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

Transcript

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

   View Slide

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

   View Slide

3. 自己紹介
   • ぱいん
   • 本業
   – テストエンジニア＠テスト会社
   – 1児のパパ
   • 社外活動など
   – JaSST Review実行委員
   – JaSST Online実行委員 など
   • 趣味
   – Twitter
   – Bリーグ鑑賞(川崎BTファン)
   3
   

   View Slide

4. 本日の発表のスコープ
   4
   [1]
   

   View Slide

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

   View Slide

6. ぱいん的レビュー観点＆比重
   1. 検証方法（40点）
   2. テスト条件（25点）
   3. コードアーキテクチャ（15点）
   4. 再実行可能性（10点）
   5. リーダブルコード的なあれ（10点）
   6
   あああああああああああ
   美しいコードであったとしても、
   テストができていなければ不合格
   

   View Slide

7. 1. 検証方法
   • 理由：対象がテストコード＝テスト実行を行うコードであるため
   • 判定方法の妥当性
   – 想定した出力を判定条件に使っているか
   • 例1)文字列を判定 (”このプランで予約”)
   • 例2)オブジェクトの存在を判定 (id=“reservation_plan”)
   • 例3)表示を判定 (画像判定)
   • 判定方法の安定性
   – どういうパタンで落ちる可能性があるか
   – 判定の待ち時間の過不足
   • 仕様で規定されている通りか
   • （仕様がない場合）無用に長く設定しすぎていないか
   7
   

   View Slide

8. 脱線1) 何をassertion (検証) するのか
   • 例) 手動テストでは無意識に以下の3つを検証している
   • 3つのチェックポイント
   1. オブジェクトの存在を判定
   2. 文字列を判定 (”このプランで予約”)
   3. 表示のレイアウト、見切れを判定
   • 自動テストにおいてはそれぞれ検証方法が異なる
   1. オブジェクトの存在を判定 (id=“reserve_btn”があるか)
   2. 文字列を判定 (”このプランで予約”とマッチするか)
   3. 表示のレイアウト、見切れを判定 (画像判定など)
   8
   OK
   OK
   NG
   

   View Slide

9. 2. テスト条件
   • 理由: 期待どおりのテストの条件を設定する必要がある
   • テストケースに対する一致性
   – ユーザ操作との一致を重視
   • システムテストとしての役割を果たしているか
   – 明記されていないテスト条件が実装されているか
   • 言語
   • ロケール
   • App version
   • 冗長なテストコードを作成していないか
   – 複数テストケースにまたがって同じコードがある場合、関数化する
   • Preconditionの簡潔性
   – データ準備などで不要なテストステップを実装していないか
   • (Tips) テストに直接関係ないステップはAPIを使う (ユーザ作成)
   • (Tips) テスト対象に二段階認証回避するパスを準備しておく
   9
   

   View Slide

10. 待って！
    これってコードレビュー観点以前の話じゃない？
    10
    

    View Slide

11. 脱線2)
    待って！これってコードレビュー観点以前の話じゃない？
    • その疑問は正しい！
    • これらの大半は、コード実装開始前に
    済ませておきたいこと
    • 実際のところ、具体的な観点や観点の粒度は
    テスト対象、チームの状況による
    ⇨上流へフィードバックをかけて行くのが現実的
    11
    [2]
    

    View Slide

12. 3. 再実行可能性
    • 単一テストケースでの再実行可能性
    – 再実行を妨げる処理
    • 既存データの更新、削除
    • ユーザプロファイルの更新
    • 他のテストケースへの影響
    • 他のテストケースに依存していないか
    • 他のテストケースに依存されていないか
    12
    

    View Slide

13. 4. コードアーキテクチャ
    • 理由: 大人数での開発、規模拡大の際の効率性に影響する
    • setup, teardownは書かれているか
    • setup, teardown: 前処理、後処理で共通化したもの
    • 前提条件を戻す （ログアウト, キャッシュ削除 他)
    • エビデンス確保 (設定データ、スクリーンショット、ログ他)
    • エビデンスの取り方
    • 起票するのに必要な箇所は残せているか
    • 実行時間が長すぎないか
    • (使用している場合) Page Object Moduleの呼び方が合っているか
    13
    

    View Slide

14. 5. リーダブルコード的なあれ
    • ←細かいことは読んでください
    • 命名規則
    • 読みやすさ
    • コメント
    • 制御フロー
    • フォーマッタ適用
    • 文法チェック
    • 例外処理
    14
    [3]
    

    View Slide

15. まとめ
    • 開発経験を踏まえて、レビュー観点を整理してみた
    • 規定したテスト条件を実現し、期待通りの検証することが合格ライン
    – 合格ライン（当たり前品質）を満たした上で、規模やレベルに応じたアーキテクチャ整備を進める
    • 理想的には、初期からレビュー観点を整備できれば
    最適だが、プロジェクトやテスト対象に応じて積み上げていくのが現実的
    – 開発者が習熟してくると、合格ラインのレビューは楽になる
    – レビュアーは安定性や運用性などに考慮した、より良いアーキテクチャに導いていく
    15
    

    View Slide

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
    

    View Slide