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
ソフトウェアテスト 2022 / Software Testing 2022
Search
akihisa1210
June 17, 2022
Technology
1
8.4k
ソフトウェアテスト 2022 / Software Testing 2022
サイボウズの開発運用研修で使用した資料です。
akihisa1210
June 17, 2022
Tweet
Share
More Decks by akihisa1210
See All by akihisa1210
推し書籍📚 / Books and a QA Engineer
ak1210
0
160
アジャイルな開発チームでテスト戦略の話は誰がする? / Who Talks About Test Strategy?
ak1210
2
1.2k
Four Keysに基づくリリースプロセス改善とその成果 / Release process improvement based on the Four Keys and its results
ak1210
0
1.4k
独立したQA担当者か開発チームか? あるプロダクトチームのQA体制の変遷 / Independent QA or Dev Team
ak1210
0
1.6k
E2E自動テスト導入・運用をめぐる先入観と実際に起きたこと / Preconceptions and What Happened with E2E Testing
ak1210
7
3.1k
テストコードを書きたいけどテスト対象がない。どうする? / What to do to write test?
ak1210
2
1k
ここからはじめるスクラムQA(増補改訂版) / Getting started with QA in Scrum (revised)
ak1210
2
990
ここからはじめるスクラムQA / Getting started with QA in Scrum
ak1210
2
1.3k
「開発チーム」とQA /"Development Team" and QA
ak1210
1
8.8k
Other Decks in Technology
See All in Technology
PHPでResult型やってみよう
higaki_program
0
190
Shadow DOMとセキュリティ - 光と影の境界を探る / Shibuya.XSS techtalk #13
masatokinugawa
0
270
P2P通信の標準化 WebRTCを知ろう
faithandbrave
6
2.3k
Amazon CloudWatchのメトリクスインターバルについて / Metrics interval matters
ymotongpoo
3
210
「手を動かした者だけが世界を変える」ソフトウェア開発だけではない開発者人生
onishi
11
4.2k
QuickBooks®️ Customer®️ USA Contact Numbers: Complete 2025 Support Guide
qbsupportinfo
0
110
公開初日に個人環境で試した Gemini CLI 体験記など / Gemini CLI実験レポート
you
PRO
3
320
PdM業務における使い分け
shinshiro
0
590
Wasmで社内ツールを作って配布しよう
askua
0
120
AIコードアシスタントとiOS開発
jollyjoester
1
230
FAST導入1年間のふりかえり〜現実を直視し、さらなる進化を求めて〜 / Review of the first year of FAST implementation
wooootack
1
120
DatabricksのOLTPデータベース『Lakebase』に詳しくなろう!
inoutk
0
110
Featured
See All Featured
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.6k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Building an army of robots
kneath
306
45k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
How to train your dragon (web standard)
notwaldorf
96
6.1k
The Cult of Friendly URLs
andyhume
79
6.5k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Transcript
ソフトウェアテスト 2022-05-19 サイボウズ開運研修 小山晃久(Garoon/生産性向上)
ソフトウェアテストの位置づけ 「ソフトウェアテストはソフトウェアの品質を評価し、運用環境でソフト ウェアの故障が発生するリスクを低減する1つの手段である。」 (JSTQB FL p.15) JSTQB FL 1.1
よいソフトウェアテストをやっていくには? よいソフトウェアテスト 適切な情報を、適切なタイミングで、適切な相手にフィードバックする
適切な情報 テストによってさまざまな情報を得ることができる テストに抜け・漏れがあり、適切な情報を取得できないのは避けたい
適切なタイミング 重大な不具合は早くフィードバックしたい
適切な相手 テストで得られた情報が欲しいのは誰だろう?
どうやってよいテストを実現するか テストは「テスト実行」だけからなるわけではない
テスト活動とテストプロセス テスト計画 テストのモニタリングとコントロール テスト分析 テスト設計 テスト実装 テスト実行 テスト完了 今回は、テスト分析~テスト実行を扱う JSTQB
FL 1.4
1. 何をテストすればよいだろう か?––––テスト分析
機能のテストを考えてみよう 題材: 「Garoon のスケジュールのコメントで、参加者全員宛の宛先 指定をできるようにする」機能 機能のイメージは次のページにあります
None
何をテストしよう? 仕様通りであること?
「仕様通り」の罠 仕様通りでも、ユーザーの課題を解決していないことがある Verification(正しく作っているか?)だけでなく、Validation(正しい ものを作っているか?)も重要 JSTQB FL 1.1
ユーザーや関わる人は誰だろう? 今作っているものは誰のためのもの? その人はそれをどうやって使 う? 直接のユーザー以外にもこれに関わる人はいる?
リスク分析 今作っているものが上手く動かなかったとき、何が起こるだろう?
テスト対象は何からなる? 図示してみる 機能以外にも、注目すべき点があるかも
仕様 どんな機能? 何ができる? 仕様に不足はない?
機能の周辺 影響があるところは? 過去の不具合は?
まとめ: テスト分析 何をテストするのかを決める そのために、必要な情報を集め、分析する
2. どうテストすればよいだろう か?––––テスト設計
欠陥の偏在 欠陥は特定の箇所に集中していることが多い リスクに応じてテストの優先度や細かさを変えていくとよい JSTQB FL 1.3
全数テストは不可能 すべての事前条件、入力を網羅するのは難しい テスト技法を使って、テストすべきことを絞り込んでいく JSTQB FL 1.3
テストを設計しよう どのようにテストする領域を分ける? どの領域をどの優先度で行う? どうやってテストケースを作る? 自動でやる? 手動でやる?
テストする領域の分割 必要であれば、テスト分析結果を踏まえて領域を分けていく 参加者全員宛の宛先指定をできるようにする機能の例 UI のテスト、通知のテスト、ユースケースに従ったテストなどに分けられそう それぞれのテストで、共通する観点もあれば異なる観点もある
テスト技法によるテストケースの絞り込み 全数テストは不可能なので、テストケースを実現可能な数に絞り込む 必要がある ただし、重要なケースが漏れるのは避けたい こういう場合にテスト技法が使える
テスト技法の例:同値分割法 同等に処理されると想定したデータをひとまとまり(同値クラス)にし て扱う 例: パスワードは8文字以上100文字以下 0や負の値なども、無効同値クラスと扱ってよい? 8 7 100 101
有効 無効 無効 JSTQB FL 4.2.1
テスト技法の例:境界値分析 同値クラスの最小値、最大値(境界値)を使ってテストする 例: パスワードは8文字以上100文字以下 8 7 100 101 JSTQB FL
4.2.2
テスト技法は他にも色々 デシジョンテーブルテスト、状態遷移テスト、ユースケーステスト、 All Pair法、…… 技法を使う理由を説明できるのが重要 JSTQB FL 4
ハイレベルテストケース 具体的な入力値と期待結果の値が記載されていないテストケース 対義語: ローレベルテストケース(具体的な値や手順が記載されて おり、実行できるテストケース) JSTQB FL 1.4.3
まとめ: テスト設計 テスト分析を踏まえつつ、何をどうテストするのか決める 欠陥が偏在することや、全数テストが不可能であることを踏まえて、テ ストの優先度や、テストケースの粒度も決める
3. テストを実行するためには何 が必要か?––––テスト実装
テストケース 設計したテストを、実施可能な形にする 形式は様々(表、チェックリスト、プレーンテキスト、……) テスト分析やテスト設計の成果物に基づいて作成する
テスト環境 正確なバージョンのテスト環境を構築する 自動化がおすすめ
テスト自動化 テストプロセスに割り当てるなら、テスト自動化の実装もここ
まとめ: テスト実装 テストを実行可能な状態にする いきなりここからやると、テストケースの抜け・漏れや重複が発生する かも
4. 探索とフィードバック––––テ スト実行
いざテスト実行 作成したテストケースを実行していく
テスト実行のテクニック 楽できないか考える 細かいことでもメモを残す 違和感やちょっと気になることを大事にする
想定外の事態が起こったら 不具合かどうか確認 適切なタイミングでのフィードバック ブロック要素の管理
不具合報告 チームごとの不具合管理方法に従って不具合を管理 BTS (Bug Tracking System) に不具合を登録するなど 不具合の再現に必要十分な手順を記載する JSTQB FL
5.6
テスト実行 テストを実際に実行するフェーズ ソフトウェアテストはこのフェーズだけから成り立つわけではない
ソフトウェア開発ライフサイク ルとテスト
ソフトウェア開発ライフサイクル 例: スクラム
スクラムイベントとテスト スクラムイベントに合わせて、どのようにテストを行っていくか? 以下は一例です
リファインメント テストのことを考えながらバックログを見てみる(テスト分析) ユーザーが実際に行う操作は? テストしやすい? 例外処理は考慮されている?
スプリントプランニング 何を作るかの認識を合わせつつ、テスト設計を行ってみる(テスト分 析、テスト設計) 実装に関する議論を聞きながら、テストすべき箇所やテストしなくてよい箇所 を考える/聞く テストの観点を出してみる(何をテストするか) テストケースの型を考えてみる(どうテストするか)
スプリント内 実装の状況に応じてテスト設計をアップデート(テスト設計) テスト設計に基づきテストケースを作成(テスト実装) 手動テストするテストケースの特定 自動テストの作成 実装が完了したらテスト開始(テスト実行) 不具合が出たらすぐにフィードバック
まとめ
まとめ 適切な内容を、適切なタイミングで、適切な相手にフィードバックし ていくために、 テスト分析で何をテストするのか考え、テスト設計でどうテストするの か考え、テスト実装でテストを実行可能にし、テストを実行しよう テスト計画 テストのモニタリングとコントロール テスト分析 テスト設計 テスト実装
テスト実行 テスト完了
参考文献 [JSTQB FL] ISTQB著、JSTQB訳、「ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03」、
2021 https://jstqb.jp/dl/JSTQB- SyllabusFoundation_Version2018V31.J03.pdf