JaSST'23 Tokyo / テスト管理ツール、利用者目線での課題を語る

JaSST'23 Tokyo セッション A8 「テストウェアのデータモデル」の発表資料です。
https://www.jasst.jp/symposium/jasst23tokyo/details.html#A8

Transcript

1. 1 / 19 テスト管理ツール、 利用者目線での課題を語る Mar. 10th, 2023 JaSST'23 Tokyo 鈴木 一裕 @ kz_suzuki Image: "First sunset | Emmet's Adventures" by chris.alcoran is licensed under CC BY-NC-ND 2.0.
2. 2 / 19 JaSST'23 Tokyo Copyright 2023, Kazuhiro SUZUKI ◼ 参加書籍 自己紹介 ◼ 鈴木 一裕 ◼ 職業: QAエンジニア ◼ Twitter: @kz_suzuki ◼ ブログ: ソフトウェアの品質を学びまくる(*1) ◼ コミュニティ ⚫ ISO/IEC/IEEE JTC1/SC7/WG26(*3)委員 など ◼ 最近の社外発表 ⚫ 2022年3月 @JaSST’22 Tokyo - 『実践ソフトウェアエンジニアリング』 第3部 超概説 ⚫ 2022年12月 @JaSST nano vol.19 - AIシステムのブラックボックステスト ⚫ 2023年2月 @Developers Summit 2023 - テストを学びたい開発者のためのソフトウェアテスト 読書マップ (*1) 実際のところ、そんなに学びまくっていない。 (*2) ソフトウェアテストに関する規格などを作っている委員会 システムテスト自動化標準ガイド 翔泳社・2014年 監訳・共訳 (1章分だけ) ソフトウェア品質知識体系ガイド(第3版) オーム社・2020年 共著 (超一部) 実践ソフトウェアエンジニアリング(第9版) オーム社・2021年 共訳 (3章分だけ)
3. 3 / 19 JaSST'23 Tokyo Copyright 2023, Kazuhiro SUZUKI 目次 1. 自己紹介・目次 2. スプレッドシートとテスト管理ツールの比較 3. 課題: 解決策が見い出せない系 A) テストケースの単位とグルーピング B) テストモデルとの相性 4. 課題: ベストプラクティス集めたい系 C) テストケースの管理構造 D) テスト実行のステータス管理 E) 情報のトレーサビリティ
4. 4 / 19 スプレッドシートと テスト管理ツールの比較 Image: "I Love Spreadsheets" by CraigMoulding is licensed under CC BY-SA 2.0.
5. 5 / 19 JaSST'23 Tokyo Copyright 2023, Kazuhiro SUZUKI Excel管理の比較(*1) ◼ テスト管理ツールも万能ではないが、Excel管理の手間を大幅に省いてくれる。 ⚫ ここでいう「Excel管理」とは、テストケース自体から実行までが強力に結合した、モノリシックExcelシートを意味します。 分類 従来のExcel運用 一般的なテスト管理ツール テスト計画 • 先にテスト期間があって、そこにテストケースを作成したり、過去のテストケー スをコピーしてくるという発想。 • 先にテストケース群があって、テスト期間に対して必要なテストケースを割り 当てるという発想。 • テストケースが、実行時間・リスク・関連づく欠陥などの情報を持っており、計 画に役立てることができる。 テスト分析・設計 • 仕様とテストケースのトレーサビリティは弱い。 • 図・表形式で設計したテストケースを、そのままテストケースとして使うことが できる。ただし設計ごとに表現方法が異なるため、集計は困難になる。 • チケット管理システムとの連動で、仕様とのトレーサビリティを確保できる。 • テスト設計のためのモデリングツールはあるが、テスト管理ツールとは連動させ られない。モデルを変更してテストケースが変わっても、テスト管理ツールに は反映できない。 テストケース管理 • テストケースが、詳細も含めて一覧化されるので、全体感がわかりやすい。 • 一括置換・コピペ・行移動・フィルタ・ソートなどが容易で、編集がしやすい。 • 過去のテストケースをコピペして寄せ集めにしがち。 • テストケースごとに1枚の画面があるため、全体感がわかりづらい(*2)。 • 複数のテストケースを一括で修正するのは難しい。 • 最新のテストケースを一元管理できる。 テスト実行 • 「テストケースに対して実行は1回」という暗黙の前提があるため、複数回実 行した場合の結果を適切に管理しづらい。 • 1つのテストケースに対し、テスト実行が複数回あることが前提のデータモデル。 • どのテストケース実行がどういうステータスにあるかが把握しやすい。 欠陥管理 • テスト実行に付随する情報として持たせることはできる。ただし、1つの実行に 対して複数のバグ・・・といった状況に弱い。 • チケット管理システムとの連動で、バグとのトレーサビリティ管理ができる。 • あるインシデントが、どのくらいのテストケース実行のブロックになっているか、と いった情報が把握しやすい。 テストのモニタリング • 進捗やグラフは自分で作りこむ必要がある。Excel職人がいれば、必要なグ ラフを柔軟に作り込むことができるが、メンテナンスが難しい。 • ビルトインで用意されたグラフや表はリアルタイムに集計され、すぐに使うことが できる。 その他 ー • 専用ツールならではの機能がある。テストシナリオのパラメタライズや、テスト ケースと環境条件の組み合わせ管理など。 (*1) より詳細な比較はこちらの記事を参照してください。テストケース管理ツールとスプレッドシートでは、テスト管理の何が違うのか (*2) スプレッドシートのような2次元表形式でテストケースを管理するツールもある。
6. 6 / 19 課題 解決策が見い出せない系 Image: "I'm studying" by rabbitneverlies is licensed under CC BY-SA 2.0.
7. 7 / 19 JaSST'23 Tokyo Copyright 2023, Kazuhiro SUZUKI 解決策が見い出せない系の課題 ◼ テスト管理ツールの一般的な機能では、どう解決していいかわからない 課題があります。 ◼ ここでは、以下の2件について説明します。 A) テストケースの単位とグルーピング B) テストモデルとの相性
8. 8 / 19 JaSST'23 Tokyo Copyright 2023, Kazuhiro SUZUKI A: テストケースの単位とグルーピング テスト管理ツールは、「1テストケース、1画面」で管理する(*1)ことが多い。 この管理方法には、いくつかのデメリットがある。 ◼ 一覧性の低下 ⚫ テストケースがバラバラにされてしまうので、テストケース間の関係性がわかりづらくなる。 ⚫ テストケースをツリー構造で管理できることが多いが、階層が深すぎても扱いづらい。 → 「スプレッドシート型」で解決できる？ ◼ 保守性の低下 ⚫ 「手順が共通で、パラメタだけが違う」テストケース群も別のテストケースとして扱うため、 共通部分を修正する場合にいくつものテストケースに同じ修正を行う必要がある。 - たとえば、「ユーザ名とパスワードを入力してログイン」というシナリオを、いろんな値で試したい、など。 → 「データ駆動」の機能サポートで解決できる？ (*1) このような管理ビューを、きんぢさんは「チケット型」と呼んでいます。
9. 9 / 19 JaSST'23 Tokyo Copyright 2023, Kazuhiro SUZUKI B: テストモデルとの相性 テスト管理ツールと、その外で作成したモデルとの関連付けが難しい。 ⚫ 記法が定義されたモデル - 記法の定義されたモデル(*1)は、専用ツールで作成し、テストケースを導出することができる。モデルは一覧性や レビュー容易性にも優れている。 - 導出したテストケースをエクスポートし、テスト管理ツールにインポートすると、トレーサビリティがそこで断絶してしまう。 ⚫ 記法が定義されていないモデル - 実際のテストにおいては、テスト対象に応じて独自のモデル（図表）を描くことも多い。 > たとえば、「システムの障害部位」×「障害のタイミング」を網羅するためのマトリクスなど。 - このようなケースでは、設計もレビューもExcelの汎用性が強みを発揮する。 - 一方で、テスト管理ツールとの相性は悪い。 ⚫ テスト設計変更時のトレーサビリティ - プロダクト仕様が変化し、テスト設計に手が入ったとき、追加・変更・削除されるテストケースはどれか。 既存のテスト実行のうち、やり直しが発生するのはどれか、の影響分析が難しい。 > 仕様が変化するケースより、テスト設計の見直しの場面の方が多いかもしれない。 (*1) デシジョンテーブル、状態遷移表、ペアワイズテストの制約表など。
10. 10 / 19 課題 ベストプラクティス集めたい系 Image: "Houston, tenim un problema - Houston, we have a problem" by Jordi@photos is licensed under CC BY-NC-SA 2.0.
11. 11 / 19 JaSST'23 Tokyo Copyright 2023, Kazuhiro SUZUKI ベストプラクティス集めたい系の課題 ◼ チケット管理ツールなど他のツールと同様に、テスト管理ツールも、 「管理の枠組み」を提供してくれます。 一方その枠組みを自分たちの仕事にどう組み込んでいくかは、 事前の検討と継続的な改善が必要です。 ◼ そうはいっても、「事前の検討」ってやっぱり難しい。なので、 提供側・利用側双方の知恵と経験で、「ベストプラクティス」 を提示できるといいな。 ◼ ここでは、以下の3件について説明します。 C) テストケースの管理構造 D) テスト実行のステータス管理 E) トレーサビリティの使いどころ
12. 12 / 19 JaSST'23 Tokyo Copyright 2023, Kazuhiro SUZUKI Smoke Test Performance Test C: テストケースの管理構造 ◼ 管理構造 ⚫ テストケースが増えてくると、カオスになりがち。 テストセットのメンテナンス性や検索性を維持 するために、ある程度は構造化が必要。 ◼ テストケース名称 ⚫ Excel管理では、テストケースに名前を与えると いうことが少なかった。テスト管理ツールでは、 各テストケースに明示的に名前を付けることが 半ば強制される。 ⚫ テストケース一覧を表示する場合、パッとみて どんなテストケースかわかることが大事。 ⚫ テストケース命名ルールがあった方がいい。 ◼ ツール提供側から、おすすめの 構造・ルールなどあるでしょうか？ Product Feat1 Feat1A Feat1B Feat2 Feat3 TC1A-2 TC1-3 TC1-4 TC1A-3 TC1A-4 TC1B-2 TC1B-3 TC1B-4 TC2-2 TC2-4 TC2-3 TC2-1 TC3-2 TC1-1 TC1-2 TC1A-1 TC1B-1 TC3-1 TC3-3 Full Test Set Test Objective Test Type 以下の図は、過去に提案した構造化の一例 ⚫ フィーチャの単位でツリー構造を構成する ⚫ テスト目的やテストタイプはタグ付けでグルーピング
13. 13 / 19 JaSST'23 Tokyo Copyright 2023, Kazuhiro SUZUKI D: テスト実行のステータス ◼ 一般的なステータス ⚫ テスト管理ツールで扱えるテスト実行のステータスはシンプルで、それほど難しくは見えない。 ⚫ しかし、「計画したテストは、完了したといえるのか？」を判断しようとすると、いきなり難しくなる。 ステータス 一般的な意味 派生的な運用 備考 Not Run テストが未実行である。 最終的に、実行しなかった。 Untested などとも呼ばれる。 Passed テストを実行し、期待通りの結果が得られ た。 他のテストケース実行でカバーされ た。 Failed テストを実行し、期待通りの結果が得られ なかった。 Blocked バグや環境問題などにより、テストの前提 条件が満たされず、テスト実行が阻害され ている。 同様の理由で、実行するまでもな く failed が予想されるため、実 行を保留しているもの。 Blocked に倒しておくことで、 「多くのテストケースが実行不 可能である」ことを表明するこ とができる。 Skipped テストを実行しないこととした。
14. 14 / 19 JaSST'23 Tokyo Copyright 2023, Kazuhiro SUZUKI D: テスト実行のステータス ◼ 「成功を期待できない」テストケースが増えてくると、事態が複雑化する。 (*1) これがグッドプラクティスという意味ではないです。 # ありがちな状況 考えられる運用(*1) 1 テスト実行でFailedになり、プロダクトのバグであること が判明したが、当該バージョンでは直さないこととした。 この状態だと、そのテスト期間のテストが完了しているの かどうかがわからなくなってしまう・・・。 当該バグチケットのステータスをBlockedにする。テスト実行がFailed で、関連づくバグチケットがBlockedのものは、そのテスト計画における 実行は完了とみなす。 ※すでに超ややこしい・・・ 2 現時点では直さないと判断したバグがあり、このバグのた めに、実行するまでもなく失敗が想定されるテストケース が残っている。 そのバグをすぐに直す予定であれば、実行ステータスをBlockedにしてお き、修正後に実行する。 すぐに直す予定がなければ、実行ステータスはFailedにし、バグチケット を関連付けておく。修正のタイミングで、そのテストケースをもう一度テス ト計画に含める。 3 テスト環境の問題で、テストケースが実行できない。 少数であればNon Runでもいいが、多いならBlockedにし、テストが阻 害されていることを明らかにする。環境の問題であってもチケットを作って 管理するのがよい。 4 仕様変更やバグフィックスに影響を受ける見込みがある ため、テストケースの実行を保留している。 当該チケットに影響を受けるテストケースを特定したうえで、チケットを関 連付けておく。 5 Blockedのテスト実行があると、やるつもりがあるのかあ きらめているのかがわからない。 実行するつもりがないのであれば、次のスプリントにケースを割り当てる。 ブロッカーも関連付けておく。
15. 15 / 19 JaSST'23 Tokyo Copyright 2023, Kazuhiro SUZUKI D: テスト実行のステータス ◼ バグチケットとの関連を整理しても、複雑になる一方。。 ◼ シンプルな考え方に整理できないでしょうか・・・？ (*1) バグチケットのステータスの方が誤っている可能性もある。 バグチケ→ ↓テスト実行 なし 修正未完 今スプリントでの修正予定 あり 修正未完 今スプリントでの修正予定 なし 修正完了 Not Run テスト実行可能であるが、未実行 である。 修正予定のバグの影響を受けるため、 実行を保留している。 → Blockedに遷移させる 当該スプリントでは実行できない。 → Blockedに遷移させる バグ対応が終わっており、実 行可能である。 Passed テスト実行済みで、期待通りの結 果が得られた。 一度Passedになったが、バグ修正の 影響を受けることがわかっており、再テス トが必要な状態(*1)。 →バグチケ対応完了後にテストを再実 行するため、Not Runに戻す。 左セルと同じだが、当該スプリント では再実行ができない。 → Blockedに遷移させる バグ対応が終わっており、テ スト実行も完了している。 Failed テスト実行済みで、期待通りの結 果が得られなかったのに、バグチ ケットがない。 → バグチケットを作成する。 テスト実行済みで、期待通りの結果が 得られなかった。バグの修正待ちである。 テスト実行済みで、期待通りの結 果が得られなかった。バグは当該 スプリントで直さないこととした。 テスト実行済みで、期待通 りの結果が得られなかった。 バグは修正済みなので、再 テストが実行可能である。 Blocked 何らかの理由でテストが実行でき ない状態だが、その要因に対応す るチケットがない。 → バグチケットを作成する。 既知のバグによって、テストが実行でき ない。 既知のバグによって、テストが実行 できない。当該スプリントでは対応 しない。 阻害要因が除去されている ため、テスト実行可能である。 → not Runに遷移させる
16. 16 / 19 JaSST'23 Tokyo Copyright 2023, Kazuhiro SUZUKI E: 情報のトレーサビリティ ◼ テスト管理ツールの1つの利点はトレーサビリティとよく言われる。一方で、 トレーサビリティ情報をどう役立てるかは、あまり語られない。気がする。 ◼ 自分たちにとって「どの情報に価値があるか」、考えよう！ ⚫ この仕様変更で影響を受けるテストケースは？ → 仕様 ⇒ テストケース のトレーサビリティ ⚫ このスプリントでは、いくつ欠陥が見つかった？ → テスト計画 ⇒ テスト実行 と、 テスト実行 ⇒ 欠陥 のトレーサビリティ ⚫ どの機能でたくさん欠陥が出ているのだろう？ → 仕様 ⇒ テストケース と、 テストケース ⇒ テスト実行 と、 テスト実行 ⇒ 欠陥 のトレーサビリティ テスト計画 テストケース群 テストケース テスト実行 テスト実行 テスト実行 テストケース テストケース テストケース 欠陥 欠陥 欠陥 欠陥 機能仕様 仕様 仕様
17. 19 / 19 JaSST'23 Tokyo Copyright 2023, Kazuhiro SUZUKI 以上、利用者側の勝手な課題感を お伝えしました。
18. 20 / 19 JaSST'23 Tokyo Copyright 2023, Kazuhiro SUZUKI Happy Testing!!