*専用*のテスターの役割を持たない開発チームの実行可能性[終了]

私は最近、無駄のない開発チームを構築する方法について多くのことを考えています。最終的には、志を同じくする少数の人々と私自身の小さなソフトウェアハウスをオープンしたいと思います。目標は金持ちになることではなく、健康的な職場環境を作ることです。

これまでのところ、無駄のないチームを次のように定義しています。

• 小さい;
• 自己組織化;
• すべてのメンバーはQAを念頭に置く必要があります。
• メンバーは複数の役割を実行できる必要があります

最後のポイントは、私が少し心配しているところです。マントラが進むにつれて...

開発者は悪いテスターを作ります。

多くの場合、開発者は自分のコードまたは同僚のコードに「近すぎ」て、品質のより高いレベルの評価を行うことを理解していますが、彼らが事実上悪いテスターであるとは確信していません。それどころか、優れた開発者の資質は優れたテスターの資質と非常に重なっていると私は考えています。

これが正しいと仮定して、私は開発者/テスターの問題を回避するさまざまな方法を考えてきましたが、私は実行可能なモデルを考え出したと思います。

私のモデルには以下が必要です：

• 2つ以上のプロジェクトがある小さなソフトウェアハウス
• 開発と配信に対するアジャイル（反復）アプローチ
• プロジェクトごとに1チーム
• すべてのチームメンバーはソフトウェア開発者になります
  • 彼らの職務記述書には、開発、品質保証、テスト、および提供が責任として明確に記載されています

これらの前提条件がすべて満たされている場合、プロジェクトは次のように編成できます（この例では、2つのプロジェクトAとBを参照します）。

• すべてのチームメンバーが開発者の役割とテスターの役割を交互に行います
• チームメンバーがプロジェクトAの開発者である場合、チームメンバーはプロジェクトBのテスターに​​なります
  • メンバーは、一度に1プロジェクトで作業しますので、として機能することが期待されているいずれかのDev やテスター。
• ロールサイクル（二つの異なるプロジェクトで、再び）Devのような3回の反復及びテスターとして2反復で構成されてい
• プロジェクトチームには、常に3つの開発者と2つのテスターがいます。
• メンバーの役割サイクルは、1反復だけフェーズがずれている必要があります。
  • これにより、チーム変更の突然の発生を最小限に抑えることができます。各反復で、2つのDevsと1つのテスターが前の反復と同じままです。

上記を考えると、次の長所と短所がわかります。

長所

• 会社全体にプロジェクトの知識を配布します。
• チームメンバーが記述に役立つコードをテストしていないことを確認します。
• フェーズが異なるロールサイクルとは、100％メンバーの切り替えを行うプロジェクトがないことを意味します。
• 交互の役割は退屈なプロジェクトの単調さを壊します。

短所

• 両方のプロジェクトのイテレーションは密接に結合されています。1つのプロジェクトが途中でイテレーションをキャンセルして再開した場合、2つのプロジェクトは同期しなくなります。これは、役割サイクルの管理を困難にします。
• 開発者を採用する際のヒンジは、テスターとしても活躍しています。

このアプローチについて友人や同僚と話し合ったとき、私はさまざまなレビューを受けました。一部の開発者はこのような役割を代替したいと考えていると信じていますが、他の開発者は個人的に試してみたいと言っています。

だから私の質問です： そのようなモデルは実際に機能するでしょうか？そうでない場合は、作業モデルに調整できますか？

注： 簡潔にするために、私はDevおよびTesterの役割のみに焦点を当てました。必要に応じて、他の役割について詳しく説明します。

同意しない

開発者は悪いテスターを作る

私のキャリアで取り組んだほとんどのチームは、QAサポートを受けていません。これには、グローバルログインや登録システムなどの製品を使用するいくつかの大規模なグローバル企業が含まれます。別のケースでは、会社の収益の30％を自分の机のボックスを介して実行しました。（これらのプラクティスはBTWには推奨されません;））これらの企業は、コードが正しく機能することを確認するためにエンジニアに依存していました。そして、私たちは細部に気を配り、少し強迫的で、私たちの仕事を誇りに思っているので、ソフトウェアが正しく機能することを確認するために、最大限の努力を払います。

また、開発者として、テスターよりもはるかに多くのテストを行っています。私は定期的にコードを90％まで、またはJavaを使用していない場合は100％までユニットテストします。

私はテスターと一緒に働くのが好きです。テスターは別の視点からやって来て、私が思いもよらなかったものを捕まえるからです。しかし、私は自分が100％の責任を負う一方で、約30-50％を超えるテストカバレッジを提供することを実際に期待していません。（ところで、それは彼らを非難するものではありません-それらは通常プロジェクト全体に薄く広がっています。）

面接でエンジニアにQAを実行するかどうかを尋ねるのではなく、次のように尋ねます。バグを紹介し、お客様がそれを経験した場合、私は気分が悪く、責任を負います。QAの人たちを責めません。IMHOそれはあなたが雇いたい（そして一緒に働きたい）エンジニアのようなものです

品質を確保するための私の方法は、a）非常に積極的な単体テストです（ただし、完全なテスト駆動開発を行うことはできません）、b）強力なコードレビュープロセスは本当に役立ちます。チーム文化への欠陥。

