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

システムテスト自動化スクリプトのレビュー観点を挙げてみたの

61cd8af33de206c39c875e3321e9c225?s=47 ぱいん
January 18, 2022

 システムテスト自動化スクリプトのレビュー観点を挙げてみたの

JaSST nano vol.8 (2022/1/18@Online)
https://jasst-nano.connpass.com/event/235252/

61cd8af33de206c39c875e3321e9c225?s=128

ぱいん

January 18, 2022
Tweet

More Decks by ぱいん

Other Decks in Technology

Transcript

  1. システムテスト自動化スクリプトの レビュー観点を挙げてみたの @JaSST nano Vol.8 2022/1/18 ぱいん 1

  2. サマリ 1. 開発経験を踏まえて、レビュー観点を整理してみた 2. 規定したテスト条件を実現し、期待通りの検証すること が合格ライン 3. 理想的には、初期からレビュー観点を整備できれば 最適だが、プロジェクトやテスト対象に応じて積み上げて いくのが現実的

    2
  3. 自己紹介 • ぱいん • 本業 – テストエンジニア@テスト会社 – 1児のパパ •

    社外活動など – JaSST Review実行委員 – JaSST Online実行委員 など • 趣味 – Twitter – Bリーグ鑑賞(川崎BTファン) 3
  4. 本日の発表のスコープ 4 [1]

  5. おことわり • こちらの資料は、ぱいん個人の考えです。会社や所属組織の考え ではありません • Q&Aはないので、Twitter #jasstnano でお願いします • 資料は公開します

    5 Speakerdeck ぱいん
  6. ぱいん的レビュー観点&比重 1. 検証方法(40点) 2. テスト条件(25点) 3. コードアーキテクチャ(15点) 4. 再実行可能性(10点) 5.

    リーダブルコード的なあれ(10点) 6 あああああああああああ 美しいコードであったとしても、 テストができていなければ不合格
  7. 1. 検証方法 • 理由:対象がテストコード=テスト実行を行うコードであるため • 判定方法の妥当性 – 想定した出力を判定条件に使っているか • 例1)文字列を判定

    (”このプランで予約”) • 例2)オブジェクトの存在を判定 (id=“reservation_plan”) • 例3)表示を判定 (画像判定) • 判定方法の安定性 – どういうパタンで落ちる可能性があるか – 判定の待ち時間の過不足 • 仕様で規定されている通りか • (仕様がない場合)無用に長く設定しすぎていないか 7
  8. 脱線1) 何をassertion (検証) するのか • 例) 手動テストでは無意識に以下の3つを検証している • 3つのチェックポイント 1.

    オブジェクトの存在を判定 2. 文字列を判定 (”このプランで予約”) 3. 表示のレイアウト、見切れを判定 • 自動テストにおいてはそれぞれ検証方法が異なる 1. オブジェクトの存在を判定 (id=“reserve_btn”があるか) 2. 文字列を判定 (”このプランで予約”とマッチするか) 3. 表示のレイアウト、見切れを判定 (画像判定など) 8 OK OK NG
  9. 2. テスト条件 • 理由: 期待どおりのテストの条件を設定する必要がある • テストケースに対する一致性 – ユーザ操作との一致を重視 •

    システムテストとしての役割を果たしているか – 明記されていないテスト条件が実装されているか • 言語 • ロケール • App version • 冗長なテストコードを作成していないか – 複数テストケースにまたがって同じコードがある場合、関数化する • Preconditionの簡潔性 – データ準備などで不要なテストステップを実装していないか • (Tips) テストに直接関係ないステップはAPIを使う (ユーザ作成) • (Tips) テスト対象に二段階認証回避するパスを準備しておく 9
  10. 待って! これってコードレビュー観点以前の話じゃない? 10

  11. 脱線2) 待って!これってコードレビュー観点以前の話じゃない? • その疑問は正しい! • これらの大半は、コード実装開始前に 済ませておきたいこと • 実際のところ、具体的な観点や観点の粒度は テスト対象、チームの状況による

    ⇨上流へフィードバックをかけて行くのが現実的 11 [2]
  12. 3. 再実行可能性 • 単一テストケースでの再実行可能性 – 再実行を妨げる処理 • 既存データの更新、削除 • ユーザプロファイルの更新

    • 他のテストケースへの影響 • 他のテストケースに依存していないか • 他のテストケースに依存されていないか 12
  13. 4. コードアーキテクチャ • 理由: 大人数での開発、規模拡大の際の効率性に影響する • setup, teardownは書かれているか • setup,

    teardown: 前処理、後処理で共通化したもの • 前提条件を戻す (ログアウト, キャッシュ削除 他) • エビデンス確保 (設定データ、スクリーンショット、ログ他) • エビデンスの取り方 • 起票するのに必要な箇所は残せているか • 実行時間が長すぎないか • (使用している場合) Page Object Moduleの呼び方が合っているか 13
  14. 5. リーダブルコード的なあれ • ←細かいことは読んでください • 命名規則 • 読みやすさ • コメント

    • 制御フロー • フォーマッタ適用 • 文法チェック • 例外処理 14 [3]
  15. まとめ • 開発経験を踏まえて、レビュー観点を整理してみた • 規定したテスト条件を実現し、期待通りの検証することが合格ライン – 合格ライン(当たり前品質)を満たした上で、規模やレベルに応じたアーキテクチャ整備を進める • 理想的には、初期からレビュー観点を整備できれば 最適だが、プロジェクトやテスト対象に応じて積み上げていくのが現実的

    – 開発者が習熟してくると、合格ラインのレビューは楽になる – レビュアーは安定性や運用性などに考慮した、より良いアーキテクチャに導いていく 15
  16. 参考文献、サイト No. Slide # ページ名 URL 1 4 テスト自動化研究会 -

    本会について https://sites.google.com/site/testautomationresearch/about 2 11 テスト自動化プロジェクトを支える技術と仕 組み, SpeakerDeck https://speakerdeck.com/yoshikiito/tesutozi-dong-hua- puroziekutowozhi-eruji-shu-toshi-zu-mi?slide=18 3 14 Dustin Boswell, Trevor Foucher著, 角征典訳, “リーダブルコード ――より良いコードを書 くためのシンプルで実践的なテクニック”, O’Reilly Books https://www.oreilly.co.jp/books/9784873115658/ いらすとや https://www.irasutoya.com/ 16