Qaas

QaaS PRESSQaaS通信

答え合わせのテストから、答え探しのテストへ

2020.12.24
QaaS通信

こんにちは!
前回は、「モノづくりを加速させる企業になる」ことをビジョンに掲げ
新たなクアーズへリスタートをしていく事をお話しましたが、
今回は近年のソフトウェアテストのニーズの変化と、
求められるスキルについてお話ししたいと思います。

このコラムのタイトルにもありますが、
「答え合わせ」のテストではなく、『答え探し』のテストが、今もっとも求められています。

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

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

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

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

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

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

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

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

■答え合わせのテスト
・ウォーターフォール型開発のテストアプローチ。
・仕様が決まっており、その通りに動作するかを検証するテストが主となる。
・バグは、報告する事が主となる。
・テストチームが開発に対して受動的な立場になる。

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

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

当社もこれを今後の重要課題として取り組みを強化していく所存ですが、
顧客、開発と共に「答え探し」=「モノづくり」をすることが、
当社のビジョン『バグをなくして、モノづくりを加速させる』のに込められています。

———–
この記事はnoteでも投稿しています。
https://note.com/matyu142112/n/n8955e26e40db

Share :
  • facebook
  • twitter
  • pinterest
  • linkedin

エントリー受付中!

PAGE TOP