プロダクトの品質を上げるには、会社ぐるみで品質管理に取り組む意識が重要です。
より良いソフトウェアテストを実現する為の企業文化として、大事だと思うことを幾つか挙げてみたいと思います。
新人にまずやってもらうことは？
新人テスターをいきなりテストに参加させるのは良くありません。製品への理解が深くないと有効なテストは出来ないからです。
まずは製品の仕様を覚えてもらったり、バグレポートの書き方を覚えてもらったりしなくてはいけないのですが、仕様書をポンと渡して、「これを見ながら製品を全部動かしてみて」といった指示を出しても現実味がなくモチベーションは揚がらないでしょう。
最初にやってもらうことは、先輩テスターの書いた障害報告の再テストか、
画面遷移図の更新など手探りで学習しながら行えることが良いと思います。
極力固定したビルドでテストする
テスト対象のビルドは極力固定されていなくてはいけません。
忙しさ故ずるずると変更を受け入れがちですが、わずかでもコードが変われば新たなバグが発生する可能性があるからです。
一番難しいのが、変更箇所として伝えられた箇所以外にも何らかの手が入っている場合です。予測出来ないバグを潰すことはとても困難です。必ずすべての変更点を明らかにしておかなくてはいけません。
本番同様の検証環境を用意する
本番と別に開発環境のあることが多いと思いますが、検証を行う環境は可能な限り本番に近い状態に保たなくてはいけません。検証の為に本番から大量のデータをコピーするなど、これは相当手間がかかります。
しかし、両環境に乖離があれば「この問題は本番だとちゃんと動くはず」というバグ修正は絶対に出てきます。この修正が正しいことをどうやって本番反映前に証明することが出来るでしょうか。
そういった綱渡りのようなスタイルの修正が成功する率はかなり低いでしょう。
バグを隠さない
コードにバグがあることは好ましくないのですが、バグ発見を忌み嫌うような空気が職場に蔓延すると、結果としてバグを隠すようになります。
そうなっては逆に問題なので、前向きに捉えるように努力しなくてはいけません。
このへんはバランス感覚が難しいところですね。
テストにかかる工数を忘れない
何故かコードを書くとなると、人はコーディングの終了イコール完成だと考える傾向にあるようです。（このことに関しては自分も人のことは言えませんが。。）
名著「人月の神話」では工数配分の例として 設計1/6 コーディング1/3 テスト1/2という比率を示しています。
趣味のプログラムではないので、検証にかかる工数を忘れないように現場の意識を保つようにしましょう。
テスターは早期にアサインさせる
仕様がなかなか決まらずに見切り発車でコーディングが進んでいる場合など、テストも泥縄式にテストケースを書いて実施することがあります。そんな調子だと十分な品質は確保出来ないでしょう。
テストは設計と表裏一体であると言えます。テストケースを記述することで設計の問題点を明らかにすることが出来ますから、テスターはなるべく早期にアサインすべきです。
Tipsを共有する：Googleの例 TotT
テスト担当者同士での情報交換を活発にするのも良いですね。
好ましい例としてGoogleにはTotTという習慣があり、トイレの壁にテストのTipsが貼ってあるそうです。#TotT = 'Testing on the Toilet'の略
google_testing_blog posted by (C)フォト蔵
Google Testing Blog
http://googletesting.blogspot.com/
Introducing "Testing on the Toilet"
思い当たるところを書いてみましたが、他にもあれば是非コメントくださいね。
今回はテスト視点でしたが、プログラマ視点で「より品質の高いコードを書く為の企業文化」という話も面白そうですね。
多分そのうちウノウプログラマー軍団の誰かがエントリを書いてくれることでしょう。乞うご期待。