見出し画像

第258回: 「ALTAのテキストをつくろう」18 (リスク識別)

◀前の記事へ 次の記事へ▶


≡ はじめに

このシリーズの前回では、「リスクベースドテスト」のイントロダクションについて書きました。

前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「2. リスクベースドテストにおけるテストアナリストのタスク」の「2.2 リスク識別」について書きます。



≡ 前回の復習

以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。


𝕏によるアンケート結果

投票の結果、4が41.3%と最も多いのですが、正解は1の「リスクベースドテスト戦略の採用決定」です。1は、テストマネージャーの役割です。

そして、2, 3, 4が前回のキャッチイメージ(下記)のとおり、テストアナリストが関与する3つのタスクであり、今回と次回と次々回にわけて説明する予定のものです。

ということで、今回のnoteのテーマは「リスク識別」です。以上で復習は終わりです。



≡ リスク識別


■ リスクベースドテストにおけるリスク

リスクベースドテストにおける「リスク識別」とは、「テスト中に対応すべきビジネスリスクの領域を決定すること」です。

JSTQBのFL試験を受けた人は「プロダクトリスク」と「プロジェクトリスク」の違いについて勉強したと思います。

ISTQBの用語集で復習します。

ISTQB用語集より
ISTQB用語集より

要は、プロダクトリスクは「品質が悪い商品となるリスク」、プロジェクトリスクは「納期遅延やコスト超過などプロジェクトが失敗に終わるリスク」のことです。用語集では「リスク」も参照するようにボタンがあるので押してみます。

ISTQB用語集より

「(リスクとは)将来、否定的な結果を生む要素。」という定義となっています。
『そんなこと知ってる』と思われると思いますが、対称となる「将来、肯定的な結果を生む要素。」が入っていない点に注意が必要です。

たとえば、「株を買うことのリスク」といった場合、「株価が下がること(否定的な結果)」がリスクなのは納得だと思いますが、「株価が上がること(肯定的な結果)」もリスクと呼びます。

抽象化すれば「不確定な未来の要素」となります。そして、このことをリスクと呼ぶ業界があるということは頭の隅に置いておきましょう。

ただし、一般的(辞書的)には、リスクを「将来、否定的な結果を生む要素。」と考えて差し支えありません。
「将来、肯定的な結果を生む要素。」の方は、一般的には「機会」と呼びます。

「リスク」と「機会」は否定的か肯定的かの違いでしかありません。つまり、「事象そのものの違い」ではなく「とらえ方の違い」です。

例えば、「円安」はリスクでしょうか? それとも機会でしょうか?
海外旅行に行く人にとって、「円安」はリスクです。「円安になることが分かっていたら成田空港でたくさん両替しておけばよかった」って。
ところが、製造業の経営者にとっては「円安になれば、海外でうちの商品が『安い・安い』と爆売れして儲かる」から機会でしょう。

1人の人間に絞って考えても、例えば「転職」はリスクでもあり機会でもあるといえます。

リスクと機会を抽象化した「不確定な未来の要素」に名前を付けたくなりませんか?

さて、ISTQBでは、「将来、否定的な結果を生む要素。」をリスクと呼び、リスクはさらにプロダクトリスクとプロジェクトリスクに分かれるとわかりました。
そこで、あらためて初めの方で書いた、テストアナリストが関与するリスクベースドテストにおけるリスク識別の定義を読み直します。

リスクベースドテストにおける「リスク識別」とは、「テスト中に対応すべきビジネスリスクの領域を決定すること」。

プロダクトリスクを見つける」ことを「リスク識別」と言っています。


■ リスクベースドテストにおけるリスクの識別方法

テストアナリストは、ユーザーおよび他のドメインの専門家(要件エンジニア、ビジネスアナリストなど)と緊密に連携してリスクを識別します。

シラバスには具体的な方法の例が載っていますが、ポイントは、テストアナリストに「テスト対象システムの特定のビジネスドメインに関する特有の知識を保有している」ことを期待しているという点です。

例えば、eコマースシステムのテストアナリストを名乗るなら、eコマースのビジネスについての知識を持っていることが期待されます。

言われてみれば、当たり前ですが、単に「ソフトウェアテスト技術」や「IT全般の知識」だけではなく、「テスト対象システムの特定のビジネスドメインに関する特有の知識」が必要ということです。

テストアナリストになると、以下の図のProfessional testerように、ドメイン知識が求められます。

JaSST Tokyo’14のクロージングパネル: Stuart Reid氏の資料より


■ プロジェクトで識別される可能性のあるリスクの例

ALTAのシラバスに記載されているリスクベースドテストのリスクの例です。

  1. 機能の正確性の問題(例えば、誤った計算)

  2. 使用性の問題(例えば、キーボードショートカットの不足)

  3. 移植性の問題(例えば、アプリケーションを特定のプラットフォームにインストールできない)


≡ JSTQB ALTA試験対策

いつものことですが、まずは、「学習の目的」を確認します。

TA-2.1.1 (K3)
特定の状況で、リスク識別に参加し、リスクアセスメントを実行し、適切なリスク軽減策を提案する 。

K3なので、「適用」です。
適用ですので、「概念または技法を正しく選択することができ、それを特定の事例に適用することができる」必要があります。
リスクベースドテストはK1でもK2でもないので、ISTQBとして重要な概念として位置付けられています。

《問題》
 リスクベースドテストにおいて、テストアナリストが識別することが期待されるリスクではないものを以下の選択肢から選びなさい。

1. ユーザーの不満足
2. メンテナンスコストが高い
3. 不正確な見積り
4. 操作性が悪い

答えは次回に書きます。



≡  おわりに

今回は、「リスク識別」がテーマでした。
アジャイル開発におけるテストでは特に大切なのではないでしょうか。

次回は「リスクアセスメント」です。

この記事が気に入ったらサポートをしてみませんか?