超(個人)訳JSTQB Foundation Level シラバス Part1

はじめに

今回、JSTQB FLのシラバス読解に関する記事を書いていきます。
その経緯として、私自身2017年にFLを取得しましたが、資格取得してから「これ取ったはいいけど、どう仕事に活かせばいいの？」という疑問が浮んでおりました。
当時は「この先経験を積んでいく中で段々分かってくるか」と楽観視し、未来の自分に期待しておりましたが、現時点でもさほど分かっておりません。
このままではただ資格取得したという事実しか残らないため、改めてシラバスを読んで自分なりの発信したいと思い、記事にしようと決意しました。

引用元について

テーマにある通り、ISTQBが提供するFoundation Levelシラバスを引用させて頂く。
前回はIVECのシラバス読解の記事を記載していたが、それと比較しても非常にボリューミーであり、この記事を書いている時点で途中で(ないとは思うが)新シラバスが発行されないかが気がかりである。

記事の構成について

記事の構成については、シラバスを引用し、記載されている内容から自分なりの解釈や得た知識をどう活かせるかを考察してみる。
但し、この記事を読んだからといってFLの取得に役立つかと言われたら微妙かもしれない。
なぜなら、全然関係ない話や身内ネタが出てくると思っています。
最速でFL受かりたいならシラバスやシラバス解説本を読み、問題集やった方がいいはず(経験談)
では早速シラバスを読み解いていく。

1 テストの基礎

1.1 テストとは何か？

ソフトウェアシステムは、日々の生活を構成する要素として必須となっている。ソフトウェアが期待通りに動かなかった経験は誰もが持っている。ソフトウェアが正しく動作しないと、経済的な損失、時間の浪費、信用の失墜など、さまざまな問題が発生し、極端な場合は傷害や死亡事故になることもある。
ソフトウェアテストは、ソフトウェアの品質を評価し、運用環境でソフトウェアの故障が発生するリスクを低減する手助けとなる。

ソフトウェアは我々の生活に浸透し、豊かにしているがソフトウェアに不都合が生じることで日常生活に多大な影響を及ぼす。以下はソフトウェアが正しく動かないことで起こり得る事例である。

• インターネットバンキングで送金取引ができず、期日までに公共料金を支払えなかった
• 自動車の運転中に運転支援機能が正常に動作せず、接触事故を引き起こした
• ソシャゲのランキングイベント中、ゲーム進行できないバグが見つかって緊急メンテナンスに入り、プレイ時間を確保できず、目標順位に到達できなかった
• ソフトウェアが正しく動かなかったことで、本来発生しなかった修正作業が割り込んできた
• ソフトウェアが正しく動かなかったことで、クレーム対応や製品回収が発生した

こうしたトラブルが起きることでユーザーの持つ時間や金銭に損失を与え、ユーザー離れや利用サービスの解約に拍車がかかり、最悪の場合は生命が脅かされるリスクもある。
また、後半2つの例はソフトウェアの提供側目線から、ソフトウェアが正しく動作しないことで起こり得る話である。様々なビジネスモデルにおいて、ソフトウェアが動かなかったことで経済活動遅延や損害発生によって企業の信用が低下し、取引終了や収益低下といったリスクが考えうる。

そうした多様なリスクをできるだけなくせるよう、ソフトウェアテストはテスト対象の品質を評価し、ユーザーに不利益をもたらす要素がないか検証するのが重大な役割である。

ソフトウェアテストは、欠陥を発見し、ソフトウェアアーティファクトの品質を評価するための一連の活動である。これらアーティファクトは、テストをする際のテスト対象である。テストに関するよくある誤解の 1 つは、テストはテスト実行（すなわち、ソフトウェアを実行しテスト結果を確認する）だけだというものである。しかし、ソフトウェアテストには他の活動も含まれる。そして、ソフトウェア開発ライフサイクルと整合させなければばらない（第2章参照）。

テストに対する誤解の1つに、ソフトウェアを動かし、動作に問題ないか確認するだけの作業とみなされているが、ソフトウェアテストはソフトウェア開発においてテスト以外の部分も含まれている。

