はじめに
みなさんQAチームってご存知でしょうか。
QA・・・Question and Answerではありませんよ(お約束)・・・「Quality Assurance」すなわち品質保証の略です。
字面をそのまま解釈すれば、プロダクトを検査(テスト)して、その品質を保証する人たちです。
では、保証する対象となる「プロダクトの品質」って何でしょう。
いざ「プロダクトの品質とは何か？」と言われると、概念としては理解できると思いますが、具象例として即答するのは難しいのではないでしょうか。
私もQAチームの一員として製品に関わって幾年月・・・「QAチームとは何ぞや？」という壮大なテーマで、普段頭の中でなんとなく考えていることをアウトプットしてみたいと思います。
しばしのお付き合いをお願いします。
QAチームの目的とは
何かしらの作業が発生する際には、目的(何のためにやるのか？)を設定する必要がありますが、QAチームの目的って何でしょう。
いったん、先ほど述べました「プロダクトの品質を保証する」ということにしましょうか。そうなると「プロダクトを検査(テスト)する」はゴールに向かうための手法ですね。
人が複数集まれば今度はルールが必要になります。次に手法(テスト)のルールを考えてみましょう。
テストでどんなルールが必要か考えてみますと、ざっと
- 何をテストするのか (テスト対象)
- どういうアプローチでテストするのか (テスト観点・テスト手法)
- どうすれば結果がOKになるのか (合否条件)
- どうすればテストが終わるのか (終了条件)
というようなことが挙げられますね。
では、これらルールの詳細を決めるにはどうすればよいでしょうか・・・。
一貫した内容にしたいので、思いつきや行き当たりばったりではなく、決めるための「考えの軸(拠り所)」がほしいところですね。
では、次からは「考えの軸」について考えていきます。
誰のための品質か
まず初めに、「誰のために」ということを考えてみましょう。
そもそも、プロダクトはいったい誰のためにあるものでしょうか。少なくともパッケージソフトウェアでは、製品を購入し使用するユーザーのためにあるといえます。
そうなると、QAが保証する品質はユーザーのために、ということになりますね。
ここで、「ユーザーのためにプロダクトの品質を保証する」ということが、第一の考えの軸にしてみましょう。
では次に、「品質を保証する」ということについて考えてみます。
プロダクトの品質を保証するとは
「プロダクトの品質を保証する」とは、二つのプロセスから成り立ちます。
それは、「プロダクトの現在の品質状態を明らかにする」と「プロダクトの品質を高める」です。
このうち、「プロダクトの現在の品質状態を明らかにする」は、その手法として「テスト」を使用します。すなわち、テストとは「ソフトウェアの品質状態を明らかにすること」です。
「プロダクトの品質を高める」については、プログラマの協力が不可欠です。なぜなら、直接的にプロダクトの品質を高めることをできるのは、ソースコードを触ることができるプログラマだけだと考えるからです。（もちろん、QAチームでもソースコードを修正することは可能ですが、それを行うと自作自演というか、ワンオペというか、検証から客観性が損なわれてしまい、結果として不具合検知率が低下してしまうので、現在のアプレッソではやっていません。)
よってQAチームとしては、「現在のプロダクトの品質状態をプログラマにしっかりと認識してもらい、どうすれば品質が高くなるかをプログラマと一緒に考え、考えた結果(答え)を実践する」ということを行わなければなりません。
これが、QAチームができるプロダクト品質を高めるためのアプローチです。
「現在の品質状態を明らかにしたうえで、プログラマと一緒に品質を高める」を第二の考えの軸にしましょう。
目指すべき製品品質のビジョン
では、目指すべき品質というのはどういったものになるでしょうか。
目指すべき品質のビジョンができていないと、プログラマと協力して品質を上げる、ということが達成できません。
ではどうすればよいのか。一つの具体的な例を書いてみます。
「こうあるべきだ」という品質のビジョンを固めます。具体的には、逆説的に「こういう問題が起きたらダメ」というNOリストを、「ユーザー目線」という考えの軸を基に作っていきます。
リスト項目は、できるだけ具体的なほうがよいです。たとえば、「製品が起動しない」「動かしたらエラーになる」「メモリリークしている」「以前は正常終了していたのにバージョンアップしたらエラーになる」などなど、実際に使われるユーザーをしっかりとイメージしながらピックアップしてみます。内容については、後々のためにプログラマとも共有しておくとよいです。
すなわち、
「こういった問題が起きない製品」=「ユーザーが困らない製品」=「目指すべき製品品質」
となります。
内容に応じて、レベル分けするのも良いでしょう。実際にアプレッソでは、7段階のレベルを設けています。そして、計画段階で、その製品がクリアしなければならないラインを決めます。
こうすると、「どんな内容の問題を事前に潰しておかなければならないのか」というゴールが明確になり、ひいてはテスト戦略が明確になります。
なお、リスト項目は、新たに問題を検知した際の判断にも役立ちます。どのレベルに属する問題なのか。それによって、修正すべきかどうかの判断が明確にできるようになります。
こういった客観性をもった評価材料があると、プログラマに対するアプローチもしやすくなります。ないと、追い詰められたプログラマが「これ修正しろって言っているが、報告者の恣意的な判断が入っていないか。きっと俺が気に入らないのでわざとやっているんだ・・・」と疑心暗鬼に陥ってしまうかも知れません。QAとプログラマとは、ある程度の緊張感の中でしっかりと信頼関係を築いておくべきですので、疑いの目を向けられるのはできれば避けたいところです。
こうして、第三の考えの軸である「検知した問題を客観的に評価できる軸を作る」が定義できました。
考えの軸を基にルールを決めてみる
では、最初に挙げた決め事を、以下の3つの考えの軸を基に決めてみます。
- ユーザーのためにプロダクトの品質を保証する
- 現在の品質状態を明らかにしたうえで、プログラマと一緒に品質を高める
- 検知した問題を客観的に評価できる軸を作る
何をテストするのか (テスト対象)
ユーザーが触れる場所。優先度は使用頻度の高い機能からとする。
どういうアプローチでテストするのか (テスト観点・テスト手法)
計画段階で決めた、製品がクリアしなければならないライン以上の問題が検知できる観点を考え、最適なテスト手法を当てはめる。
→ より突っ込むのであれば、製品導線やユーザーの動線に応じて、シナリオ化してみる。そのシナリオをもとに観点を導き出し、最適なテスト手法を当てはめる。
どうすれば結果がOKになるのか (合否条件)
ユーザーが期待する動作になっているかどうかで判断する。具体的には、ユーザーが見るであろうマニュアルの内容や、他の機能との動作統一感から期待する動作を導き出す。
どうすればテストが終わるのか (終了条件)
計画段階で決めた、製品がクリアしなければならないライン以上の問題が検知されなければ終了。検知された場合は修正後に回帰テストを行う。
いかがでしょうか。
「QAチームのテスト」を定義する
ここまでくれば、QAチームのテストの定義づけが可能になります。それは、「ユーザー目線のテスト」(すなわち「ブラックボックステスト」に近い)です。
プログラマのテストは「内部実装視点のテスト」(すなわち「ホワイトボックステスト」に近い)であるため、明確な住み分けができます。
アプレッソでは原則をそのような住み分けにして、と言っても固執しすぎず、柔軟に相互補完しながら楽しく(ときどきつらく)製品開発を行っています。