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