業務アプリケーションのテストの話（その１）
テストについて書いていく
ブログ更新するのは一年ぶりです。システム開発の上流工程と下流工程を行ったり来たりして、それなりに楽しいエンジニアライフを過ごしています。これまでテストに関する記事を書いたことはありませんが、ネタがそろってきたので書いて行こうと思います。
プログラマはテストが苦手
プログラマはテストに対して苦手意識を持っていたり、必要性はわかるんだけど面倒なのであまりやりたくないと考えたりしがちです。おそらく背景には
- テストに関する十分な教育を受けていない。作るのは好きでも、テストへの興味が薄いので自分で勉強しようとしない
- 自分が作ったコードの欠陥を自分で発見するのは、先入観があるので難しい
- プログラマの最大の関心事は品質ではなく、納期を遵守した製品のデリバリー
といったことがあると思います。
規模が小さいプロジェクトだと、少数のエンジニアで開発もテストも兼務してやることが多いと思います。一方で、テスト専任者またはテストチームを設置することで上記の2と3はある程度解決します。作業を分担することで開発者の負担を減らせるうえ、期間短縮および第三者の視点による品質向上が期待できるでしょう。
一方で、1の「テストに関する十分な教育を受けていない」という問題はわりと根深い問題です。諸先輩方も含め、テストタスクのあるべき姿をきちんと指導できる人は少なく思います。
テストが好きな人
個人的には、開発が大好きな人にはたくさんお目にかかれても、テストが好きで好きでたまらないという変態（暴言）にはお目にかかる機会はあまりありません。ただし、テストに向いている人というのは、ある種の特性を持っている気がします。
- コツコツやるのが得意。マメである
- 品質向上に貢献できると嬉しい
- 物事の不備を指摘することに躊躇がなく、性格が悪い（いい意味で）
- 独創的で、たまに他人が思いつかないような視点で不具合を見つけることがある
こうして列挙してみると、基本的にせっかちなプログラマという人種とは真逆の存在に思えなくはないです。
独立したテストチームの有効性
システム開発の現場においては、開発チームとは別に独立したテストチームを設置すると品質は向上する傾向があります。開発チームは製品を産み出すことに、テストチームは品質確認に、それぞれ集中できます。
また、テストチームがテスト仕様書を作成する過程で、要件定義書や外部設計書に対する第三者レビューの効果があり、設計不備を早期に発見することにつながります。
なお、テストチームが担うテスト工程は結合テスト以降であり、 単体テストは実装担当の開発者自身が行います。
１回目は以上です。それなりに書くのは疲れます。
次回は混乱するテスト工程の呼び方について書こうと思います。
