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
400
システムテスト自動化スクリプトのレビュー観点を挙げてみたの
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
130
アジャイル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
Gradle Build Scanを使ってビルドのことを知ろう potatotips #87
tomorrowkey
2
160
コードファーストの考え方。 Amplify Gen2から学ぶAWS次世代のWeb開発体験
yoshiitaka
2
370
社内アプリで Cloudflare D1を プロダクト運用してみた体験談(Tokyo)
haochenx
0
120
EMとして2023年度に頑張ったこと / What we did well in FY2023 as a EM
pauli
1
260
プロンプトエンジニアリングでがんばらない-Agentic Workflow へ-近藤憲児
kenjikondobai
6
1.2k
.NET Profiler in 2024.
kkamegawa
2
1.7k
ExaDB-D dbaascli で出来ること
oracle4engineer
PRO
0
2.1k
今さら聞けないDocker入門 〜 Dockerfileのベストプラクティス編
devops_vtj
16
4.2k
Além do else! Categorizando Pokemóns com Pattern Matching no JavaScript
wmsbill
0
710
成長をサポートするピープルマネジメントのやり方
sioncojp
9
1.2k
今年のRubyKaigiはProfiler Year🤘
osyoyu
0
420
Android Target SDK 35 (Android 15) 対応の概要
akkie76
0
160
Featured
See All Featured
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
245
20k
The Cost Of JavaScript in 2023
addyosmani
20
3.9k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
14
1.5k
Fireside Chat
paigeccino
22
2.6k
Music & Morning Musume
bryan
41
5.6k
Building Effective Engineering Teams - LeadDev
addyosmani
31
1.9k
Learning to Love Humans: Emotional Interface Design
aarron
267
39k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
18
6.9k
Building Adaptive Systems
keathley
32
1.9k
Why You Should Never Use an ORM
jnunemaker
PRO
51
8.7k
Atom: Resistance is Futile
akmur
260
25k
Building Flexible Design Systems
yeseniaperezcruz
320
37k
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