dogfoodingのススメ
これは ソフトウェアテスト Advent Calendar 2016 - Qiita の5日目の記事です。
4日目は goyoki - Qiitaさんによる (C++)constexpr & static_assertによるコンパイル時テストの用途 - 千里霧中 でした。
6日目は ks888 - Qiitaさんによる NightmareでE2Eテストをするときに役立った独自アクションのメモ - Soon Lazy です。
背景
製品開発をしている場合、その開発している製品を日頃から自分たちで触っておくことが大切です。
触っておくことで、仕様のミスや改善項目に気づけたりします。
※バグとかについても、ユーザや評価区からの指摘だけでなく、普段から触っていたら結構自分たちで発見できる(;´Д`)
俗にいう「dogfooding」と言われるやつ。
Eating your own dog food - Wikipedia
触るといっても「実際どんな感じでやればいいの?(´・ω・`)」という感じになるので、やってみた事例を紹介しておきます。
ちなみに以下の本に出てくるQAのテストを参考にしています。
- 作者: ジェームズ A ウィテカー;ジェーソンアーボン;ジェフキャローロ
- 出版社/メーカー: 日経BP社
- 発売日: 2014/02/12
- メディア: Kindle版
- この商品を含むブログ (7件) を見る
やりかた
表
管理のための表をつくって評価を進めます。
以下は実施している途中の例。
項目 | 小項目 | ログイン・ログアウト | ユーザ管理 | 個人設定 | ・・・ | 備考 |
---|---|---|---|---|---|---|
主要シーケンス | ユーザを作成する | 2016/11/01 なみひら 1 | ・最も利用されるシーケンス ・売りとなるシーケンス |
|||
(略) | 2016/11/04 Aさん 1 | |||||
・・・ | ・・・ | |||||
分かりやすさ | 進む/戻る | 2016/11/07 なみひら 1 |
||||
用語 | 分かりやすさ | 2016/11/08 なみひら 1 |
2016/11/03 Bさん 1 |
|||
誤字脱字/文字化け/公序良俗 | 2016/11/05 Aさん 0 |
2016/11/06 なみひら 1 |
||||
動作環境 | OS:Win or Mac | 2016/11/05 Bさん 3 |
2016/11/05 なみひら 1 |
|||
ブラウザ:IE or Firefox or Chrome | 2016/11/04 Bさん 1 |
・IEは特に注意。 | ||||
モニタ:19 or 24inch | 2016/11/02 なみひら 3 |
・ユーザは小さいモニタを使っているケースもある | ||||
セキュリティ | - | 2016/11/05 Aさん 0 |
・セキュリティ的に出しちゃいけないものが表示されていないか。 ・セキュリティ的に問題がある作業がないか。 |
|||
パフォーマンス | - | 2016/11/04 Bさん 1 |
・遅いところがないか確認。 | |||
ログ | - | 2016/11/06 Aさん 1 |
・パスワードをログに出力していないかなど。 ・エラーを意図的に起こしたときのログにも注目 |
|||
入力値 | 禁則文字/記号文字 | 2016/11/02 Aさん 0 |
||||
未入力 | 2016/11/03 なみひら 2 |
2016/11/01 Bさん 3 |
||||
境界値 | |2016/11/01 Bさん 1 |
2016/11/03 Aさん 1 |
- 行に評価項目・観点を並べる
- 列に機能を並べる。
- 主要シーケンスについては、機能を横断的に利用するので横串。
- 項目・機能についても随時更新・追加する。
ルール
- 毎日、項目を決めて実施する。
- 項目は各人が自由に決める。
- 数は2~3個程度。
- 1項目あたり10分ぐらい作業時間を想定。
- 少ない時間でも毎日触ることが大切。
- 実施したら上記の表に結果を記載する。例:
- 記載する内容は、「日付」「実施者」「発見したバグ/改善点の数」
- 「発見したバグ/改善点の数」については評価項目以外で気づいたものも含める。
- 管理に重視するのではなくて品質向上に努める。(バグを出し尽くす)
- 週のはじめにその週に対応するもの(直すもの)を決めて対応する。※これは開発のサイクルに依存する。
- ペルソナは作っておく。
良し悪し
良かった点
- ランダムっぽく実施するが、カバレッジが測定できる。なので、評価の穴とかが見える。
- 「この観点でこんだけの工数で実施しました」という報告がしやすい。
- 自分が担当していない他の機能もユーザ視点で触るので、視野が広がる。
悪かった点(改善点)
- やりだすと1項目実施で3つぐらい起票されるので、バグ・改善点がどんどん溜まっていく(;´Д`)
- 対応スピードが重要。または、1日あたりの実施数を少なくしたり調整が必要。
- 油断する(ちょっと忙しくなる)とやらなくなるので、習慣化するまではちょっとだけ強制する。
- 実施を進めてテスト項目を全制覇を繰り返すと、似たような手順をやりがち。そういうときは新機能を重視するとかの工夫が必要。
まとめ
なかなかコスパがいい活動(*´Д`*)