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
510
システムテスト自動化スクリプトのレビュー観点を挙げてみたの
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 ぱいん
テストについて相談を受けたときに いつもしていること (公開用) #テストラジオ
pineapplecandy
0
560
カジュアル面談って、もっとカジュアルに していいの / informal session #jasstnano
pineapplecandy
0
300
アジャイルQA2年生が、過去の自分に伝えたいこと #テストラジオ
pineapplecandy
0
250
PO,SMに送るテスト自動化の8原則に5箇条を添えて / scrumniigata2023
pineapplecandy
2
1.9k
E2Eテストのflakyと向き合う / stac2020
pineapplecandy
2
6k
しくじり先生ーアジャイルテスト自動化立ち上げ迷走記 #D3QA / Failure teaches success in automated testing development
pineapplecandy
1
3.4k
これからシステムテスト自動化を始める組織のための勉強会(公開用)
pineapplecandy
2
3k
#WACATE 2019夏_夜の分科会_情報交換会_公開用
pineapplecandy
0
1.3k
#オンライン飲み会 経験ベースで語るテストエンジニアのための英語術 Ver.0.190113
pineapplecandy
0
1.1k
Other Decks in Technology
See All in Technology
OpenTelemetryセマンティック規約の恩恵とMackerel APMにおける活用例 / SRE NEXT 2025
mackerelio
2
1.3k
成長し続けるアプリのためのテストと設計の関係、そして意思決定の記録。
sansantech
PRO
0
140
United airlines®️ USA Contact Numbers: Complete 2025 Support Guide
unitedflyhelp
0
330
Operating Operator
shhnjk
1
640
大量配信システムにおけるSLOの実践:「見えない」信頼性をSLOで可視化
plaidtech
PRO
0
260
Lufthansa ®️ USA Contact Numbers: Complete 2025 Support Guide
lufthanahelpsupport
0
230
DatabricksにOLTPデータベース『Lakebase』がやってきた!
inoutk
0
150
TLSから見るSREの未来
atpons
2
190
サイバーエージェントグループのSRE10年の歩みとAI時代の生存戦略
shotatsuge
4
700
Rethinking Incident Response: Context-Aware AI in Practice
rrreeeyyy
1
230
AIの全社活用を推進するための安全なレールを敷いた話
shoheimitani
2
610
shake-upを科学する
rsakata
7
900
Featured
See All Featured
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Agile that works and the tools we love
rasmusluckow
329
21k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
Docker and Python
trallard
44
3.5k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Embracing the Ebb and Flow
colly
86
4.7k
The Cult of Friendly URLs
andyhume
79
6.5k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Optimizing for Happiness
mojombo
379
70k
Designing for humans not robots
tammielis
253
25k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
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