• ソフトウェアの要件や開発担当が作成した設計書がステークホルダーの要求に沿った内容であり、考慮漏れや不整合・矛盾がないかを精査する
• 目標とする品質に達成しているかの指標を定め、テスト全体を通して目標がクリアしているかをチェックする
• ソフトウェアの開発工程全体を見て、改善すべき過程がないかを見直す

脱線してしまいますが、シラバスにある「ソフトウェアアーティファクト」って響きがいいですね。
私自身これまでの業務で一度も使ったことありませんが、いつかドヤ顔で言ってみたいです。

テストに関するもう 1 つのよくある誤解は、テストはテスト対象の検証だけに重点を置くというものである。テストでは検証、つまり指定されている要件をシステムが満たすかどうかを確認することに加えて、妥当性確認も行う。妥当性確認では、ユーザーやその他のステークホルダーのニーズを運用環境でシステムが満たしていることを確認する。

テストはテスト対象を動かすこと、つまり「検証」だけがテストの果たすべき役割ではない。
例えば、ソフトウェアを実際に動かしてステークホルダーが欲する要件を全て満たしていたとしても、ソフトウェアそのものが満足いくものでなければ、テストの役割を果たしたとは言えない。
シラバスではこれを「妥当性確認」と呼び、テストは検証と妥当性確認の2軸で成り立っている。

テストは動的な場合、または静的な場合がある。動的テストはソフトウェアの実行を伴うが、静的テストはソフトウェアの実行を伴わない。静的テストはレビュー（第 3 章参照）と静的解析を含む。動的テストでは、さまざまな種類のテスト技法やテストアプローチを用いてテストケースを導出する（第4章参照）。

テストは実際にテスト対象を動かすだけと思われがちだが、テスト対象を動かさない形でのテストも存在する。
ソフトウェア開発において、ステークホルダーの要望を言語化した要件や、開発チームが要件を実現するために作成した各種設計書等、ソフトウェアを作るために必要な資料が数多く作成されるが、その内容が妥当かを確認・精査するのもテストの1種である。
また、テスト対象を動かす場合においても、当てずっぽうで行うのではなく、テストの目的にマッチするやり方があり、それらを駆使して効率よく不具合を検出していく。

テストは、技術的な活動だけではない。適切に計画、マネジメント、見積り、モニタリング、コントロールすることもまた必要となる（第 5 章参照）。

テストは技術的な活動に留まらず、マネジメント部分の活動も数多く存在する。
テストを行う過程に焦点を当ててみると、テストを行う前は予算や人員を見積もり、それらをスケジュールに落とし込んでいく。
また、テストを行っている最中はテストの進み具合や品質の状況を観察し、ステークホルダーや開発チームに共有することで現在の品質を把握してもらう。
そして、テストが終わった後はテスト結果をレポートにまとめてステークホルダーへ報告し、必要に応じて達成すべき品質に到達しているかを判定する。
といった流れが形成されている。

テスト担当者はツールを使用するが（第6章参照）、テストは大部分が知的活動であり、テスト担当者は専門知識を持ち、分析スキルを使い、批判的思考やシステム思考を適用することが求められることを忘れてはならない（Myers 2011, Roman 2018）。
標準である ISO/IEC/IEEE 29119-1 では、ソフトウェアテストの概念についてさらに詳しい情報を提供している。

テストに対するイメージとして、ソフトウェア開発スキルが乏しい人がこなす仕事という認識があるかもしれない。しかし、ソフトウェアテストはソフトウェア開発同様に専門の知識が存在し、テスト担当者は自分たちが行っている仕事はスキルの乏しい人による確認作業ではなく、高度な知識を駆使した知的労働と認識を改めなければならない。

おわりに

これ書いている最中にChromeの更新通知来たので手癖で更新したら、下書き保存忘れていたのをボタンを押した後に思い出し、前の夜から書いていた内容も丸ごと吹っ飛んだ。
下書き保存は大事。
今回は長い旅になりそうですが、現在の業務状況に関わらず定期的に更新できるよう進めてまいります。