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
ソフトウェアテスト2025
Search
Cybozu
PRO
July 06, 2025
0
18
ソフトウェアテスト2025
Cybozu
PRO
July 06, 2025
Tweet
Share
More Decks by Cybozu
See All by Cybozu
AIツール開発ワークショップ(Dify)
cybozuinsideout
PRO
2
55
モバイル
cybozuinsideout
PRO
0
21
Git/GitHub を使う上で知っておくと嬉しいかも Tips
cybozuinsideout
PRO
0
45
GitHub Copilot活用
cybozuinsideout
PRO
0
34
ソフトウェアライセンス
cybozuinsideout
PRO
0
19
エンジニアのためのアウトプット講座 〜知識をシェアするはじめの一歩〜
cybozuinsideout
PRO
0
26
Docker入門
cybozuinsideout
PRO
0
22
セキュリティ
cybozuinsideout
PRO
0
17
暗号
cybozuinsideout
PRO
0
11
Featured
See All Featured
Building an army of robots
kneath
306
45k
KATA
mclloyd
30
14k
It's Worth the Effort
3n
185
28k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Faster Mobile Websites
deanohume
307
31k
Agile that works and the tools we love
rasmusluckow
329
21k
Embracing the Ebb and Flow
colly
86
4.7k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
RailsConf 2023
tenderlove
30
1.1k
Transcript
25年度 開運研修 ソフトウェアテスト CyDE-C QA 早川 1
2 01 02 03 04 ソフトウェアテスト ソフトウェアテストの7原則 テストプロセス テスト設計とテスト技法 目
次
ソフトウェアテスト 3
JSTQB (Japan Software Testing Qualifications Board) 日本のソフトウェアテスト技術者資格を認定する運営組織 参考 : https://jstqb.jp/committee.html
ソフトウェアテストとは? 4 ソフトウェアテスト
> ソフトウェアテストは、欠陥を発見し、ソフトウェアアーティファクトの品質を評価するための一連の 活動である。これらアーティファクトは、テストをする際のテスト対象である。 (JSTQB FL) ソフトウェアテストとは? 5 ソフトウェアテスト
> ソフトウェアテストは、欠陥を発見し、ソフトウェアアーティファクトの品質を評価するための一連の 活動である。これらアーティファクトは、テストをする際のテスト対象である。 (JSTQB FL) 「動作するか?」だけでなく 「要件を満たしているか?」「ユーザーにとって使いやすいか?」も観点に含まれる ソフトウェアテストとは? 6 ソフトウェアテスト
• 単体テスト(ユニットテスト、コンポーネントテスト) • 個々のコンポーネントやモジュールが正しく動作するかを確認 • 結合テスト(インテグレーションテスト) • 複数のコンポーネントが連携して正しく動作するかを確認 • 総合テスト(システムテスト)
• システム全体が要件を満たしているかを確認 • 受け入れテスト(ユーザーアクセプタンステスト) • システム全体が要件を満たしているかを確認 ソフトウェアテストの種類 7 ソフトウェアテスト
ソフトウェアテストの種類を説明するモデル : V字モデル 8 ソフトウェアテスト 引用:https://webrage.jp/techblog/v_shaped_mode/
ソフトウェアテストを行うタイミング 9 ソフトウェアテスト Q. ソフトウェアテストは、 ソフトウェアが出来上がるまで テストできないのでしょうか?
ソフトウェアテストを行うタイミング 10 ソフトウェアテスト Q. ソフトウェアテストは、 ソフトウェアが出来上がるまで テストできないのでしょうか? A.ソフトウェアが出来上がる前に、 ドキュメントから欠陥を見つけるテ スト(レビュー)があります!
• 静的テスト • ソフトウェアを実行せずに行うテスト • 要件定義書や仕様書、設計書などのドキュメントから欠陥を見つけるテスト • 例 • コードレビュー
• 静的解析 • 動的テスト • ソフトウェアを実際に実行して行うテスト • 例 • 単体テスト • 結合テスト • 統合テスト • 受け入れテスト ソフトウェアテストを行うタイミング 11 ソフトウェアテスト
欠陥の早期発見 • 静的テストをソフトウェアを動かすテスト(動的テスト)の前から行うことで、欠陥を早期発見 • 修正コストが大幅に削減 • 後期に発見される欠陥は修正にコストがかかる • 作業成果物の更新や確認 •
影響範囲の調査 • 再テスト • 静的テストで早期発見した欠陥は、欠陥箇所のみを修正するだけで完了する場合も • 開発プロセスの早い段階で行う単体テストや結合テストも大事!! ソフトウェアテストを行うタイミング 12 ソフトウェアテスト
ソフトウェアテストの7原則 13
1. テストは欠陥があることは示せるが、欠陥がないことは示せない 2. 全数テストは不可能 3. 早期テストで時間とコストを節約 4. 欠陥の偏在 5. テストの弱化
6. テストはコンテキスト次第 7. 「欠陥ゼロ」の落とし穴 ソフトウェアテストの7原則 14 ソフトウェアテストの7原則
1. テストは欠陥があることは示せるが、欠陥がないことは示せない • 欠陥が見つからないとしても、テスト対象の正しさを証明できない 2. 全数テストは不可能 • すべての事前条件、入力を網羅するのは難しい • テストすべき箇所絞り込む必要がある
3. 早期テストで時間とコストを節約 • 早期に検出することで手戻りが少なくなる 4. 欠陥の偏在 • 欠陥は特定の箇所に集中する • リスクに応じてテストの優先度や細かさを変えていくとよい ソフトウェアテストの7原則 15 ソフトウェアテストの7原則
5. テストの弱化 • 同じテストを繰り返すと新たな欠陥を検出しずらくなる場合がある • ※ 自走化されたリグレッションテストなど、繰り返すことで意味があるものもある • テストとテストデータを入れ替える •
新規でテストを作成する 6. テストはコンテキスト次第 • 必ず適用できるテストは存在しない 7. 「欠陥ゼロ」の落とし穴 • バグが0でも、ユーザーのニーズや期待を満たさないシステムになることもある。 ソフトウェアテストの7原則 16 ソフトウェアテストの7原則
1. テストは欠陥があることは示せるが、欠陥がないことは示せない 2. 全数テストは不可能 3. 早期テストで時間とコストを節約 4. 欠陥の偏在 5. テストの弱化
6. テストはコンテキスト次第 7. 「欠陥ゼロ」の落とし穴 ソフトウェアテストの7原則 17 ソフトウェアテストの7原則
テストプロセス 18
「テスト実行」だけがテストではない。 > テストに関するよくある誤解の 1 つは、テストはテスト実行(すなわち、ソフトウェアを実行しテスト 結果を確認する)だけだというものである。 しかし、ソフトウェアテストには他の活動も含まれる。 そし て、ソフトウェア開発ライフサイクルと整合させなければばらない。 (JSTQB
FL) テスト実行以外にも様々な活動が... • どんなテストをするか計画を立る • テストに必要なデータや環境を準備する • テストの結果を分析 テストはソフトウェア開発のプロセス全体と連携して進める テストに関するよくある誤解 19 テストプロセス
• テスト計画 • テスト分析 • テスト設計 • テスト実装 • テスト実行
• テスト完了 • テストのモニタリングとコントロール ソフトウェアテストのプロセス 20 テストプロセス
「何を」「いつまでに」「どのように」テストするかを計画する • テストの目的と範囲の明確化 • 何を • スケジュール管理 • いつまでに •
リソースの最適化 • どのように • リスクの特定と対策 • 事前に分かったものは、事前に対策 • メトリクスの計画 • モニタリングする測定基準 (ヘルス情報や、パフォーマンス情報)を計画 テスト計画 21 テストプロセス
• モニタリングの目的 • テスト進捗の把握 • 問題の早期発見 • リソースの最適化 • コントロールの目的
• テストプロセスの調整(見直し) • リスクの管理 • 品質基準の維持 テストプロセスの継続的な改善を図る テストのモニタリングとコントロール 22 テストプロセス
「何を」「いつ」テストするかを決定する • テストベース(機能や仕様、影響範囲などの必要な情報)を収集し、分析を行う • 分析を行うことで、仕様や設計の不備に気づくことも → 静的テスト 分析結果を元に • ソフトウェアの何をテストするかを決定
• いつ(どの様な優先順位で)テストをするかを決定 テスト分析 23 テストプロセス
テスト分析を踏まえ、何をどうテストするのかを決定する • 具体的な入力値と期待結果が記載されていない抽象的なテストケース(ハイレベルテストケース)の作成 • テストの全体像の把握 • そのテストの必要性の把握 • テスト技法を使用し、より正確に、効率的にテストを作成 →
テスト技法の詳細は、次章で! • 対象テストの実行方法の決定 • 自動テスト • 手動テスト テスト設計 24 テストプロセス
テスト設計で作成した抽象的なテストケースを、より具体的に • テスト設計で作成したハイレベルテストケースから、より具体的なローレベルテストケースを作成 • テストの実施が可能な状態にする • テストケースの手順を明確にする • 効率よくテストを実行できる順序・方法はないか? •
テスト環境の準備 • テスト環境の構築 • テストに必要な、スクリプトやデータの準備 • テスト自動化 • 自動テストを実装 テスト実装 25 テストプロセス
テスト実装で作成したテストを実行する • テストケースの実行 • 手動テスト・自動テストの実行 • 記録を残す • 細かなことでもログを残すと、不足の事態に対応できることも •
不具合の報告 • 不具合の再現に必要な情報を報告する • どのような条件で • どのような問題が発生するか • 不具合が修正されたら、再度テストする テスト実行 26 テストプロセス
• テストで得られた情報を集め、今後のテストにどう活かすのかを検討する • テストで使用した環境の整備を行う テスト完了 27 テストプロセス
• テスト計画 • テスト分析 • テスト設計 • テスト実装 • テスト実行
• テスト完了 • テストのモニタリングとコントロール ソフトウェアテストのプロセス 28 テストプロセス
テスト設計とテスト技法 29
JSTQBでは、ソフトウェアをテストする方法をいくつかに分類しています • ブラックボックステスト • ホワイトボックステスト • 経験ベースのテスト テスト技法 30 テスト設計とテスト技法
• ブラックボックステスト • ソフトウェアの内部処理は気にせず、操作とその結果だけを見る • ソフトウェアが外部仕様通りに作成されているかを確認する • 利用者側の目線で行うテスト • ブラックボックステストの例
• 同値分割法 • 境界値分析 • デシジョンテーブルテスト • 状態遷移テスト テスト技法 31 テスト設計とテスト技法
• ホワイトボックステスト • ソフトウェアの内部構造(ソースコード、内部仕様など)をもとに行う • プログラムが想定通りに動いているかを確認する • 作り手側の目線で行うテスト • ホワイトボックステストの例
• ステートメントテスト • ブランチテスト テスト技法 32 テスト設計とテスト技法
• 経験ベースのテスト • 過去の経験を活かして、特定の問題が起こりやすい部分を重点的にチェックする • テスト担当者の知識や経験を活かして行うテスト • 経験ベースのテストの例 • エラー推測
• 探索的テスト • チェックリストベースドテスト テスト技法 33 テスト設計とテスト技法
• ブラックボックステスト • 内部構造を見ずに外部からの動作を確認するテスト • ホワイトボックステスト • 内部構造を詳細に分析するテスト • 経験ベースのテスト
• 知識と経験を活かしたテスト テスト技法 34 テスト設計とテスト技法
テスト対象 • .com ログイン画面 のパスワード入力フィールド テスト設計 35 テスト設計とテスト技法 各アプリにアクセス
テスト対象 • .com ログイン画面 のパスワード入力フィールド テスト目的 • .com ログイン画面で、パスワードフィールドに文字列を入力し、 入力内容に応じてログインができることを確認する
テスト設計 36 テスト設計とテスト技法
テスト対象 • .com ログイン画面 のパスワード入力フィールド テスト目的 • .com ログイン画面で、パスワードフィールドに文字列を入力し、 入力内容に応じてログインができることを確認する
仕様 • パスワードの最小文字数 : 8文字 • パスワードの最大文字数 : 100文字 テスト設計 37 テスト設計とテスト技法
同値分割法 38 テスト設計とテスト技法 同等に処理されることが想定されるデータをひとまとまりとして扱う 今回の仕様 • パスワードの最小文字数 : 8文字 •
パスワードの最大文字数 : 100文字
境界値分析 39 テスト設計とテスト技法 同値パーティションの 境界 (最小値、最大値) を確認する 今回の仕様 • パスワードの最小文字数
: 8文字 • パスワードの最大文字数 : 100文字
テスト対象 • .com ログイン画面 のパスワード入力フィールド テスト目的 • .com ログイン画面で、パスワードフィールドに文字列を入力し、 入力内容に応じてログインができることを確認する
仕様 • パスワードの最小文字数 : 8文字 • パスワードの最大文字数 : 100文字 テスト設計 40 テスト設計とテスト技法
試験観点 • 以下のパターンの場合、ログインが成功すること • パスワードが8文字以上、100文字以下の場合 • 以下のパターンの場合、ログインが失敗すること • パスワードが7文字以下の場合 •
パスワードが101文字以上の場合 テスト設計 41 テスト設計とテスト技法
• 以下のパターンの場合、ログインが成功すること • パスワードが8文字以上、100文字以下の場合 (8文字・50文字・100文字) 手順 1.「.com ログイン画面」を開き、(ログイン名フィールドにログイン名を入力する) 2.パスワードフィールドに以下のデータパターンの文字数で入力を行う 1.
8文字 2. 50文字 3. 100文字 3. ログインボタンを押下する 期待結果 3. ログインが成功し、cybozu.comにアクセスできること 観点 : 条件を満たすときログインが成功すること 42 テスト設計とテスト技法
• 以下のパターンの場合、ログインが失敗すること • パスワードが7文字以下の場合 (7文字) • パスワードが101文字以上の場合 (101文字) 手順 1..com
ログイン画面を開き、(ログイン名フィールドにログイン名を入力する) 2.パスワードフィールドに以下のデータパターンの文字数で入力を行う 1. 7文字 2. 101文字 3. ログインボタンを押下する 期待結果 3. ログインが失敗し、「〇〇〇〇〇〇」のエラーが表示されること 観点 : 条件を満たさないときログインが失敗すること 43 テスト設計とテスト技法
最後に 44
©️ Cybozu, Inc. 本講義で扱った内容は、 ソフトウェアテストのほんの一部 一朝一夕で身につく内容ではない 業務で必要になったときに、 今日学んだ内容を足がかりに! 45
©️ Cybozu, Inc. 46