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
520
システムテスト自動化スクリプトのレビュー観点を挙げてみたの
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
600
カジュアル面談って、もっとカジュアルに していいの / informal session #jasstnano
pineapplecandy
0
300
アジャイルQA2年生が、過去の自分に伝えたいこと #テストラジオ
pineapplecandy
0
260
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
Product Management Conference -AI時代に進化するPdM-
kojima111
0
260
LLMエージェント時代に適応した開発フロー
hiragram
1
460
自社製CMSからmicroCMSへのリプレースがプロダクトグロースを加速させた話
nextbeatdev
0
310
7月のガバクラ利用料が高かったので調べてみた
techniczna
3
750
ここ一年のCCoEとしてのAWSコスト最適化を振り返る / CCoE AWS Cost Optimization devio2025
masahirokawahara
1
300
AIエージェントの開発に必須な「コンテキスト・エンジニアリング」とは何か──プロンプト・エンジニアリングとの違いを手がかりに考える
masayamoriofficial
0
470
役割は変わっても、変わらないもの 〜スクラムマスターからEMへの転身で学んだ信頼構築の本質〜 / How to build trust
shinop
0
120
Goss: Faiss向けの新しい本番環境対応 Goバインディング #coefl_go_jp
bengo4com
1
1.4k
kintone開発チームの紹介
cybozuinsideout
PRO
0
73k
Webアクセシビリティ入門
recruitengineers
PRO
3
1.3k
つくって納得、つかって実感! 大規模言語モデルことはじめ
recruitengineers
PRO
29
11k
広島銀行におけるAWS活用の取り組みについて
masakimori
0
160
Featured
See All Featured
Building an army of robots
kneath
306
46k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
185
54k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.5k
Unsuck your backbone
ammeep
671
58k
Fireside Chat
paigeccino
39
3.6k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
61k
Designing for humans not robots
tammielis
253
25k
Git: the NoSQL Database
bkeepers
PRO
431
65k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Six Lessons from altMBA
skipperchong
28
4k
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