アジャイル開発 | Enterprise Java | 株式会社アットウェア

はじめまして、サービス創生事業部の石上（いしがみ）です。
私からは、『テストによる品質の向上』について、少し述べさせていただきます。
みなさまは『テスト』を行う前、行うときに、プロジェクトでいつもおこなっていることはありますか？
例えば、
　・テスト種類を定義する。
　・テストの計画を立てる
　・どのように実施するかリソースを決める。
などです。
他にもいろいろあると思いますが、上記にあげたことは、とても重要で当たり前のようにやってきていることと思います。
テスト種類を定義するとは、単体テスト、結合テスト、システムテスト、受け入れテストなどで、それが決まれば、スケジュール（テストの計画）を立てたりしていると思います。（詳細には、もっと細かいステップを踏んでいると思いますが、、）
ただ、私が最近思っていることがあります。
『人』によって、それぞれのテストのレベル（又はスコープ、目的）の考え方が違うということです。
昨今のプロジェクトとは、協力会社の方とプロジェクトチームを形成することが多く、
継続的にプロジェクトチームを維持することが難しくなっていると感じており、それまでに積み上げてきたチームとしての考え方や手順とは違う、新メンバーの経験や文化や、使用してきたツールにより、それぞれのテストのレベルが違ってくるからです。
それは、新しい意見を取り込み、チームをよりよいものにしていくにはよいかもしれません。
ただ、それぞれのテストのレベルを定義せず、そのままにしておくと、各工程で、粒度の違うテストケースが出来、品質レベルが違うものが出来てしまうからです。
逆に言うと、定義したテストレベルは、ある程度品質を保っていると言えるのではないでしょうか？
（ある程度と言っているのは、すべてをテストすることは不可能であったり、人間はミスをするため）
では、どのように定義するのでしょうか？
ISTQB テスト技術者資格制度というものがあります。
これは、ソフトウェアのテスト作業に関与する全ての人を対象としているもので、テストの必要性からテストのプロセス、テストのレベルの定義、種類の定義、テスト技法まで幅広く定義しているもので、シラバス（Syllabus）を配布しております。
例えば、このシラバスをベースに、プロジェクト毎の品質管理基準を定義し、テストの標準化を図るということも考えられます。
そのシラバスの中に、
“「バグゼロ」でもユーザが満足しなければ役に立たない”
とありました。
まさに、私もその通りだと思います。
ソフトウェアとして作りこんだものが、「バグゼロ」でも、そもそも、使いにくいシステムや、ユーザの要件を汲み取れていないシステムでは、顧客満足を得ることが出来ないと考えています。
これからも、ユーザの満足する
“人々をしあわせにするシステム”
を創っていきたいと思います。