Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie ソフトウェアテストことはじめ2016年ver
Ähnlich wie ソフトウェアテストことはじめ2016年ver (20)
Mehr von Kosuke Fujisawa
Mehr von Kosuke Fujisawa (20)
ソフトウェアテストことはじめ2016年ver
- 2. はじめに 本発表の対象者 • テストを実施する⼈へ • 普段⾏なっているテストを良くするにはどうし たらいいかのヒントを得てほしい • テストを管理する⼈へ • テストを実施する⼈が普段どんなことを考えて いるか知ってほしい 2
- 3. アジェンダ • ⾃⼰紹介 • テストプロセス全体像について • プロジェクトであった出来事 • チェックリストで評価してみよう • まとめ 3
- 4. ⾃⼰紹介 • 仙台本社の某SIerのQAとして勤務してます • 盛岡市出⾝です • 勤務地は関東です • ドメインは⾦融系です 4
- 8. テストプロセス全体像 • 参考：JSTQBテスト技術者シラバス Advanced Level テストマネージャ 8 テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 テ ス ト 実 ⾏ テ ス ト 報 告 テスト計画とコントロール
- 9. テストプロセス全体像 9 テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 テ ス ト 実 ⾏ テ ス ト 報 告 テスト計画とコントロール • 何をテストするか考える (What) • なぜテストするか考える (Why) • どのようにテストするか 考える(How) • どれくらいテストするか 考える(How much)
- 10. テストプロセス全体像 10 テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 テ ス ト 実 ⾏ テ ス ト 報 告 テスト計画とコントロール • テスト計画とコントロール • テスト全体の⽅針を決める • 決めた⽅針に沿ってテストが⾏えている かチェックし、問題があれば⾒直す • テスト計画は進⾏とともに⾒直す
- 11. テストプロセス全体像 11 テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 テ ス ト 実 ⾏ テ ス ト 報 告 テスト計画とコントロール • テストベース（要件定義書、設計書 など）を分析する • テストベースを読み込む • 構造、モデルを使って分析する
- 12. テストプロセス全体像 12 テ ス ト 分 析 テ ス ト 設 計 テ ス ト 実 装 テ ス ト 実 ⾏ テ ス ト 報 告 テスト計画とコントロール • 組み合わせテスト、状態 遷移テストなどの設計を ⾏う • カバレッジの検討も⾏う • 具体的なテストアプロー チも検討する
- 16. テストプロセスを定義する意味 • 「テスト」と⼀緒くたに考えてしまうと、どこが問題 なのかわかりづらい • プロセスが分かれることで、テストのどこが問題なの かわかりやすくなる • テストの準備？テスト⾃体？テスト結果の報告？ • ⾔葉の意味づけ⾃体に正解はない。ただし認識を合わ せることは重要 16
- 18. プロジェクトであった出来事 • テストがうまくいかなかった（テストが遅れる、 不具合が出ない） • テストケースに記述した⼿順が曖昧だったために、 実⾏する段階になってテストできないケースが出 てくる • テスト環境の使い⽅がわからず、テストできない 18
- 19. プロジェクトであった出来事 • 「テストを改善する」というと、テスト設計 技法やテスト⾃動化などを連想しがち • 実際それに関する情報も多い • 今回うまくいかなかった問題を解決するのは、 テスト設計技法や⾃動化ではないと思った 19
- 22. 22 テスト活動 簡易評価チェックリスト # 項⽬ 分類 チェック （○、△、 ×） 1 開発者とのコミュニケーションに、物理的距離、⼼理的距離、時間的制約など重⼤な障害がないこと。 コミュニケーション 2 テスト結果の報告について、頻度や時間帯、⼿段、レポートの内容が規定されていること。 コミュニケーション 3 テストチームリーダーおよびメンバー間で、情報共有すべき事項が明確になっていること。 コミュニケーション 4 テストチームまたは開発チーム内の有識者に、確認すべき事項が明確になっていること。また、確認できる⾒ 通しがあること。 コミュニケーション 5 テストに関する成果物のレビューを計画していること。また、計画通り実施していること。 レビュー 6 テストチーム内で、テストの取り組み⽅や⼿順、テスト関連資料やテスト結果の保管⽅法が統⼀されているこ と。 テスト成果物管理 7 テストの重み付けは、テスト対象機能のリスク分析結果によって調節されていること。 テスト計画 8 ⽋陥レポートは、⽋陥の再現⼿順、期待する結果と実際の結果が読み⼿に理解できるように記述しているこ と。 ⽋陥管理 9 テストケースは、テスト開始時の状態（前提条件）を読み⼿に理解できるように記述していること。 テスト実装 10 テストケースは、具体的なテスト実⾏⼿順を読み⼿に理解できるように記述していること。 テスト実装
- 24. チェックリスト（１） • 開発者とのコミュニケーションに、物理的距離、⼼理 的距離、時間的制約など重⼤な障害がないこと • 同じ場所で開発しているか • 開発者とのコミュニケーションで、どことなく壁を 感じることはないか • 勤務時間や空き時間が開発者と（ある程度）合うか 24
- 25. チェックリスト（１） • Face to Faceでのコミュニケーションには、⽬に ⾒えない情報がある • 声のトーン、顔⾊、雰囲気 • ちょっとした⽇常会話がヒントになることもある • あまりにも時間が合わないと打ち合わせなどの調 整が⼤変 25
- 27. チェックリスト（２） • テスト結果の報告について、頻度や時間帯、 ⼿段、レポートの内容が規定されていること • 何を報告するか決まっていること • いつ報告するか決まっていること • 報告フォーマットが決まっていること 27
- 28. チェックリスト（２） • 報告を受ける側とする側で、要求しているこ と報告されることが違うことがある • 報告が欲しいタイミングと、報告をしたいタ イミングは違うことがある • メール、Excelなど報告に使うツールが決まっ ているとそのあとの作業がスムーズに進む 28
- 31. チェックリスト（３） • 「それくらいは共有してくれると思ってた」 • 「なんで教えてくれなかったんだ」 • 「無駄な情報ばかり⾶び交っていて、本当に必要 な情報が判別できない」 • 何が共有すべき事項なのか、なぜ共有すべきな のかチーム内で認識を合わせる必要がある 31
- 34. チェックリスト（４） • その場その場で必要な情報を求めていたら、どん どん対応が後⼿に回る • 確認しておきたい情報はできるだけ早い段階で確 認する。せめて確認する時期がいつくらいになり そうか⾒当をつける • 「確認待ち」のステータスで作業が⽌まるの が⼀番時間がもったいない 34
- 36. チェックリスト（５） • テストに関する成果物のレビューを計画して いること。また、計画通り実施していること • そもそもレビューを計画しているか • レビューを計画していても、それが計画の まま放置されていないか 36
- 37. チェックリスト（５） • できるだけレビューは早めに⾏う • ⼤きな問題が後からわかっても⼿遅れ • スケジュールが合わない場合、なるべく中⽌で はなく延期にする • あまりにも合わない場合、参加者の⾒直しが 必要なこともある 37
- 39. チェックリスト（６） • テストチーム内で、テストの取り組み⽅や⼿ 順、テスト関連資料やテスト結果の保管⽅法 が統⼀されていること • テストに関する資料、テストデータ、ログ などの置き場が決まっているか • それが周知され、守られているか 39
- 40. チェックリスト（６） • 置き場が決まっていれば、⼿順の変更⼀つ⼀つに対して いちいちコミュニケーションを取らなくてもよくなる • 個⼈が集めた資料であっても、メンバ全員が⾒られる場 所に資料を置いておく⽅が時間の節約になる。同じこと を別のメンバが聞くという⼆度⼿間を防ぐ • テスト成果物が散在していると、報告などの時にとても 困る 40
- 42. チェックリスト（７） • テストの重み付けは、テスト対象機能のリスク分析結 果によって調節されていること • その機能が正しく動作しないことによる影響度の⼤ きさはどれくらいか • その機能はどれくらいの頻度で使われるものなのか • 上記のような情報を加味してテストの重み付け（カ バレッジの網羅度の調節など）が⾏われているか 42
- 43. チェックリスト（７） • ⼀律で同じ重み付けでテストをするのは良く ない • 過度なテスト実施、テスト不⾜を招く • リスクを考慮してテストの調節を⾏うべき 43
- 45. チェックリスト（８） • ⽋陥レポートは、⽋陥の再現⼿順、期待する結果 と実際の結果が読み⼿に理解できるように記述し ていること • 開発者が全く同じ⼿順で操作しても再現できる こと • 期待する結果と実際の結果との差異は何か記述 していること 45
- 46. チェックリスト（８） • 開発者からすると再現できない不具合は扱い づらい • 再現できないにしても、できるだけ情報は 集める（この時に発⽣する／発⽣しない） • 期待結果と実際の結果との差異がわからない と、何が問題なのか認識できないことがある 46
- 49. チェックリスト（９） • 前提条件はテストケースの中でも特に抜けがちな項⽬ • 書いている本⼈にとっては当たり前なことでも、第三 者が読むとわからない場合もある • 読んだ通りにテストした結果、意図した結果が現れ ないこともある • できるだけ客観的に、前提となる「条件」「状態」な どを記述する必要がある 49
- 51. チェックリスト（１０） • テストケースは、具体的なテスト実⾏⼿順を 読み⼿に理解できるように記述していること • 「それを読めば、誰にも何も確認せずにテ ストを実⾏できる」が理想の状態 51
- 54. 現場で使うために • チェックリストの導⼊は難しくても、「問い かけ」の形にすれば取り⼊れやすい • 例 • このテストケースってどう実⾏しますか？ • テスト結果の報告の仕⽅は決まってますか？ 54
- 56. まとめ • やみくもにテスト技法やテスト⾃動化を学ん でも、すぐに仕事に役⽴つとは限らないので は？ • 改善するために必要なステップがあり、順序 ⽴てて取り組むことが重要なのではないか 56
- 58. 参考⽂献 • TPI NEXT® ビジネス主導のテストプロセス改善 薮⽥ 和夫／湯本 剛／皆川 義孝 訳 • JSTQBテスト技術者シラバス Advanced Level テスト マネージャ • わたしたちの開発現場 by miwa719 • http://sssslide.com/speakerdeck.com/miwa719/ watasitatifalsekai-fa-xian-chang 58