JSTQB Foundation Level シラバス 1章を10分で読めるようにまとめてみた
自己紹介
初めまして！QAエンジニアの平沢 恵佑と申します。最近は仕事の疲れをサウナとジムで癒すことにはまっています。これがないと1週間働ききれないので、私のエネルギーになってます。
そんな中、蓄えたエネルギーでJSTQB Foundation Levelのシラバスを読んだので、アウトプットとして少しかみ砕いて説明してみました。(きっと10分で読めるはずです)
以前には心理的安全性についても書いているので、お時間ある方はこちらもご覧になってください↓
あくまで概要を記載しているので、詳細を知りたい方は以下原本をご参照ください。 また今回の引用はすべてシラバスから引用しております。
原本：https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
JSTQBとは？
そもそもJSTQBってなんやねんって方もいらっしゃると思います。
簡単に言うと「ソフトウェアテスト技術者の資格」です。
その中でFoundation Level(今後はFLと記述します)とは最も基礎的なレベルのモノと言われています。そのFLの中身も6章に分かれているので、その中の1章を今回紹介させていただきます。
0章について
1章の紹介の前に、0章の概要を記載させてください。
0章ではこのJSTQBの対象者、目的等が記載されています。
対象者：ソフトウェア開発にかかわるすべての人。QAだけではないです。
目的：本シラバスの6つの章で説明されているキーワードと概念について認識し、記憶し、想起することでビジネス成果を支援すること
テストの基礎
ソフトウェアテストとは？
→運用環境でソフトウェアの故障が発生するリスクを低減する一つの手段
よくある誤解として、「ソフトウェアを実行し結果を確認するだけ」がテストではないです。
テスト設計/実装はもちろんですが、要件やユーザストーリーのレビュー、妥当性確認もテストと呼びます。
テストの目的
テストとは？を理解すると目的が見えてくると思います。
JSTQBに書かれているのは以下の通りです!
要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価することによって欠陥を防ぐ。
明確にしたすべての要件を満たしていることを検証する。
テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする。
テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する。
欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減する。
ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分な情報を提供する。
契約上、法律上、または規制上の要件や標準を遵守する、そして/またはテスト対象がそのような要件や標準に準拠していることを検証する。
ただ対象のシステムやテストレベルによって微妙に目的は異なるので、自案件のテスト目的を考えてみてもいいかもしれません。
エラー/欠陥/故障
一見同じ意味に見える単語ですが、JSTQB内では、エラー/欠陥/故障の3つをちゃんと区別してます。
エラー
主にヒューマンエラーのことを指します。人間なのでエラーが起きるのはしょうがないという前提ですね。
シラバスによるとエラーの原因は以下にあるそうです。
納期のプレッシャー
人間の誤りを犯しやすい性質
プロジェクト参加者の経験不足または技術不足
プロジェクト参加者間の誤ったコミュニケーション（要件や設計の誤ったコミュニケーションを含む）
コードの複雑さ、設計の複雑さ、アーキテクチャーの複雑さ、解決すべき根本的な問題の複雑さ、そして/または使用する技術の複雑さ
システム内またはシステム間のインターフェースに関する誤解（特に、関連するシステムの数が多い場合）
新しく不慣れな技術
どれもイメージしやすいですね、、
欠陥
欠陥はエラーによって引き起こされる事象のことです。
私たちがイメージするバグがこれにあたります。
エラーによっては複数の作業成果物に影響を与えることがあります。例えば
「要件の導出がエラーによって漏れる→要件欠陥→プログラミングエラー→コードに欠陥」のような感じです。
故障
欠陥によって引き起こされるのが故障ですが、絶対発生するわけではないです。欠陥によっては故障を引き起こす為に複雑な入力をする必要がある場合もあります。また、コード内の欠陥だけではなく環境条件によって引き起こされることもあります。例えば落雷によってファームウェアの誤作動が起きたりなど。
7原則
シラバスではテストの7原則を定めていて、あらゆるテストで共通して使える一般的なガイドラインとなっています。
1.テストは欠陥があることは示せるが、欠陥がないことは示せない
いわゆる悪魔の証明的なやつです。
テストをすることによって「欠陥ありました！」とは言えますが、「欠陥はもうないです！」とは言い切れないですよね。（テストが悪いのかもしれない）
2.全数テストは不可能
全網羅してテストすることはシンプルなソフトウェアじゃない限り、難しいということです。現実的に工数の問題もあるので。。
それであれば優先順位をつけてテストをした方が効率がいいですよね。
3.早期テストで時間とコストを節約
静的テストと動的テストの両方を早い段階でやると、欠陥を見つけたときに修正コストが少なくてすみますよねって話です。
4.欠陥の偏在
欠陥は万遍なく広がっているわけではなく、ある程度固まっているということです。これがあるから、2番目の「全数テストは不可能」があっても充分に品質担保できるんですね。
5.殺虫剤のパラドックスにご用心
同じテストを何回も繰り返しても、欠陥を見つけられなくなるよって話です。殺虫剤も効きが悪くなってくると新しいモデルの殺虫剤ができるように、テストもデータを見直したり新規にテストを作成したりすることが大事です。
6.テストは状況次第
アジャイルとウォーターフォールでテストの実行方法が違ったりするという話です。
7.「バグゼロ」の落とし穴
1番と2番が関わってきますが、全部のテストをして予想した欠陥をすべて検出することはできないということです。
テストプロセス
テストプロセス：テストの目的を達成する確率を高くするための、汎用的なテスト活動のセットのことです。
シラバスで挙げられているテストプロセスを構成する活動は以下の通りです。
テスト計画
テストのモニタリングとコントロール
テスト分析
テスト設計
テスト実装
テスト実行
テスト完了
実際に業務としてやったことがある活動もあると思いますが、それがテストプロセスの一つだったということです。
状況に応じたテストプロセス
上記のようなテストプロセスに影響を与える状況がいくつかあるので、JSTQBで挙げられてるモノを記述します。
使用するソフトウェア開発ライフサイクルモデルとプロジェクト方法論
考慮対象のテストレベルとテストタイプ
プロダクトとプロジェクトのリスク
運用上の制約：予算とリソース/期間/複雑さ
先ほども少し記述しましたが、アジャイルとウォーターフォールではテストプロセスの進め方が違ったり、予算やリソースが足りないと現実的にどこかできない箇所が発生したりします。
テスト活動について
※アジャイルだとまた形が違ってくる
先ほど記述した、テストプロセスを構成するタスクの中でテスト設計/テスト実行を除いた活動内容をかる～～く記述します。
(テスト実行/設計は研修でも受講していると思うので)
詳細を知りたい方はシラバスを参照ください。
テスト計画
「テストの目的と状況により課せられる制約内でテストの目的を達成するためのアプローチを定義する」ことです。
分かりにくすぎたのですが、シラバスには具体例が記載されていました。
適切なテスト技法とタスクを指定して、納期に間に合うようにテストスケジュールを作成すること」です。
ぐっとイメージしやすくなりました。
※テスト技法：同値分割法や境界値分析など
また、テスト計画に関しては「テストのモニタリングとコントロール」からのフィードバックを得て、更新し続ける必要があります。
5章で詳細を説明します。
テストのモニタリングとコントロール
テストモニタリング：計画した進捗と実際の進捗のズレがないか継続的に比較する活動
テストコントール：テスト計画書の目的に合致させるために対策を講じる活動で、テスト計画書の継続的な更新活動も含む
この2つの活動を遂行するためには終了基準(doneの定義)があるとやりやすいです。
計画に対する進捗はテスト進捗レポートを使用してステークホルダーに報告し、それを元にテスト中止を決定する場合があるので、重要な活動ですね。
ここも5章で詳細を説明します。
テスト分析
計測可能なカバレッジ基準から見た「何をテストするか」を決定することです。
具体的な活動はこんなことを指すらしい↓
・テストレベルごとに適切なテストベースを分析する
テストベース：テストケースを作成するためのinputのこと。要件仕様やユーザストーリーなどなど
つまり、コンポーネントテストや受入テストなどそれぞれのテストレベルを考慮しつつテストベースを決定/分析することです。
・テストベースとテストアイテムを評価して、さまざまな種類の欠陥を識別する
テストアイテム：テストを実施する個々の要素＝「テスト対象の機能」と読み替えた方がわかりやすいかもしれません。
つまり各機能とテストベースを以下の観点で確認して、欠陥がないか確かめるというわけですね。
曖昧
欠落
不整合
不正確
矛盾
冗長なステートメント
・テストすべきフィーチャーとフィーチャーのセットを識別する
フィーチャーセット：機能パッケージのこと
テストすべき機能と機能パッケージを再度識別しましょうということですね。
・テストベースの分析に基づいて、各フィーチャーのテスト条件を決めて優先度を割り当てる。この際には、機能/非機能/構造の特性、他のビジネス/技術的要因、リスクのレベルを考慮する
テスト条件：テストケース内の作業工程をいくつか踏んだ上で生み出されるシステムの状態のこと
先ほどテスト対象機能を識別したので、それぞれのテスト条件を決めて優先順位を決定するという工程ですね。
そして優先度を割り当てる際には様々な条件に考慮しつつ行わなければいけないということです。
・テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立する
頭に入ってこない文章だったので言葉を置き換えてみました↓
「inputの各要素と、関連するテスト条件の間の対応関係や変更履歴などを更新しておき、追跡できる仕組みを確立しておきましょう」ということですね。
テスト実装
テスト設計と同時に行われることもある工程なので、テスト設計との区別がイメージしづらい工程だと思います。
テスト設計は「どうやってテストするのかを明確にする」という目的なのに対し、テスト実装は「テストの実行に必要なものすべてを準備する」ということが目的です。
準備するモノの例としては、自動化スクリプトやテスト環境、テスト手順などが該当します。
テスト完了
完了したテストの活動データを集めて「プロジェクトから得たこと/テストウェア/その他の関連する情報すべて」をまとめる工程です。
具体例としては以下のような活動内容です。
すべての欠陥レポートがクローズしていることを確認する。または、テスト実行の終了時に未解決として残されている欠陥について変更要求またはプロダクトバックログアイテムを作成する。
テストサマリーレポートを作成して、ステークホルダーに提出する。
テスト環境、テストデータ、テストインフラストラクチャー、その他のテストウェアを次回も使えるように整理し保管する。
テストウェアをメンテナンスチーム、他のプロジェクトチーム、および/またはその使用により利益を得る可能性のある他のステークホルダーに引き継ぐ。
完了したテスト活動から得られた教訓を分析し、次回のイテレーションやリリース、プロジェクトのために必要な変更を決定する。
収集した情報をテストプロセスの成熟度を改善するために利用する。
テスト作業成果の心理学
人の心理とテスト
開発もテストもすべて人が行うので、人の心理学が大きく影響してきます。
例えばテスト実行中にバグを見つけて報告すると、プロダクトやプロダクトの開発担当者に対する「非難」と受け取られることがあります。
原因としてシラバスには「確証バイアス」と呼ばれる心理要素だと書かれています。
これは持っている信念に合わない情報を受け入れがたくするもの。開発者は作成したコードが正しいと思い込んでいるので、バグの指摘を受け入れずらかったりするという状況になります。
こういったギスギスした状況にはならないようにする為に、シラバスではコミュニケーションを適切にとる方法が記述されています。
対決ではなく、協調姿勢で開始する。全員のゴールは、高品質のシステムであることを再認識するとよい
テストの利点を強調する。例えば、開発担当者に対しては、欠陥情報は、作業成果物の品質向上と開発担当者のスキル向上に役立つ。組織に対しては、欠陥をテストで検出して修正すると、時間と経費の節約になり、プロダクト品質の全体的なリスクも減る
テスト結果や他の発見事項は、中立な立場で、事実に焦点をあてて伝え、欠陥を作りこんだ担当者を非難しないようにする。客観的かつ事実に基づいた欠陥レポートを書いたり、発見事項をレビューしたりする
他人の気持ちや、他人が情報に対して否定的に反応した理由を理解するように努力する
自分の言ったことを他人が理解し、他人の言ったことを自分が理解していることを確認する
双方が理解していなくては効果は薄いかもしれませんが、まず自身ができていないと始まらないとも思います。
まとめ
以上が1章の内容です。
「テストとは？」が主な内容だったので、全体的に抽象度が高い内容だったかなと思います。
また、内容をかみ砕いて説明している部分があるのでしっかりと理解したい場合は、シラバス原本を読んでみてもいいかもしれません。
今回は1章のみでしたが、今後2章以降も執筆していく予定です。
ちなみに2章以降の概要は以下の感じです。
第2章：ソフトウェア開発ライフサイクル全体を通してのテスト
第3章：静的テスト
第4章：テスト技法
第5章：テストマネジメント
第6章：テスト支援ツール
初見で分からなかった単語集
シラバスを読んでいく中で、意味が分からなかった単語を並べておきます。 一応文中でも意味は記載していますが、まとめて見る用です
テストベース：テストケースを作成するためのinputのこと。要件仕様やユーザストーリーなどなど
テストアイテム：テストを実施する個々の要素＝「テスト対象の機能」と読み替えた方がわかりやすいかも
テスト条件：テストケース内の作業工程をいくつか踏んだ上で生み出されるシステムの状態のこと
フィーチャーセット：機能パッケージのこと
執筆者プロフィール：平沢 恵佑
生命保険の営業職からSHIFTへSAA一期生として入社。 約3か月の研修後、5名のチームに設計リーダーとして参画。 約1年半のチームリーダー経験を経て、現在はQAエンジニアとして次案件に参画中。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/