彼らがより大きな問題を指摘する可能性があるので、最も年配の男性は、軽微な問題でさえ最も勤勉で注意深い人であったことをいつも私は思いました。しかし、主に彼らはそれを正しくするために最も時間を費やすことをいとわないものでした。

しかし、私が取り組んできたほとんどのチーム、特に小規模な企業には、正式なQAコンポーネントがありませんでした。

@Rob Yの回答に同意し、いくつかのポイントを追加したいと思います。

• アジャイルでは、チーム内の専用のテスターは、チームに作業をパイプラインで強制し、本質的に非効率になるため、アンチパターンです。あなたは絶えず「開発された」が、テストされていない物語に終わります。専用のテスターは、チーム外（または別のチーム）で作業する場合は問題ありません。

• 開発者は悪いテスターを作る...そしてテスターは悪いテスターを作る。QAは難しいです。実際、それは非常に困難です。あなたの問題は人や役割ではないかもしれません。あなたの問題はあなたのソフトウェアが急いでいるということかもしれません。繰り返しになりますが、アジャイルでは、本番前にテストすることはチームの責任です（専用のQAがあるかどうかにかかわらず）。

• QAは、リファクタリング、アーキテクチャーなどの開発の一部です。ソフトウェアを特定の、合意された、現実的な標準に合わせて作成するのは、開発チームの責任です。QAはその標準を改善しません。より良い開発者はおそらくそうするでしょう。

• 挑発：QAはQA-ingの開発者より優れていると誰が言っていますか？それは人々が言うことですが... [要出典]。QAに必要な「ハッカー」の考え方は、開発者の考え方です。実際、基本的にすべてのハッカーは開発者であり、開発者であり、QAではありません...

• 挑発2：QA作業の99％は、スクリプトを介して自動化できます（もちろん、自動化する必要があります）。優れたチームがこれを行います。これを適切に行うには、開発者が必要です。

以前の仕事では、開発者のみでQAスタッフはいませんでした。その結果、問題が本番環境に到達した場合、他に責任を負う人はいませんでした。私たちはQAの責任を非常に真剣に受け止め、自動化されたテストスイートに大きく依存していました。自動テストの作成はまだコーディング中であるため、開発者にそれを実行させることは大したことではありませんでした。

重要なことは、それをチームの文化の一部にし、すべてのプロジェクトの一部にすることです。テスト計画（プロジェクト用に作成する予定のテストの簡単なリストのみ）を作成し、他の開発者は見逃したケースやシナリオを確認して提案しました。

あなたがそれについて厳密であるならば、それは非常にうまく働くことができます。それは私たちのためにありました-私たちは常に稼働しているeコマースWebサービスで優れた稼働時間と低い欠陥を抱えていました。

最初の警告-私はQAエンジニアとソフトウェアエンジニアの両方として専門的に働いてきました。

そのようなモデルは実際に機能するでしょうか？

何でも可能です。

多くの場合、開発者はコードまたは同僚のコードに「近すぎて」品質のより高いレベルの評価を行うことを理解していますが、それらが事実上悪いテスターであるとは確信していません。それどころか、優れた開発者の資質は優れたテスターの資質と非常に重なっていると私は考えています。

必要なテストの種類によって異なります。面倒な、単調で反復的な手動テストが必要な場合は、すべての画面または要素が実際にElbonianに翻訳されていることを確認してください...問題が発生します。

そして、私の経験では、すべてのプロジェクトがこの種のテストを少なくとも少しは必要とします（すべてのプロジェクトがその種のテストをしたわけではありませんが）。問題は、QAのベストプラクティスに慣れていない人からこの種のテストを受けられないことです。地獄、あなたはベストプラクティスを知っている人からそれを得ることさえせず、開発者を「信頼する」。

テスターとして、開発者を信頼することはできません。「その変更によって引き起こされたのではないか」または「開発ボックスで完全に機能する」というバグの数を失いました。

5週間のうち2週間、やりたいことをやらないことを許容できる開発者を見つけることができたとしても、このコアの矛盾に遭遇します。さらに悪いことに、1つではなく2つの仕事が得意になるように人々を訓練するために、時間とエネルギーを費やしています。企業は、2つの仕事はもちろんのこと、1つの仕事が得意な人を見つけてトレーニングするのに十分な時間を費やしています。

たぶん、あなたは私がまだ遭遇していないある意味で素晴らしい人ですが、私はそれを疑っています。

私はそれがうまくいくと思いますが、私があなたがそうすることを確認するいくつかのことがあります。

1. 候補者の二重の役割について非常に前向きである。それは多くの理由で皆のためではありません。それを嫌う人が多すぎると、失敗して離職してしまいます。
2. これをチームに組み込むための最良の方法を評価できる計画を立ててください。一度に1つのタスク/プロジェクトに集中するのが好きですが、非常に長い期間プログラミングをしたくないのかどうかはわかりません。たぶんテストはプログラミングから離れて素晴らしい休暇です。変更のためにいくつかの異なる脳細胞を使用するのは簡単ではありません。何が最善かを決める前に、さまざまな方法で試す準備をしてください。

プロジェクトの同期は実用的な解決策のようには見えません。誰かがプロジェクトのテスターである場合、彼らはプログラマーを置き換える最も良い候補であり、逆もまた同様です。

この計画では、チームが十分に自己組織化できません。1つの戦略では、おそらくすべてのチームとすべてのプロジェクトに対応できるわけではありません。