はじめに
元々エンジニアをやっていましたが、ひょんなことからここ1年 QA をやっている者です。
QA は仕様や要件のような上流工程に対しどのように関わることができるのか、ここ1年での経験を踏まえて記したいと思います。
前置き
今回書く内容は、ある新規事業開発現場での QA 業務に纏わるお話がベースです。
全ての現場・シチュエーションに沿わないかもしれませんがご容赦ください。
JSTQB での定義
早速ですがJSTQB では、上流工程から関わることについてこのように論じています。
JSTQB 1.3
3.早期テストで時間とコストを節約 プロセスの早い段階で欠陥を取り除くと、その後の作業成果物では取り除かれた欠陥に起因する欠陥を引き起こすことはない。SDLCの後半に発生する故障が少なくなるため、品質コストは削減される（Boehm 1981）。早い段階で欠陥を見つけるために、静的テスト（第3章参照）と動的テスト（第4章参照）の両方をなるべく早い時期に開始すべきである。
JSTQB 2.1.5
2.1.5 シフトレフトアプローチ
早期テストの原則（1.3節参照）を、シフトレフトと呼ぶことがある。なぜなら、テストがSDLCの早い段階で実行されるアプローチだからである。シフトレフトでは、通常、テストがより早い段階（例えば、コードが実装されるのを待たない、コンポーネントが統合されるのを待たない）で行われるべきだと提言しているが、SDLCの後半でのテストを軽視するべきだということを意味しているわけではない。テストにおける「シフトレフト」を実現する方法を示すよい実践例は次の通りである：
・テストをする観点から仕様書をレビューする。このような仕様書のレビュー活動では、曖昧さ、不完全さ、矛盾など、潜在的な欠陥を発見することが多い。
・コードを書く前にテストケースを書き、コード実装時にテストハーネスでコードを実行する。
・ソースコードをコードリポジトリへサブミットする際に、付随する自動コンポーネントテスト、そして高速フィードバックが伴うようにするため、CIやCDを用いる。
・動的テストの前に、または自動化したプロセスの一部として、ソースコードの静的解析を完了する。
・実施可能であれば、コンポーネントテストレベルで非機能テストの実施を始める。システムが完成し、本番相当のテスト環境が利用可能になるSDLCの後半に実施される傾向がある非機能テストをこのように実施することは、シフトレフトの一形態である。
シフトレフトアプローチは、プロセスの初期には追加のトレーニング、労力、またはコストがかかるかもしれないが、プロセスの後期には労力やコストを削減することが期待される。 シフトレフトアプローチのために、ステークホルダーがこの考え方に納得し、受け入れることが重要である。
要するに、上流工程にテストの観点から関わることで、下流での手戻りが少なくなりプロジェクト全体のコストが抑えられます。
QA は上流工程にどのように関わればいい？
本題です。
JSTQB の定義と実体験を踏まえ、上流への関わり方について以下が効果的なように思います。
- 仕様が決まっていなかったら拾う
- テスト分析〜テスト設計をする中で考慮もれや懸念を共有する
- リスクマネジメント
1. 仕様が決まっていなかったら拾う
プロジェクトの性質によっては、仕様がスケジュール通りに決まらないケースって多々あるんじゃないかなと思います。
QA としてはテスト分析（テスト観点出しなど）を行うにあたって、
仕様書は特にテストベース（テストするための材料）として重宝するのでできれば早く決まって欲しいお気持ちがあります。
仕様が決まりきっていないケースでは、QA が現状の確認と仕様の整理を買って出るのもアリかなと思います。
整理することで仕様を理解できますし、認識合わせ会を開いてついでに仕様を決められたもりするので一石二鳥です。
2. テスト分析〜テスト設計をする中で考慮もれや懸念を共有する
JSTQB でも記載があると思いますが、いわゆるトレーサビリティです。
仕様や要件をレビューするっていっても、仕様書やドキュメントを眺めていても時間が過ぎるだけで何も思いつきません。
QAの業務では一般的かと思いますが、テスト観点をスプシにまとめるなど何か別のものに書き出すことによって気づきがあったりします。
仕様書と書いたテスト観点を行ったり来たりして確認し合う（＝トレーサビリティ）ことで、抜け漏れなどが把握しやすくなります。
それらを定例 MTG で共有するなり仕様書にコメントしておくなりして残しておくなりします。
3. リスクマネジメント
リスクを把握し、管理・共有、対処法を考えることは、
仕様や要件に影響を与えるので結果的に上流に関わることになります。
JSTQB 5.2
リスクマネジメントは、組織が目的を達成する可能性を高め、プロダクトの品質を向上させ、ステークホルダーの信頼と信用を高めることを可能にする。
JSTQB によると、テストにおいてリスクは下記の2つに分類されます。
- プロダクトリスク
- プロジェクトリスク
1. プロダクトリスク
JSTQB 5.2.2
プロダクトの品質特性（例えば、ISO 25010品質モデルに記述がある）に関連するものである。プロダクトリスクの例としては、機能の不足や誤り、誤った計算、ランタイムエラー、貧弱なアーキテクチャー、非効率なアルゴリズム、不十分な応答時間、貧弱なユーザーエクスペリエンス、セキュリティの脆弱性などが挙げられる。
プロダクトの品質評価という点で、プロダクトリスクは QA にとってイメージしやすいです。
テスト分析〜テスト実行で、上記のプロダクトリスクを検知、修正を促すことができます。
2. プロジェクトリスク
一方、QA はプロジェクト全体のリスクにも関心を持ち、助言ができるべきだと考えます。(この点が今回の私的な反省点です)
JSTQB 5.2.2
顕在化した場合、プロジェクトのスケジュール、予算、スコープに影響を与え、プロジェクトの目的を達成する能力に影響を与える可能性がある。
私の経験だと、下記が原因でスケジュールが遅延することになりました。
- SaaS の品質不安
- ステークホルダーの増減
- 実運用の考慮不足
1, 2のような突発的な事象は、予測できたものではないので仕方がないと割り切ることができます。
一方、3 に関しては未然に防げる問題です。
プロダクトの品質に集中するあまり、プロジェクトの全体像へ思いを馳せることができていませんでした。
（ユーザーではなく、内側の人の）実運用を考慮しておく必要がありました。
- 誰がどう運用するのか
- 現状の運用からの移行をどうするか
など、観点としては事前に挙げられたように思います。
さいごに
1年ほどの経験ではありますが、JSTQB と実体験をもとに
QA は上流工程にどう関わっていけばよいかを書かせていただきました。
上流への関わり方について、知見等あればコメントいただけると嬉しいです。
読んでいただきありがとうございました。