「答え合わせ」から、「答え探し」のソフトウェアテストへ

今回は、近年のソフトウェアテストのニーズの変化と、求められるスキルについて書きました。

ソフトウェアテストは現在、「答え合わせ」ではなく、『答え探し』が、もっとも求められています。

この背景には、開発の手法として、従来のウォーターフォール型ではなく、
アジャイル型の開発が多くなってきている事が大きく関係しています。

ウォーターフォール型では、当然ながら要件→設計→製造→テストの開発プロセスは1つずつしかなく、それぞれ完了させてから次のプロセスに進めるため、テストでは仕様が決まっていることが前提となります。
つまり、仕様（期待する結果）の通りに動くか？を検証する「答え合わせ」のテストです。

一方アジャイル型では、その「答え」が詳細に決まっておらず、積極的に変わっていきます。
この手法では、要件→設計→製造→テストの開発プロセスを反復させながら、次第にプロダクトを成熟させていき、Webやクラウド型のSaaSを中心に昨今よく用いられていますが、多くは「MVP」という考え方に沿っています。

MVPとは、「実用最小限の製品： minimum viable product」の略で、
製品を提供する上で必要最小限の機能のみをもつ、もっともシンプルな製品を指し、一般的には「顧客価値があり、利益を生み出せる最小限のもの」という考え方です。

つまり、アジャイル型の開発には「ユーザーにとって価値があり、利益を生む、最低限の製品を少しずつ作り、成熟させていく」という思想があるため、テストも、確かな答えがないプロダクトに対して、開発チームと共に「答えを探し」ながら、このMVPの部分の品質を効率的に検証することが、重要なミッションになります。

このMVPの部分をどのようにテストするか？に決まった解はありませんが、
その時点のプロダクトとして「ユーザーに価値があり、利益を生む最小限のもの」が何を指すか、
機能的なアプローチだけでなく、UX（ユーザーエクスペリエンス）なアプローチなど、非機能的な考え方も必要となるでしょう。

「答え探し」のテストでは、バグの報告１つをとっても違います。
明らかに誰が見ても問題があると分かるバグは良いですが、「これはおかしい気がする」といった、感覚的な気づきや違和感も大事になり、報告するだけでなく、「それならどうすれば良いか」、「どうあるべきか」まで考えて、提案することが大切です。

まとめると…以下のようになります。

■答え合わせのテスト
　・ウォーターフォール型開発のテストアプローチ。
　・仕様が決まっており、その通りに動作するかのテストが主となる。
　・バグは、報告する事が主となる。
　・テストチームが開発に対して受動的な立場になる。
　
■答え探しのテスト
　・アジャイル型開発のテストアプローチ。
　・仕様の成熟にあわせて、ユーザーに価値があり利益を生み出す最低限
　　の製品としてテストする。
　・バグは、報告だけでなく、提案までする事が求められる。
　・テストチームが開発と能動的に伴走する立場になる。

これはどちらが良い悪いという訳ではなく、開発の手法に合わせたQA・テストのアプローチを変えていくことが大事なのですが、今後もアジャイル型の開発が増加する中で、QA専門会社やQAエンジニアも積極的に変革する必要があります。