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
fukabori.fm 出張版: 売上高617億円と高稼働率を陰で支えた社内ツール開発のあれこれ話 / 20250704 Yoshimasa Iwase & Tomoo Morikawa
shift_evolve
PRO
2
7.8k
NewSQLや分散データベースを支えるRaftの仕組み - 仕組みを理解して知る得意不得意
hacomono
PRO
2
170
20250707-AI活用の個人差を埋めるチームづくり
shnjtk
4
3.9k
関数型プログラミングで 「脳がバグる」を乗り越える
manabeai
1
190
ゼロからはじめる採用広報
yutadayo
3
950
MUITにおける開発プロセスモダナイズの取り組みと開発生産性可視化の取り組みについて / Modernize the Development Process and Visualize Development Productivity at MUIT
muit
1
17k
赤煉瓦倉庫勉強会「Databricksを選んだ理由と、絶賛真っ只中のデータ基盤移行体験記」
ivry_presentationmaterials
2
370
タイミーのデータモデリング事例と今後のチャレンジ
ttccddtoki
6
2.4k
Flutter向けPDFビューア、pdfrxのpdfium WASM対応について
espresso3389
0
130
United Airlines Customer Service– Call 1-833-341-3142 Now!
airhelp
0
170
KubeCon + CloudNativeCon Japan 2025 Recap by CA
ponkio_o
PRO
0
300
生まれ変わった AWS Security Hub (Preview) を紹介 #reInforce_osaka / reInforce New Security Hub
masahirokawahara
0
470
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.7k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.4k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
Code Review Best Practice
trishagee
69
18k
Thoughts on Productivity
jonyablonski
69
4.7k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Facilitating Awesome Meetings
lara
54
6.4k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
Designing for Performance
lara
610
69k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
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