FaRSeTの説明②(概要)

つづきです。FaRSeTの「背景」についてはコチラ

FaRSeTの主な構成要素は以下です。

  • 品質モデルを活用したテストチャータ
  • マトリクスを使った探索的テスト
  • マインドマップでの業務分析

個々を見ると、そんなに目新しいものではないです。ただ、これらを組み合わせることによる問題の解決(「短納期型開発プロジェクトでは、仕様変更多発によりテスト工数が増える」)を目指しています。

具体的には、FaRSeTは2つの施策に分かれます。

A)テスト設計時の施策

⇒仕様変更の影響の少ないテスト分析&設計の実施

B)テスト実施時の施策

⇒仕様変更による開発スケジュール変更に対応しやすいテストの実施

まずは「A)テスト設計時の施策」からご説明します。

すごくシンプルに言うと「仕様変更が多発するといっても、変更がない部分だってあるんじゃない?」です。

ですので、仕様変更の大小をうまく要素分割すれば、それぞれにアプローチをとることが可能と考えたのです。たとえば業務系のリプレースの案件であれば

業務要件     ⇒ 仕様変更が少ない要素

システム要件   ⇒ 仕様変更が多い要素

となります。システムによって「やりたいこと」は既存の「業務」であって、それは不変であると考えます。とはいえその「実現方法」はシステム側の実装方法やシステム構成によって変わります。つまり変更が多いと考えました。

ここがFaRSeTの基本だと考えています。

仕様変更の多い少ないに応じたアプローチは、現在は

・仕様変更が少ない要素(業務要件)

⇒探索的テスト実施前にマインドマップを活用して業務分析

・変更が多い要素(システム要件)

⇒テストスクリプトを記載しない探索的テストを採用し、頻繁に発生する仕様変更への対応とする

としていますが、この仕様変更の多い少ないの要素とそれに対するアプローチは、テスト対象ドメインやプロジェクト内容によって変更する可能性は大いにあると考えています。(現在は、主に短納期の業務系をターゲットとしている)

次回は、設計方法の具体的な内容を書いていきます。

以下はまったくの余談。

元々のアイデアの基としては、私が業務系パッケージのQAチームにいたときの話です(10年以上前)。

パッケージの大規模なリプレース開発に伴って、開発との五月雨テストを余儀なくされた状況におかれ、十分なテスト期間も与えられないプロジェクトでした。単機能⇒結合⇒システムテストと工数を積み上げても全然足りない。メンバからは「こりゃあ、単機能テストだけしか実施できないなあ」というあきらめモードに。

ただ、業務系のキモは業務シナリオが通るかですし、多少の不具合があってもいそぎで修正すれば何とかなる(本当は良くないけど)のが実態でした。それよりも、たとえば請求書などの金額のミスや、業務が止まってしまう事態を避ける方が優先されます。業務シナリオについては、リプレース案件のため「達成されるべき業務シナリオ」は明確に存在していました。

つまり、テストの優先度と実施順が一致していない状況でした。そこで私は「単機能より先にシステムテストを先にやろう」と提案しました。

たとえば仕様漏れであったり、機能間の不整合だったり、そういった不具合は早めに検知しないと修正に時間がかかるうえに必ず防がないといけない内容。それらは単機能に多少の不具合があってもテストすることは可能かと考えました。(今考えると、それらはレビューなど上流工程で行う事ですね)

たとえ「仕様が固まらない」「仕様書が無い」「一部の機能が実装されていない」「不具合が多い」状況でも業務シナリオさえあれば、それをもとに重要なテストを優先して進めることができる・・・というアイデアをその時から持っていました。FaRSeTの原型と考えています。

業務シナリオを執拗に確認していく事で、結果的にはDBの問題や組合せの不具合や、単機能の不具合も検出できるかな。。。という狙いもありました。また、単機能の不具合は開発者がその場で見つけて直してしまうために、不具合起票しても結局は「際限なし」なチケットが山ほど出てしまう事態も予想していましたし。

さて、結果としては・・・

一部はうまく行ったと思います。重要な仕様の不具合やDBの設計の問題などを早期に発見できたと思っています。与えられた条件下においてはベストなテストができたのではないかと考えています。

ただ、一部はうまく行きませんでした。その理由は

・あまりにも品質が悪すぎた。とくにデータ更新回り

⇒単発でデータ更新の不具合があると、もう結合~システムテストができない

・プログラム開発実装タイミングが、業務シナリオに沿わなかった

⇒一番大事な「業務日次データ入力」が最後まで完成せず

・テスト担当者に意図が伝わらず、単機能の軽微な不具合の起票が多くを占めた

⇒テスト担当者は、不具合を見て見ぬふりはできない

・不具合の切り分けが難しい

⇒不具合が出ている場合、その不具合の影響内容を考慮(補正)してテストを実施しないといけない

今思うに、もっとよいやりかたはあったとは思います。ただ、当時の私としては最良の方法を模索した結果です。ただ、以降も「システムにおいて大事な要素や不変の要素はある。そこを優先的にテストすべき」という考え方は生きており、FaRSeTにつながるのでした。