FaRSeTの説明①(背景)

さて、FaRSeTについて少しずつお話していきます。

FaRSeTは

Flexible and Rapid Software Test(柔軟で素早いソフトウェアテスト)

の略です。

2015年頃から組織内で徐々にブラッシュアップを繰り返してきたテスト手法で、短納期プロジェクトの顧客要望に応えるために、メンバからのアイデアや現場での取り組みを盛り込んでアップデートしてきたものです。

この手法が生まれた背景は

短納期型プロジェクトのテスト依頼が増加している

短納期プロジェクトは、開発プロセス(要件定義、設計、開発、テスト)が並行で実施されることが多い

プロセスの並行実施は、仕様変更が発生しやすい

ということで、もともとは短納期だったり、キッチリしてないプロセス(前のプロセスが終わらないのに次のプロセスが走っちゃう)の時に発生する、

「仕様変更が多い」「スケジュール変更が多い」(あと、ドキュメントが揃わない)

という問題に対して、どうやったらうまい事テストができるだろう・・・・をメンバがずっと考えてきて取り組んできたノウハウを集約したものです。

このような場合に、今までのやりかた(ウォーターフォール的なテストプロセス)でテストを実施すると・・・

仕様変更によるテストケースの変更が発生する

仕様変更による開発スケジュール変動の影響を受けて、テスト実施が非効率になる

短納期型開発プロジェクトでは、仕様変更多発によりテスト工数が増える

となって、かなりテストがかなりグダグダになります。

これが解決したい問題です。

さて、ここで

「なんでウォーターフォールを採用するの?」

という意見もあると思うのですが、我々第三者検証の会社や、独立したテストチームなどは、事前の計画・・・つまり「工数見積」や「テスト範囲(内容)の合意」「成果物の合意」が必要になります。これらがないと、第三者検証の場合には契約すらできません。社内での独立したテストチームでも計画が明確にならないと予算が立てられず、人的リソースの確保ができないです。

しかし、仕様変更が多発してしまうプロジェクトではこの事前の計画や合意をすることは難しく、無理矢理に計画を立てて合意したとしても仕様変更にて容易く崩れ去ってしまいます。

また、こういうプロジェクトはドキュメントが揃わないことが多いです。そうなると事前の合意どころか、概算の見積すら立てられずにテストチームの立ち上げすらできないという・・・。

という事で、「仕様やスケジュールは変更しちゃうことを前提とする」という条件下でのテストを考えました。

ここで、こういう意見も出ると思います。

「そもそも、そういったプロジェクトの根幹を解決しなければいけないのでは」

その通りです。

ただ、やはり現実的には色々な制約のもとで根本の解決が出来なかったり、テストチームの立場ではそこまアプローチできなかったりすると思います。

そんな場合に「プロセスがダメだからテストできません」「ドキュメントが無いからテストできません」という立場をとりたくなかったのです。

FaRSeTは対症療法的な部分があるのは確かです。

とはいえ、どんな状況下においても「最善のテストを実施したい」というメンバの創意工夫の結晶ではないかなと思っています。

FaRSeTの主な構成要素は以下です。
・品質モデルを活用したテストチャータ
マトリクスを使った探索的テスト
マインドマップでの業務分析

次回から詳細を書いてみますね。

<おまけ>

FaRSeT(ファルセット)は「裏声」のことですね。あまり意味はないです。ただ、「Flexible」と「Rapid」をどこかに入れたかったので色々考えた結果、私の趣味である音楽の用語から採用しました。

この手法に関わったメンバはほとんど札幌のメンバなので、本当は北海道らしい名前を付けようと思ったのですが、上手くは言葉にあてはまりませんでした。(「ジンギスカン」とかにしたかった)

また、社内では今まではFaRSeTとは呼ばれておらず「いつものアレでやろうか」とか「あの早いやつで」とか。ただ、名前が無いのは不便なので私が今回勝手に名付けました。今では、「FaRSeT」の名前で呼ばれることが増えて、同時にこのやり方への認知度がチーム内でも高まってきたような気がします。

やっぱり名前を付けるのは大事ですね。