その1を書いてから間が空いてしまいました。
No More Second Class Testers! という面白いコラムを、引き続きご紹介しましょう。
なぜ１流のテスターでなければいけないか
テスターは商品開発における重要な役割を果たします。
テスターは開発中の製品の情報とテストに関する情報を提供します。
テスターには少なくとも3種類の相手（客）がいます。
・開発者には、分かりにくい箇所、テスタビリティ、そして動作しない箇所について報告します。
・ユーザーには、サポート係を通して製品の情報を提供します。
・開発マネージャーには、リリースのリスクについて情報を提供します。
１流のテスターは、コードが書かれている前にシステムのデザインとアーキテクチャを評価することができるくらいクリエイティブです。 コーディングが進む間、テストの準備を整えます。テストカヴァレッジを測定し、リリース可能なくらい、システムのリスクが低くなっているかを調査します。
3種類の相手（客）がいるっていうのはまさにその通りですね。
でも自分の考えでは、QAは第一にユーザーの味方だと思っているので
ここに書かれているユーザーへの効果はちょっと控えめかな？と思います。
では、１流のテストグループを組織するにはどうしたら良いでしょうか？
理想を思い浮かべて、それに向かって努力してみるのもいい方法です。
１流のテスターは何を行うか
理想的なテスターは何を行うでしょうか？テスターは製品をテストするだけではありません。私は、テスターをプロジェクトの調整役として、技術レビューアとして、モデレータとして、デザインチームのメンバーとして、そしてテストツールの開発者として役立てました。
私がテストチームを組織したとき、深い技術的知識と様々なテスト技術（自動化を含む）を持った人々を主に雇いました。開発者は自分の書いたコードを完璧にテストすることはできません。
Robert Glassは'Facts and Fallacies of Software Engineering'で
彼らが自分達のコードを「完全に」テストしたと考えたとき、ロジックの55%～60%がテストされたと述べています。
更に、Capers Jonesは'Assessment and Control of Software Risks'で
系統的なブラックボックステストがテストできるのはコードの30%未満に過ぎないと断言しています。
あなたの製品について考えてみてください。どんな種類のテストを必要としているでしょうか？
私なら、要件ごとにテストをする人ではなく、境界値分析、同値分割、結合テスト、探索的テストが出来て製品を最初から終わりまでテスト出来るかそれを学ぶことの出来る人を雇います。
Cem Kanerは"Recruiting Software Testers"の中で、その製品の専門家をテストグループに加えると大いに役に立つと述べています。多くの複雑な製品において、彼は正しいです。
私は製品のヘビーユーザーだけで構成された多くのテストチームを見てきましたが、残念ながらそれらは２流でした。ヘビーユーザーと技術のあるテスターを組み合わせた場合は極めて有効でした。
～
１流のテスターは何を知っているか
理想的なテスターは何を知っているでしょうか？
製品により必要な知識は違っています。
技術知識を評価するとき、私は技術的専門知識の4つの領域を評価します。
・機能的な知識 すなわち、様々なテストの手法に精通しているか
・製品分野の知識 製品の機能についての知識、どれくらいすばやく学ぶことができるか
・ツール/技術の経験 既にツールか技術経験を持っている人々は、それ無しの人より生産性が高いです。
・産業の専門的技術
より大きくより複雑な製品は、多くの知識があり製品について学ぶことの出来るテスターを必要とします。
日本で言う「テスター」の守備範囲からは大分離れて来ました。
QAにも普通のエンジニア並に大きなスキルスケールがあるのです。
あなたのチームに足りないものは何でしょう
では、現実とのギャップはどうやって埋めれば良いでしょう？
採用面接ではどのように応募者の能力を判断していますか？
・テストツールを開発することの出来るテスターを雇いたいならば、開発者と同様の試験を課すべきです。
・コードを読んでテストを実施することの出来るテスターを雇いたいならば、コードを見せて、そこからどんなテストを実施しようと考えるか質問してみると良いでしょう。
・テスト技術に精通した人を雇いたいなら、設計について議論する場を設けて設計に基づいてどんなテストを行うか尋ねてみると良いでしょう。
・リスク管理に関心があるなら、過去どんなプロジェクトで何を行ったか尋ね、例えばどんな風に報告をしてくれるのか試してみれば良いでしょう。
テスターによって得意分野は異なります。
あなたはプロジェクトにとってどのスキルが一番好ましいかを見極める必要があります。
ナルホド！確かにその通り。
求職中のQAの皆さんは準備をしておきましょう。
まとめ
１流のテスターはバグ探し以上の働きをします。
あなたの組織で２流のテスターを使う道理はありません。
要求を満たす適切なスタッフを雇ったり、訓練したりしましょう。
いやあ、興味深いです。
日本はソフトウェアQAの認知度が低いせいか、こういうコラムはあまり見かけないですよね。
そもそもテスターという仕事の求人がほぼありませんし。
転職サイトの履歴書に「QAです」と書いておいても、
問い合わせが来たのは年に1～2件だった覚えがあります。
かといって品質が悪いかというと日本の製品の品質は世界でも相当良いワケで、QCは盛んです。
要はエンジニアが品質問題まで担当するという形なのですね。
ISO9001の取得を考慮すると品質管理部が必要なのですが、
設置しても実務には関わらないスタイルもあるようです。
さて、WEBアプリ開発にはどういった組織形態が適しているでしょう？
個人的には技術の進化スピードと仕組みの複雑さ（まさに混沌）からいって、
得意分野で適度に分業化するモデルは有効だと考えています。
このコラムで述べているように「１流のテスター」を使うことも考えると
色々な組織形態のバリエーションがありそうですね。