第258回: 「ALTAのテキストをつくろう」18 (リスク識別)
◀前の記事へ 次の記事へ▶
≡ はじめに
このシリーズの前回では、「リスクベースドテスト」のイントロダクションについて書きました。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「2. リスクベースドテストにおけるテストアナリストのタスク」の「2.2 リスク識別」について書きます。
≡ 前回の復習
以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、4が41.3%と最も多いのですが、正解は1の「リスクベースドテスト戦略の採用決定」です。1は、テストマネージャーの役割です。
そして、2, 3, 4が前回のキャッチイメージ(下記)のとおり、テストアナリストが関与する3つのタスクであり、今回と次回と次々回にわけて説明する予定のものです。
ということで、今回のnoteのテーマは「リスク識別」です。以上で復習は終わりです。
≡ リスク識別
■ リスクベースドテストにおけるリスク
リスクベースドテストにおける「リスク識別」とは、「テスト中に対応すべきビジネスリスクの領域を決定すること」です。
JSTQBのFL試験を受けた人は「プロダクトリスク」と「プロジェクトリスク」の違いについて勉強したと思います。
ISTQBの用語集で復習します。
要は、プロダクトリスクは「品質が悪い商品となるリスク」、プロジェクトリスクは「納期遅延やコスト超過などプロジェクトが失敗に終わるリスク」のことです。用語集では「リスク」も参照するようにボタンがあるので押してみます。
「(リスクとは)将来、否定的な結果を生む要素。」という定義となっています。
『そんなこと知ってる』と思われると思いますが、対称となる「将来、肯定的な結果を生む要素。」が入っていない点に注意が必要です。
さて、ISTQBでは、「将来、否定的な結果を生む要素。」をリスクと呼び、リスクはさらにプロダクトリスクとプロジェクトリスクに分かれるとわかりました。
そこで、あらためて初めの方で書いた、テストアナリストが関与するリスクベースドテストにおけるリスク識別の定義を読み直します。
「プロダクトリスクを見つける」ことを「リスク識別」と言っています。
■ リスクベースドテストにおけるリスクの識別方法
テストアナリストは、ユーザーおよび他のドメインの専門家(要件エンジニア、ビジネスアナリストなど)と緊密に連携してリスクを識別します。
シラバスには具体的な方法の例が載っていますが、ポイントは、テストアナリストに「テスト対象システムの特定のビジネスドメインに関する特有の知識を保有している」ことを期待しているという点です。
言われてみれば、当たり前ですが、単に「ソフトウェアテスト技術」や「IT全般の知識」だけではなく、「テスト対象システムの特定のビジネスドメインに関する特有の知識」が必要ということです。
テストアナリストになると、以下の図のProfessional testerように、ドメイン知識が求められます。
■ プロジェクトで識別される可能性のあるリスクの例
ALTAのシラバスに記載されているリスクベースドテストのリスクの例です。
機能の正確性の問題(例えば、誤った計算)
使用性の問題(例えば、キーボードショートカットの不足)
移植性の問題(例えば、アプリケーションを特定のプラットフォームにインストールできない)
≡ JSTQB ALTA試験対策
いつものことですが、まずは、「学習の目的」を確認します。
K3なので、「適用」です。
適用ですので、「概念または技法を正しく選択することができ、それを特定の事例に適用することができる」必要があります。
リスクベースドテストはK1でもK2でもないので、ISTQBとして重要な概念として位置付けられています。
答えは次回に書きます。
≡ おわりに
今回は、「リスク識別」がテーマでした。
アジャイル開発におけるテストでは特に大切なのではないでしょうか。
次回は「リスクアセスメント」です。
この記事が気に入ったらサポートをしてみませんか?