Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

20190906 practitestslideshare

640 views

Published on

a presentation slide for test management solution introduction meetup at Tokyo

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

20190906 practitestslideshare

  1. 1. My Test Management Journey 2019/9/6 湯本 剛 @yumotsuyo テスト管理ソリューション⼊⾨Meetup
  2. 2. 2 ⾃⼰紹介 湯本剛(@yumotsuyo) q経歴 1991年 ⼯作機器メーカーで経理部に所属し、⽣産管理システムの受⼊テストに従事 1995年 メーカー系列ソフトハウスにてテストリーダーとしてアプリ開発に従事 – 財務会計のパッケージソフト、プリンタ、スキャナ、製造業受託開発(在庫管理、⽣産管理など)、顧客向けプロダク ト販売Webサイト構築など 2003年 ⾖蔵にて、ソフトウェアテストコンサルタントとして、テストプロセス改善コンサル、テ ストツール導⼊⽀援、テスト教育に従事 2010年 ⽇本ヒューレット・パッカード(HP) ソフトウェア部⾨にて、ALM製品のプリセールス に従事 2014年 ⽇本HPのサービス部⾨にて、デリバリー案件のテストマネジメント、⼤規模プロジェク ト専⾨QA組⽴ち上げのコンサルテイング&デリバリー 2017年 ユーザー企業 開発部⾨のテスト専⾨部署にて⼤規模デリバリーのテストマネージャー、 社内全システムのテストガバナンス運営(標準整備、定着活動) ーーーーーー freee株式会社 テスト師匠 / 株式会社ytte Lab 代表 & コンサルタント NPO法⼈ ASTER︓ソフトウェアテスト技術振興協会 理事 JSTQB(認定ソフトウェアテスト技術者資格制度)技術委員 ISO/IEC JTC1/SC7 WG26 (ISO29119︓テストプロセス標準の策定)幹事 ーーーーーー 博⼠(⼯学)︓筑波⼤学⼤学院にて、テスト技術の研究に従事し、2018年に授与 q著書 § 書籍(6冊)︓ 現場の仕事がバリバリ進むテスト⼿法、ソフトウェアテストの基礎、JSTQBソフトウェアテスト教科書、 基本から学ぶソフトウェアテスト、ソフトウェアテスト293の鉄則、TPINEXT(ビジネス主導のテストプロセス改善) § 学術論⽂︓ 「データ共有タスク間の順序組合せテストケース抽出⼿法」電気学会 論⽂誌C Vol. 137 No. 7 § 国際学会︓ A Test Analysis Method for Black Box Testing Using AUT and Fault Knowledge など多数 § 雑誌、ネット記事︓ ⽇経ITProなど多数
  3. 3. 「タフでクールでそして ヒューマンタッチ、まともな 暮らしが苦⼿だと誰もに⾔わ われている」 Happy man 佐野元春
  4. 4. 4 テストマネジメントに関するOutput Journey 現場の仕事がバリバリ進むソフトウェアテスト⼿法 • 技術評論社 ⾼橋寿⼀さんと共著 2006年 • それまでの経験を書籍に書いた(当時37歳) テスト計画の⽴て⽅,書き⽅,進め⽅ • ソフトウェア・テスト PRESS Vol.5 特集記事 2007年 • 「戦略、段取り、成果物の三位⼀体」 ISTQB ALテストマネージャーシラバス 2012 6章 • ⼈⽣初めて英語で執筆 • 書いた内容はOKもらったが、英⽂の⾔い回しは8割がた直された(爆) テストマネジメント⻁の巻 • 2010年から2012年までHPのサイトで連載していた記事。12回まで。 • HPのサイトからは削除されてしまったので、⾃分のnoteで マガジンにして公開している。 • 途中で休⽌してしまっているので、どこかで再開し完結させるのが夢 開発プロジェクトにおけるテストマネジメントの基本と実践 • ソフトウェアテストシンポジウム(JaSST)2019北陸 基調講演 • ⼤規模プロジェクトのテストマネジメントについての話
  5. 5. 5 テストマネジメントツール活⽤ Journey 1998年︓ Test Director(その後のQuality Center)に出会う • ⾃社で作ったテストケース管理ツールにTest Directorで知ったノウハウを追加した。 – テストケースをレビューするときのワークフローをくみこんだ • ⾃動テスト(WinRunner)の結果を蓄積、管理 – ⾃動テスト実⾏状況の可視化ツールとして活⽤ 2004年︓テストマネジメントツールの導⼊コンサルティング始める • この頃は、導⼊後の定着⽀援や実装や運⽤もやるケースが多かった。 • OS開発プロジェクトにて、⾃動テストとのインテグレーションで、リアルタイムにテスト結 果を可視化させた。 – テストケース保管庫として⼤活躍 2010年︓テストマネジメントツールベンダーでプリセールスを⾏う • 導⼊前のテストケースの管理の仕⽅をアセスメントするツールを開発 • 10社程度のアセスメントを実施 • このアセスメントツールは公開してもいいかな、って最近思う 2014年︓⾃分がテストマネージャーとして活⽤する • ⼈事パッケージ、公共系フロントシステム、統合プロジェクト、⾦融プロジェクト – テスト進捗の可視化/バグとのトレースツールとして⼤活躍
  6. 6. 6 今後テスト管理でやりたいと思うこと ⾃動テストと探索的テスト(そして従来のテスト)の融合 • 1つのプロダクトに対してのテストのやり⽅がさまざまになってきて、どのテストのや り⽅でどのエリアがカバーできているかがわからなくなる懸念を解消する – 開発エコシステムに組み込んでリアルタイムに情報収集 誰もが同じところを⾒ればテストの状況がわかる • ⼩さなチームに分かれて開発をしていくようになったときの それぞれのやり⽅をモニタリングする道具になる – 複数のチームのE2Eテストのテストケースのためのサービステンプレート – システムが⽬的を達成しているか判断するためのダッシュボード 過去どのようなテストをしていたのかがわかる • マイクロサービス化によるカナリアリリースが実現でき、 リリースがどんどん⼩刻みになったときに、いつ何をどの程度テスト していたのかがわかるための道具になる – 同じテストを複数回繰り返すためのナレッジデータベース – システムが進化していく中でテストケースも追加、修正、削除を していかなければならない。そのためには後から⾒てわかるよう にテストが整理されて格納されていないといけない。
  7. 7. 7 [参考]テストケース管理 データ構造 • 今までとテストの管理の仕⽅の違い。 • テスト︓今までのテスト項⽬のうち、テスト設計で最初に作る部分が該当します。 • テストインスタンス︓テスト項⽬の中の「テスト実⾏時に必要となる具体的な内容」を 別記したものです。これにより、テスト項⽬の汎⽤的な部分と、毎回変わる部分を分け て管理できるため、テスト項⽬の再利⽤が容易になります。 • テストラン︓テストの実⾏結果(合格/不合格)の結果を残すためのものです。複数回 テスト実⾏した際の履歴を全て確認できます。 テスト テストラン 1 対 N テスト設計で作ったテストケース テスト実行結果の登録 1 対 N テスト項目 今までのテスト項目(SpredSheetで作るもの) ID 確認概要 実施予定日 実施結果手順 期待結果 実施結果 実施予定担当 ID 確認概要 手順 期待結果 いままではひとつの 行に全ての内容を 記載したテスト項目 を作っていました。 今後は、テスト設計、日程 /担当に割り当て、実施で それぞれに分けて記載す るようになります。 テストインスタンス 実行日程に割り当てたテスト 実施予定日 実施予定担当 テストセット テストインスタンスを実行単位に束ねる箱
  8. 8. 8 [参考]テストケース管理 資産化と実績収集⽤払出し テスト1 テストケース条 件 値 操 作 結 果 テストケース1 テストケース2 テストケース3 テスト2 テストケース条 件 値 操 作 結 果 テストケース1 テストケース2 テストケース3 テストケース4 テスト設計(資産化) テスト一覧 ※資産管理対象 テスト3 テストケース条 件 値 操 作 結 果 テストケース1 リリース1.2 第一週 実行計画 ※リリース毎 第二週 テスト実⾏(実績収集) 動作確認 山田 田中 テスト1 インスタンス テスト1 インスタンス旅行予約 山田 テスト2 インスタンス テスト3 インスタンス テストすべきことを、資産が⼊った貯蔵庫から実績収集の場へ払い出す
  9. 9. 9 [参考]テストケース簡易アセスメント ⽬的 テストケースのマネジメント状況を以下の視点で改善する • テストケースが適切に⽤意できているかが把握できる (レビューなどテストの過不⾜ を確認する⼯数増を防⽌) …可読性 • テストケースの再利⽤を促進する(テストケース作成⼯数の重複防⽌) …再利⽤性 • テスト⽬的とテスト対象に適合したテスト設計を⾏える(適切なテスト量設定)…⼗分 性 アセスメント到達ゴール 3つの特性でテスト関連ドキュメントの現状評価と要強化ポイントの提⽰を⾏う • テストの可読性 • テストの再利⽤性 • テストの⼗分性 ヒアリング2時間、現物調査4時間で実施 25% 8% 17% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 十分性 再利用性可読性 アセスメント
  10. 10. ありがとうございました︕ Thanks for your attention!
  11. 11. Appendix テストケースマネジメントのアセスメント
  12. 12. 12 アセスメントの⽅法 アセスメントはインタビューとドキュメントレビューをベースに実施 担当者の⽅にインタビューを⾏い、テストの進め⽅を確認した上で、進めてい く中で使われているドキュメントをレビュー • インタビュー2h、ドキュメントレビュー4h以内で調査できる範囲でアセスメントを実施 弊社独⾃に作成したテストドキュメントのアセスメントモデルを元に客 観的な評価を実施 以下の5つの領域に分類し、ドキュメントの記述内容を評価 • テスト対象の分析 • テスト⽬的の定義(テストタイプの定義) • テスト条件の識別 • テスト設計 • テスト構造(ドキュメント構成や、項⽬定義に関する評価) 評価の視点は以下の3つ • 可読性、⼗分性、再利⽤性 評価項⽬は16項⽬、それぞれの項⽬に対して0点~2点で採点 ※ 本評価は、テスト技術者のスキル、テスト対象の品質を評価するものではありません
  13. 13. 13 アセスメント項⽬ テスト対象の分析 1) テスト対象の分析、整理方法の定義 十分性 2) 「1)」のやり方の読みやすさ 可読性 3) テスト対象の詳細化(大中小化)と「1)」の分析モデルの整合性 可読性 4) テストチーム、テストのフェーズなどでテスト内容について書かれたドキュメントの記載内容の突き合 わせができるか? 可読性と再 利用性 テストタイプ定義 5) テスト目的(テストタイプ)は複数の視点でテストするように定義されているか? 十分性 6) テスト対象を網羅するため、テストタイプを具体的に定義して(ex.入力に着目)いるか? 再利用性 テスト条件の識別 7) テスト対象からどのテストタイプ(目的を満たすための観点)でテスト要件(条件)を識別しているかが 読み取れるか?ルールとそれが書かれた文書があるか? 再利用性 テスト設計 8) バグの出そうなところ、バグが出た時の市場へのインパクトを考慮したテストケース作成 十分性 9) テストケース設計技法の適用方法 十分性 テスト構造 10) テストケースとテスト対象との紐づけ 再利用性 11) テストケースとテストインスタンス、テスト手順の分離 再利用性 12) テストケースの粒度(条件、操作、期待結果)のルール 可読性と再 利用性 13) テストケースとテスト結果の紐づけ 十分性 14) テスト結果とバグの紐づけ 十分性 15) テストに関する要素をトレースする仕掛け 可読性 16) テスト結果の集計の仕掛け 可読性
  14. 14. 14 アセスメントチェックリスト(1/2)
  15. 15. 15 アセスメントチェックリスト(2/2)

×