このような記事を読みました。
品質とは要求を満たすこと
http://jibun.atmarkit.co.jp/lskill01/rensai/pm_kiso06/pm_kiso01.html
一番気になったのは「品質を管理するとは？」という箇所です。
品質の管理を意味する英語に、
Quality Management（QM）、Quality Control（QC）の２通りがあるそうです。
以下が引用内容です。
--------------------------------------------------------------------------------------------------------------------------------------
不良品を出さないようにするために、テストを厳しく行ったり、製造の手順を変えたりするような活動を
QC（日本的品質管理）といいます。
一方、成果物を生成するプロセスが適切に運用されているかを管理の対象とした品質向上のためのさまざまなプロセス、
取り組みをQM（品質マネジメント）といいます。
--------------------------------------------------------------------------------------------------------------------------------------
私は、社内におけるソフトウェア開発部単体テストチームの今までの活動は、
上記の２分類のうち、どちらかと言えばQM（品質マネジメント）的な活動だった様に思います。
各自、テストを行ったらエビデンスを提出しましょう、単体テスト結果報告書に記述して提出しましょう、
といった内容ばかりに着目していました。
そうすれば、「テストが甘い」という消極的発言が減り、テスト意識が向上すると私自身も思い込んでいました。
確かに以前よりはテストをして自分の作成したプログラムが正しく動くことを確認する、テスト結果をきちんと残す、という意識も行動も
以前よりは確実に向上していると思います。
品質向上に向けての第一段階は、既に踏み出せているはずです。
しかし、そろそろもっと１ランク上の視野でテストについて考えなければならない時期なのではないかと思います。
今度は、テストパターンについて考えなければならないと思います。
仕様に基づいたテストパターンというのは各システムやプロジェクトに依存するもので、
SEの引継ぎ頼みになりすぎています。
プログラマの本人テストであれ、第三者のテスターテストであれ、
その仕様（要求）を満たすための正しい動きをするための考慮の不足が
テストが甘いと言われる一番の原因なのではないでしょうか？
バグを多く出してしまったり（プログラマの本人テストで本人が確認しきれなかったバグという意味）、致命的なバグを発見できない
というのは、どのような動きが最善と考えられるか、といった動きの想定が甘いからだと思います。
私個人が思う、アイロベックスのよいところは、
「品質が高く、作成スピードが早い」という点だと思っていますし、これからもそうあり続けたいと考えています。
一人一人がもっとテストパターンに敏感であればある程、
品質の高さ、作業スピードを保つ事ができるでしょう。
会社全体としてよい品質という事を考えた時に、新人であれベテランであれ、
よりよい結果を出す仕組み作りというものをソフトウェアテストの観点からも行っていかなければなりません。
これからは、QC（日本的品質管理）的活動も進めていきたいと思います。
