十分に小さい組織では、完全に独立した QA と開発の役割を持たせるべきですか、それとも各役割に一定の時間 (たとえば、週に 1 日) 他の側の役割を果たさせるべきでしょうか?
単体テストについて話しているのではありません。私が話しているのは、システムに焦点を当てた QA が実稼働コードにも貢献していることと、開発者がシステムの別の部分の分析とテストに時間を費やしていることです。
この種のジャグリングは理にかなっているかもしれません。なぜなら、QA はシステムをよりよく理解し、個人的な利害関係を得るのに対し、開発者は単体テストを超えて品質とテストの問題をよりよく理解するからです。しかし、それには反対の理由もあると確信しています...
考慮すべき点:
開発者は本番コードと単体テストの作成に集中する必要があると思いますが、QA は統合テスト、テストの自動化、および受け入れレベルのテストに集中する必要があります。QA チームが優れていて、API ドキュメントが優れている場合、QA が仕様に従って API を実行する単体テストを作成しても問題ないと思います。
私が一緒に働いた多くの QA 担当者は、自動化スクリプトなどの手続き型コードの記述に習熟していました。特に複雑なオブジェクト指向の設計パターンが使用されている場合や、基本レベルのコーディングを超えたものが使用されている場合は特に、製品コードを作成してもらいたいかどうかはわかりません。
私の意見です。
私はそれがうまくいくのを見てきました：
テスト駆動開発を行うアジャイル ショップでは、CppUnit を知っている C++ 開発者が、社内の GUI 自動化ツールを使用して自動化する方法を知っているテスターとペアを組みます。ストーリーごとに、ユニット/GUI テストのどのブレンドが最も効果的かを決定し、協力してテスト/コードを作成します。テスト担当者は C++ を知らずに入社し、開発者は GUI 自動化を知らずに入社しました。このアプローチを採用した最初のプロジェクトが全社的なプレゼンテーションを行うほどの成功を収めました。そのプロジェクトの誰も、テスターが開発者より 1、2 スプリント遅れていた「古いやり方」に戻りたくありませんでした。
Bug Bashes、Guerilla Testing、名前は何でも構いませんが、開発者が製品をテストする場所です。私はこれが発見されたバグの点で成功したいくつかの店にいました。 少し構造とレポートを追加したい場合は、セッションベースの探索的テストが役立ちます。
プログラミング スキルを持つテスターが、ジュニア プログラマーとしてしばらく開発チームで働きます。ある例では、そのタスクは、一部のレガシ コードに対するチームの C++ 単体テストを強化することでした。
私の経験では、QA は製品と顧客を可能な限り理解する必要があります。彼らは、製品の問題領域に精通している必要があり、コード変更を必要としない問題について、レベル 2 のカスタマー サポート スタッフと同様に、顧客の問題をトラブルシューティングできる必要があります。また、テスト スクリプトは必要ですが、すべての QA スタッフがスクリプトを記述できる必要はないため、すべての QA スタッフがプログラミングの能力を必要とするわけではありません。実際、プログラマーではない方が、コーディングの達人である場合よりも多くのバグを QA が発見することになります。
さらに、QA スタッフがシステムの一部をコーディングすることを許可した場合、その部分にバグ レポートがあるとどうなりますか。彼らはバグ修正を引き継ぐのでしょうか? その場合、誰がバグ修正の QA を行いますか? そうでない場合は、コードを知っているときにプログラマーの変更を QA できますか。コードを知っていると微妙なバイアスがかかるため、そもそも QA を使用します。彼らにとって、システムはブラックボックスであり、入力が正しい出力を生成することを確認するのが彼らの仕事です。これがどのように行われるかを知ることは、彼らの仕事ではありません。そして、その効果を低下させる盲点を作成する方法を知ることができます.
反対に、統計的に有意な数のコーダーが「テスト」を嫌います。または、テストを単純/初心者レベルのものと見なします。彼らを QA で働かせることは、生産性に影響を与える士気に影響を与える可能性があります。
短い答え: いいえ。
QA 担当者として、プログラミングを行い、新しい機能を実装しました。システムをより深く理解できたので、より良いテスターになりました。従うべき主なルールは 2 つだけでした。1) 独自のコードを QA することはできないため、QA チームに少なくとも 2 人が必要です。2) 標準開発プロセスを経る必要があります。つまり、主任開発者によるコード レビューが必要です。
他家受粉は便利です。追加のスキルを習得するのに役立ち、必要に応じて従業員を簡単に入れ替えることができます。さらに、自我を抑えるために、QA がキックバックで少しやけどするのは良いことです。
すべての会社は異なります。ある会社でうまくいったことが、別の会社でも自動的にうまくいくとは限りません。
とはいえ、確かに、可能な限りバランスのとれた従業員を持つことは理にかなっています。知識が多ければ多いほどよい。新しいリリースにコードを寄稿するよう誰かに強制する必要がありますか? それが厳密な要件であるべきかどうかはよくわかりません。しかし、少数の人しかいない場合は、知識を広め、誰かが去ったときに失う知識を減らすためだけでなく、おそらく人よりもはるかに多くの仕事をしており、「私は部門 X で働いていますが、それには触れません。申し訳ありません」などのゲームをプレイする余裕はありません。
確かに合理的で実用的なように聞こえますが、厳密で迅速なルールはありません。優れた開発者が悪いテスターである場合、私はそれを否定しません。逆の場合も同様です。
この種の「相互受粉」を持つことは素晴らしいアイデアだと思います。開発者とテスターがそれぞれの役割をよりよく理解することで、より効果的に協力できると信じています。
彼らをお互いの立場に置くことで、お互いをより理解し、協力し合うことができます。彼らは、意見の不一致が生じたときに、相手の立場を理解するでしょう。
さらに、テストは開発者にとって素晴らしい学習体験です。少しのQAは、機能するコードを書くときに少し慎重になるために大いに役立ちます。
そうは言っても、QAはミッションクリティカルな本番コードを書くべきではなく、開発者はミッションクリティカルな機能をQAするべきではありません。