スライド
概説 テスト分析 from Takashi YAMASAKI
www.slideshare.net
アンケート
JSTQB FL取得者
- 半分ぐらい
テスト分析をズバリ説明できる人
- 2人ぐらい
テスト条件をズバリ説明できる人
- 2人ぐらい
このセッションの目的
曖昧模糊なテスト分析が実際に何であるか改めて理解し、他人に説明できるようになろう!
例題
次の仕様に対してテスト条件を考える
- パスワードは4文字以上12文字以下の 英数字のみを許容する。
- パスワードを3分以内に連続して4回以上間違って入力すると、アカウントを5分間ロックする。
ここで導き出すのは「パスワードを3文字にする」といったようなテストケースではなく、あくまでもテスト条件。
- 解答例はスライド参照
演習問題
- 次の仕様に対してテスト条件を考える
- 「ユーザデータ登録」画面の「インポート」ボタンを押下することで、「ユーザデータの一括登録」画面に遷移する。
- 「ファイル選択」ボタンを押下すると「ファイル選択」画面が表示され、ツリー構造のビューからインポート対象のファイルを選択することができる。
- 「登録」ボタンを押下するとファイル内のデータを読み込み、「ユーザデータの一括登録」画面を閉じ、「ユーザデータ」画面を表示する。
テスト分析・テスト条件について
- テスト条件は粒度が様々。
- テスト条件は考える人によってアウトプットが様々。
- だからこそテスト条件に対してレビューすることが大事。
- テスト分析を方法論化することで、出力形式を統一することができる。
質問
テスト条件のレビューの参加者は?
- 関係者全員
レビューの参加者に開発者も入ると、内部的なことについての意見が出てしまうのでは?
- 新しい観点になるので良い
あいまいな要件とコードしか無い場合のテストベースはどうするのか?
- 要件レベルとコードレベルは異なるものだと思う。
- 困っていることは何か考え、それを解決する手法を考える。
テスト分析の範囲は?(システム全体か、対象部分のみか)
- 条件依存による。
分割可能かどうかもテスト分析か?
- 粒度を細かくすると工数もかかるため、トレードオフの関係ではある。
- ただ、これをどうするかも含めてテスト分析
粒度について調整する方法論はあるか?
- 今のところないと思う。
テスト分析を行っていると、テスト設計をしている気分になるか?
- なる
JSTQBの言葉をどうやって読み解いたか?
- 社外活動で知見を得た。
- 同じキーワードが書かれているドキュメントを色々とあたることで理解できることもある。
規模が大きくいい加減な仕様を元にすると、いっぱいテスト条件が出てくると思うが、深追いを止めるコツはあるか?
- ステークホルダーに「細かすぎてよく分からない」と言われない程度までやる。
- レビューして不安なところがあったら、その部分を深掘りする。
感想
演習問題は周りの人と見せ合う機会があったのがすごい良かった。
- ちなみに私は、「画面表示の方法(新しいウィンドウか同じウィンドウのままか)」「ファイル選択数」などが思い浮かびました。
- 他の人は「ファイルサイズ」や「押下回数」などの負荷テスト部分について考えていたようでした。
今回、テスト要求分析については無いように思えました。