ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

JSTQB-ALシラバスのお勉強 ─ 3.10~3.11

 第3章を、強制終了します。

3.10 故障モード影響解析

 3.9でチラリと出てきたFMEA(Failure Mode and Effect Analysis:故障モード影響解析)に関する節ですが、内容は薄い。ここはきちんと勉強して別のエントリを立てるとして、ポイントのみ。

www.kzsuzuki.com

 FMEAは元々、ハードウェア製造業から生まれた手法ですが、ソフトウェアにおいても手順は同じ。

  1. 「どんな壊れ方をするのか」(Failure Mode)を洗い出し、
  2. その壊れっぷりが何を原因とするのかを導き、
  3. どうすればその原因の影響や発生確率を減らせるかを検討する。

 リスクベーステストではこのうち(1)(2)を行い、その原因を生みそうな範囲のプライオリティを上げてテストする、ということになるのでしょう。

 なお、設計工程におけるレビュー手法として、FMEAの兄弟分であるDRBFM(Design Review based on Failure Mode)があります。こちらは、仕様・設計を変更することによって、どんな故障モードに至りうるかということを洗い出し、レビューのテーマとします。  なお、I/JSTQBにおいて「故障(failure)」とは、

コンポーネントやシステムが、期待した機能、サービス、結果を提供できないこと(JSTQB)

 Failure Modeは、その「提供できない」をもたらす状態のことを指します。たとえば、「車が走らないのがFailure。その理由であるタイヤのパンクがFailure Mode」と理解すればよさそうです。

3.11.1 探索的テストに関するテストマネジメントの考慮点

 3.11は、どうもまとまりのない章です。章や節の粒度が謎です。

www.kzsuzuki.com

 最初の節は「2.5.1 テストの実装」で言及されたSBTM(Session Based Test Management)。これも勉強不足でしっかり咀嚼できていないのですが、要は「探索的テスト(exploratory testing)やるのはいいけど、デタラメにやるんじゃなく、トレーサビリティのためのドキュメントを残そうよ」ということのようです。

 「セッション」とは、「特定のテストオブジェクトに対する、特定の目的をもったテストの単位」とされています。この「目的」とは、「これこれこういう欠陥を叩き出す」といったテーマのことでしょう。

 よくわからないのが、Wikipediaや、開発者であるJames Bach氏のサイトでは、セッションがミーティングのように書かれているのに対し、シラバスではテストの準備・実行・報告までをセッションと呼んでいるように見えることです。

www.satisfice.com

 いずれにせよその目的は、無軌道になるリスクをはらむ探索的テストにおいて、適切に方向性を修正し、またその根拠を明らかにすることで、テストプロセスを管理することにあると言えます。

3.11.2 システムオブシステムズに対するテストマネジメントの考慮点

 以下にも書いたように、システムオブシステムズは複数のシステムからなり、それぞれのシステムは、開発モデルもテスト手法もバラバラ。それだけに、品質計画・構成管理・変更管理・リリース管理といったマネジメントの方法をしっかり準備し、また合意を取ることが重要となります。

www.kzsuzuki.com

 他には、インタフェースが問題になりやすいのでシミュレータの設計・開発の計画が重要など、「そうだね、その通りだね」としか言いようのないことが書かれています。

3.11.3 セーフティクリティカルシステムに対するテストマネジメントの考慮点

 こちらも3.11.2と同様・・・、「その通りだね」的お話です。クリティカルであるため、その業界の標準に沿った開発が求められることがある、など・・・。

 用語としては、RAMS
 信頼性(Reliability)・可用性(Availability)・保守性(Maintainability)・安全性とセキュリティ(Safety & Security)のことで、セーフティクリティカルシステムにしばしば求められる非機能要件を意味します。

3.11.4 その他のテストマネジメントの考慮点

 非機能要件のテストに関するリスクが説明されています。これは、身に染みる。
 非機能要件は多くの場合、明確でない。一方でテストのコストは高く、要件を満たせない場合のリスクが非常に大きい。そのために、以下のような注意点を挙げています。

  • 非機能要件のドキュメントは、記述の形式や用語を統一し、ブレのないように表現すること
  • ツールやシミュレータを導入する大きなコスト・工数を計画に織り込むこと
  • ハードウェアやラボ環境の調達を早期に計画すること

 3.11はあまりに散文的で、駆け足になってしまいました。
 Advancedのシラバス、本文としては10章まであります。8/28までに間に合うのか、と心配してくださる方もいらっしゃるかと思いますが、ご心配なく。わたしはそのような近視眼的な思考は捨て、より遠くを見据えて試験勉強をしているのです・・・!