Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Kazuhiro SUZUKI
March 10, 2023
1.4k

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

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

Kazuhiro SUZUKI

March 10, 2023
Tweet

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.

    View Slide

  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章分だけ)

    View Slide

  3. 3
    / 19
    JaSST'23 Tokyo
    Copyright 2023, Kazuhiro SUZUKI
    目次
    1. 自己紹介・目次
    2. スプレッドシートとテスト管理ツールの比較
    3. 課題: 解決策が見い出せない系
    A) テストケースの単位とグルーピング
    B) テストモデルとの相性
    4. 課題: ベストプラクティス集めたい系
    C) テストケースの管理構造
    D) テスト実行のステータス管理
    E) 情報のトレーサビリティ

    View Slide

  4. 4
    / 19
    スプレッドシートと
    テスト管理ツールの比較
    Image: "I Love Spreadsheets" by CraigMoulding is licensed under CC BY-SA 2.0.

    View Slide

  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次元表形式でテストケースを管理するツールもある。

    View Slide

  6. 6
    / 19
    課題
    解決策が見い出せない系
    Image: "I'm studying" by rabbitneverlies is licensed under CC BY-SA 2.0.

    View Slide

  7. 7
    / 19
    JaSST'23 Tokyo
    Copyright 2023, Kazuhiro SUZUKI
    解決策が見い出せない系の課題
    ◼ テスト管理ツールの一般的な機能では、どう解決していいかわからない
    課題があります。
    ◼ ここでは、以下の2件について説明します。
    A) テストケースの単位とグルーピング
    B) テストモデルとの相性

    View Slide

  8. 8
    / 19
    JaSST'23 Tokyo
    Copyright 2023, Kazuhiro SUZUKI
    A: テストケースの単位とグルーピング
    テスト管理ツールは、「1テストケース、1画面」で管理する(*1)ことが多い。
    この管理方法には、いくつかのデメリットがある。
    ◼ 一覧性の低下
    ⚫ テストケースがバラバラにされてしまうので、テストケース間の関係性がわかりづらくなる。
    ⚫ テストケースをツリー構造で管理できることが多いが、階層が深すぎても扱いづらい。
    → 「スプレッドシート型」で解決できる?
    ◼ 保守性の低下
    ⚫ 「手順が共通で、パラメタだけが違う」テストケース群も別のテストケースとして扱うため、
    共通部分を修正する場合にいくつものテストケースに同じ修正を行う必要がある。
    - たとえば、「ユーザ名とパスワードを入力してログイン」というシナリオを、いろんな値で試したい、など。
    → 「データ駆動」の機能サポートで解決できる?
    (*1) このような管理ビューを、きんぢさんは「チケット型」と呼んでいます。

    View Slide

  9. 9
    / 19
    JaSST'23 Tokyo
    Copyright 2023, Kazuhiro SUZUKI
    B: テストモデルとの相性
    テスト管理ツールと、その外で作成したモデルとの関連付けが難しい。
    ⚫ 記法が定義されたモデル
    - 記法の定義されたモデル(*1)は、専用ツールで作成し、テストケースを導出することができる。モデルは一覧性や
    レビュー容易性にも優れている。
    - 導出したテストケースをエクスポートし、テスト管理ツールにインポートすると、トレーサビリティがそこで断絶してしまう。
    ⚫ 記法が定義されていないモデル
    - 実際のテストにおいては、テスト対象に応じて独自のモデル(図表)を描くことも多い。
    > たとえば、「システムの障害部位」×「障害のタイミング」を網羅するためのマトリクスなど。
    - このようなケースでは、設計もレビューもExcelの汎用性が強みを発揮する。
    - 一方で、テスト管理ツールとの相性は悪い。
    ⚫ テスト設計変更時のトレーサビリティ
    - プロダクト仕様が変化し、テスト設計に手が入ったとき、追加・変更・削除されるテストケースはどれか。
    既存のテスト実行のうち、やり直しが発生するのはどれか、の影響分析が難しい。
    > 仕様が変化するケースより、テスト設計の見直しの場面の方が多いかもしれない。
    (*1) デシジョンテーブル、状態遷移表、ペアワイズテストの制約表など。

    View Slide

  10. 10
    / 19
    課題
    ベストプラクティス集めたい系
    Image: "Houston, tenim un problema - Houston, we have a problem" by [email protected] is
    licensed under CC BY-NC-SA 2.0.

    View Slide

  11. 11
    / 19
    JaSST'23 Tokyo
    Copyright 2023, Kazuhiro SUZUKI
    ベストプラクティス集めたい系の課題
    ◼ チケット管理ツールなど他のツールと同様に、テスト管理ツールも、
    「管理の枠組み」を提供してくれます。
    一方その枠組みを自分たちの仕事にどう組み込んでいくかは、
    事前の検討と継続的な改善が必要です。
    ◼ そうはいっても、「事前の検討」ってやっぱり難しい。なので、
    提供側・利用側双方の知恵と経験で、「ベストプラクティス」
    を提示できるといいな。
    ◼ ここでは、以下の3件について説明します。
    C) テストケースの管理構造
    D) テスト実行のステータス管理
    E) トレーサビリティの使いどころ

    View Slide

  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
    以下の図は、過去に提案した構造化の一例
    ⚫ フィーチャの単位でツリー構造を構成する
    ⚫ テスト目的やテストタイプはタグ付けでグルーピング

    View Slide

  13. 13
    / 19
    JaSST'23 Tokyo
    Copyright 2023, Kazuhiro SUZUKI
    D: テスト実行のステータス
    ◼ 一般的なステータス
    ⚫ テスト管理ツールで扱えるテスト実行のステータスはシンプルで、それほど難しくは見えない。
    ⚫ しかし、「計画したテストは、完了したといえるのか?」を判断しようとすると、いきなり難しくなる。
    ステータス 一般的な意味 派生的な運用 備考
    Not Run テストが未実行である。 最終的に、実行しなかった。 Untested などとも呼ばれる。
    Passed テストを実行し、期待通りの結果が得られ
    た。
    他のテストケース実行でカバーされ
    た。
    Failed テストを実行し、期待通りの結果が得られ
    なかった。
    Blocked バグや環境問題などにより、テストの前提
    条件が満たされず、テスト実行が阻害され
    ている。
    同様の理由で、実行するまでもな
    く failed が予想されるため、実
    行を保留しているもの。
    Blocked に倒しておくことで、
    「多くのテストケースが実行不
    可能である」ことを表明するこ
    とができる。
    Skipped テストを実行しないこととした。

    View Slide

  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のテスト実行があると、やるつもりがあるのかあ
    きらめているのかがわからない。
    実行するつもりがないのであれば、次のスプリントにケースを割り当てる。
    ブロッカーも関連付けておく。

    View Slide

  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に遷移させる

    View Slide

  16. 16
    / 19
    JaSST'23 Tokyo
    Copyright 2023, Kazuhiro SUZUKI
    E: 情報のトレーサビリティ
    ◼ テスト管理ツールの1つの利点はトレーサビリティとよく言われる。一方で、
    トレーサビリティ情報をどう役立てるかは、あまり語られない。気がする。
    ◼ 自分たちにとって「どの情報に価値があるか」、考えよう!
    ⚫ この仕様変更で影響を受けるテストケースは?
    → 仕様 ⇒ テストケース のトレーサビリティ
    ⚫ このスプリントでは、いくつ欠陥が見つかった?
    → テスト計画 ⇒ テスト実行 と、
    テスト実行 ⇒ 欠陥 のトレーサビリティ
    ⚫ どの機能でたくさん欠陥が出ているのだろう?
    → 仕様 ⇒ テストケース と、
    テストケース ⇒ テスト実行 と、
    テスト実行 ⇒ 欠陥 のトレーサビリティ
    テスト計画
    テストケース群
    テストケース テスト実行
    テスト実行
    テスト実行
    テストケース
    テストケース
    テストケース
    欠陥
    欠陥
    欠陥
    欠陥
    機能仕様
    仕様
    仕様

    View Slide

  17. 19
    / 19
    JaSST'23 Tokyo
    Copyright 2023, Kazuhiro SUZUKI
    以上、利用者側の勝手な課題感を
    お伝えしました。

    View Slide

  18. 20
    / 19
    JaSST'23 Tokyo
    Copyright 2023, Kazuhiro SUZUKI
    Happy Testing!!

    View Slide