Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
システムテスト自動化スクリプトのレビュー観点を挙げてみたの
Search
ぱいん
January 18, 2022
Technology
0
410
システムテスト自動化スクリプトのレビュー観点を挙げてみたの
JaSST nano vol.8 (2022/1/18@Online)
https://jasst-nano.connpass.com/event/235252/
ぱいん
January 18, 2022
Tweet
Share
More Decks by ぱいん
See All by ぱいん
カジュアル面談って、もっとカジュアルに していいの / informal session #jasstnano
pineapplecandy
0
180
アジャイルQA2年生が、過去の自分に伝えたいこと #テストラジオ
pineapplecandy
0
160
PO,SMに送るテスト自動化の8原則に5箇条を添えて / scrumniigata2023
pineapplecandy
2
1.5k
E2Eテストのflakyと向き合う / stac2020
pineapplecandy
2
5.5k
しくじり先生ーアジャイルテスト自動化立ち上げ迷走記 #D3QA / Failure teaches success in automated testing development
pineapplecandy
1
3.1k
これからシステムテスト自動化を始める組織のための勉強会(公開用)
pineapplecandy
2
2.6k
#WACATE 2019夏_夜の分科会_情報交換会_公開用
pineapplecandy
0
1.2k
#オンライン飲み会 経験ベースで語るテストエンジニアのための英語術 Ver.0.190113
pineapplecandy
0
950
#WACATE 2018冬 夜の分科会「テストの困りごとを ぱいんとみんなで答える会」
pineapplecandy
0
350
Other Decks in Technology
See All in Technology
汎用ポリシー言語Rego + OPAと認可・検証事例の紹介 / Introduction Rego & OPA for authorization and validation
mizutani
1
190
TypescriptでのContextualな構造化ロギングと社内全体への導入
leveragestech
3
620
データベース05: SQL(2/3) 結合質問
trycycle
0
110
社内での継続的な機械学習勉強会の開催のコツ
yudai00
2
390
サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit
cybozuinsideout
PRO
9
37k
Databricksの生成AI戦略
taka_aki
1
380
5分で分かる(かもしれない) Vector engine for OpenSearch Serverless
tsukuboshi
1
430
RubyKaigi 2024 - Make Your Own Regex Engine!
makenowjust
1
180
シンプルなHITL機械学習と様々なタスクにおけるHITL機械学習
naohachi89
0
340
株式会社EventHub・エンジニア採用資料
eventhub
0
2.1k
使われないものを作るな!出口から作るデータ分析基盤 / Data Platform Development Starting from the User Needs
amaotone
16
4.9k
QA Engineer Life @ LINE
line_developers_tw
PRO
0
150
Featured
See All Featured
Documentation Writing (for coders)
carmenintech
60
4k
Pencils Down: Stop Designing & Start Developing
hursman
117
11k
How to Ace a Technical Interview
jacobian
273
22k
Visualization
eitanlees
137
14k
Adopting Sorbet at Scale
ufuk
69
8.6k
Building Adaptive Systems
keathley
32
1.9k
Debugging Ruby Performance
tmm1
70
11k
Designing for Performance
lara
601
67k
The Invisible Side of Design
smashingmag
294
49k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
Optimising Largest Contentful Paint
csswizardry
13
2.4k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
23
1.7k
Transcript
システムテスト自動化スクリプトの レビュー観点を挙げてみたの @JaSST nano Vol.8 2022/1/18 ぱいん 1
サマリ 1. 開発経験を踏まえて、レビュー観点を整理してみた 2. 規定したテスト条件を実現し、期待通りの検証すること が合格ライン 3. 理想的には、初期からレビュー観点を整備できれば 最適だが、プロジェクトやテスト対象に応じて積み上げて いくのが現実的
2
自己紹介 • ぱいん • 本業 – テストエンジニア@テスト会社 – 1児のパパ •
社外活動など – JaSST Review実行委員 – JaSST Online実行委員 など • 趣味 – Twitter – Bリーグ鑑賞(川崎BTファン) 3
本日の発表のスコープ 4 [1]
おことわり • こちらの資料は、ぱいん個人の考えです。会社や所属組織の考え ではありません • Q&Aはないので、Twitter #jasstnano でお願いします • 資料は公開します
5 Speakerdeck ぱいん
ぱいん的レビュー観点&比重 1. 検証方法(40点) 2. テスト条件(25点) 3. コードアーキテクチャ(15点) 4. 再実行可能性(10点) 5.
リーダブルコード的なあれ(10点) 6 あああああああああああ 美しいコードであったとしても、 テストができていなければ不合格
1. 検証方法 • 理由:対象がテストコード=テスト実行を行うコードであるため • 判定方法の妥当性 – 想定した出力を判定条件に使っているか • 例1)文字列を判定
(”このプランで予約”) • 例2)オブジェクトの存在を判定 (id=“reservation_plan”) • 例3)表示を判定 (画像判定) • 判定方法の安定性 – どういうパタンで落ちる可能性があるか – 判定の待ち時間の過不足 • 仕様で規定されている通りか • (仕様がない場合)無用に長く設定しすぎていないか 7
脱線1) 何をassertion (検証) するのか • 例) 手動テストでは無意識に以下の3つを検証している • 3つのチェックポイント 1.
オブジェクトの存在を判定 2. 文字列を判定 (”このプランで予約”) 3. 表示のレイアウト、見切れを判定 • 自動テストにおいてはそれぞれ検証方法が異なる 1. オブジェクトの存在を判定 (id=“reserve_btn”があるか) 2. 文字列を判定 (”このプランで予約”とマッチするか) 3. 表示のレイアウト、見切れを判定 (画像判定など) 8 OK OK NG
2. テスト条件 • 理由: 期待どおりのテストの条件を設定する必要がある • テストケースに対する一致性 – ユーザ操作との一致を重視 •
システムテストとしての役割を果たしているか – 明記されていないテスト条件が実装されているか • 言語 • ロケール • App version • 冗長なテストコードを作成していないか – 複数テストケースにまたがって同じコードがある場合、関数化する • Preconditionの簡潔性 – データ準備などで不要なテストステップを実装していないか • (Tips) テストに直接関係ないステップはAPIを使う (ユーザ作成) • (Tips) テスト対象に二段階認証回避するパスを準備しておく 9
待って! これってコードレビュー観点以前の話じゃない? 10
脱線2) 待って!これってコードレビュー観点以前の話じゃない? • その疑問は正しい! • これらの大半は、コード実装開始前に 済ませておきたいこと • 実際のところ、具体的な観点や観点の粒度は テスト対象、チームの状況による
⇨上流へフィードバックをかけて行くのが現実的 11 [2]
3. 再実行可能性 • 単一テストケースでの再実行可能性 – 再実行を妨げる処理 • 既存データの更新、削除 • ユーザプロファイルの更新
• 他のテストケースへの影響 • 他のテストケースに依存していないか • 他のテストケースに依存されていないか 12
4. コードアーキテクチャ • 理由: 大人数での開発、規模拡大の際の効率性に影響する • setup, teardownは書かれているか • setup,
teardown: 前処理、後処理で共通化したもの • 前提条件を戻す (ログアウト, キャッシュ削除 他) • エビデンス確保 (設定データ、スクリーンショット、ログ他) • エビデンスの取り方 • 起票するのに必要な箇所は残せているか • 実行時間が長すぎないか • (使用している場合) Page Object Moduleの呼び方が合っているか 13
5. リーダブルコード的なあれ • ←細かいことは読んでください • 命名規則 • 読みやすさ • コメント
• 制御フロー • フォーマッタ適用 • 文法チェック • 例外処理 14 [3]
まとめ • 開発経験を踏まえて、レビュー観点を整理してみた • 規定したテスト条件を実現し、期待通りの検証することが合格ライン – 合格ライン(当たり前品質)を満たした上で、規模やレベルに応じたアーキテクチャ整備を進める • 理想的には、初期からレビュー観点を整備できれば 最適だが、プロジェクトやテスト対象に応じて積み上げていくのが現実的
– 開発者が習熟してくると、合格ラインのレビューは楽になる – レビュアーは安定性や運用性などに考慮した、より良いアーキテクチャに導いていく 15
参考文献、サイト 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