開発者もテスターとして行動する必要がありますか？[閉まっている]

私たちは3人の開発者、1人のデザイナー、スクラムマスター、およびプロダクトオーナーのスクラムチームです。ただし、チームには公式のテスターはいません。私たちに常にある問題は、アプリケーションをテストし、それらのテストに合格してバグを削除することが、PBI（製品バックログアイテム）が完了したと見なす基準の1つとして定義されていることです。

しかし問題は、アプリケーション（実装された3人の開発者と1人の設計者）がどれだけアプリケーションをテストしようとしても、いくつかのバグが見られず、利害関係者へのプレゼンテーション（マーフィーの法則）を台無しにすることです。

改善策として、新しいテスターを雇うことをお勧めします。仕事をしている人はテストであり、テストのみです。公式のプロテスター。

ただし、問題は、スクラムマスターと利害関係者が開発者（または設計者）もテスターである必要があると考えていることです。

彼らは正しいですか？開発者（デザイナーも）もテスターに​​すべきですか？

事前：テストされていないものをテストしていると見なされるものには、多くの混乱があるようです。確かに、すべての開発者はコードを作成するときにテストする必要があり、動作を検証する必要があります。彼女/テスターは、それが完了して十分だと思う前にテスターに​​渡すことができません。しかし、開発者はすべてを見ているわけではありません。彼らはバグを認識しないかもしれません。これらのバグは、徹底的なテストが実施される開発サイクルの後半でのみ発見できます。問題は、開発者がそのようなテストを実施すべきかどうかであり、私の控えめな意見では、プロジェクトマネージャーの観点からこれを検討する必要があります。

開発者はテスターに​​なることができますが、テスターであってはなりません。開発者は、意図せず/意識せずに、アプリケーションを破壊する可能性のある方法でアプリケーションを使用することを避ける傾向があります。それは彼らがそれを書いて、それが使われるべき方法で大部分をテストするからです。

一方、優れたテスターは、アプリケーションを拷問しようとします。彼/彼女の主な意図はそれを破ることです。多くの場合、開発者が想像していなかった方法でアプリケーションを使用します。開発者よりもユーザーに近く、多くの場合、ワークフローをテストするための異なるアプローチがあります。

また、開発者をテスターとして使用すると、開発コストが増加し、専用のテスターを持っているほど製品の品質にメリットがありません。安くてテスターがうまくやらせることができるのであれば、開発者に作品のクロステストをさせません。開発者とテスター間のフィードバックループが非常に高価になった場合にのみ、開発者に互いのコードをクロステストさせますが、私の経験ではそれはめったになく、プロセスに大きく依存します。

それは、開発者がだらしなくて、すべてをテスターに​​任せるべきだという意味ではありません。ソフトウェアはテスターに​​渡す前に、単体テストでバックアップし、技術的なエラーを最小限に抑える必要があります。それでも、ここで修正したり、開発者が予見できない問題やその他のバグを壊したりすることもあります。また、統合テストは主に開発者が行う必要があります。テスターの主な目的は、要件が満たされていることを確認することです。

このような小さなチーム（およびアプリケーションのサイズにも依存します）では、ユニットテストとUIテストを作成するハイブリッドロールのテスターを見ることができます。必ず雇うべきです。

ただし、テスターよりも重要なのは、定期的なフリーズ/ブランチです。適切にテストされていないものは提示しないでください。機能を追加したり、何かを変更した場合、その機能を取り巻くすべてのものを再度確認する必要があります。あなたの会社がそうでない場合にのみ悪い評判を得るでしょう。不安定なものをリリースしないでください。顧客が特定の日付までにソフトウェアを入手したい場合は、十分に早く開発を停止し、適切にテストするので、バグ修正のための十分な時間があります。多くの場合、土壇場での機能要求は、適切にテストせずに不十分に実装したりリリースしたりするよりも、拒否する方が適切です。

開発者は、他の開発者のコ​​ードのテスターに​​なることができます。

しかし、独自のコードをテストすることは良い動きではありません。開発者は自分のコードについてメンタルブロックを持っている傾向があるため、包括的または適切なテストを設計するのは困難です。

これをうまくやっていると思う開発者は常にいますが、通常はそうではありません（そして多くの盲点があることは確かです）。

あなたが本当にテスターを雇うなら、開発者にお互いの作業をクロステストさせてください-つまり、Aがコードを書いてユニットテストをするなら、Bにそれらのユニットテストを見てもらい、他に追加できるものがあるかどうか確かめてください。そして、Bに（ユーザーとして）コードをテストしてテストさせ、欠陥を報告してもらいます。

これは完全ではありませんが、すべてを実行しようとする単一の開発者よりも優れています。

同僚は、ソフトウェアを壊すのが本当に上手な場合があります。なぜなら、彼らはそれを楽しんでいて、あまり気にしないからです-それは彼らのコードではないからです。

ジャーナリストは正確に書く傾向がありますか？つまり、すべての文法エラーを見つけるのは、修正者と編集者の仕事です。

それにもかかわらず、ジャーナリストは自分でいくつかのスペルチェックを提供します。それにもかかわらず、コレクターは別の重要な職業です。

開発者とテスターに​​ついても同じですが、QAが開発のさらに重要な部分であるという事実を除きます。優れた開発者であっても、製品がサポートしているすべての環境、ブラウザ、OSをカバーするために、すべてのテストケースを徹底的にテストする時間はありません。

開発するだけでなく、常にその仕事をしている場合、それは単なる事実を意味するだけです-彼はパートタイムのテスターです。

私たち（3人の開発者と1人の設計者）がアプリケーションをテストし、ユースケースを実装しようとしても、まだバグは見られず、プレゼンテーションを台無しにします...

1つまたは2つのスプリントに対して「制御された実行」を実行し、開発作業とテスト作業を個別に実行することを検討してください。そのような実行の最後に、収集されたデータを分析して、テストに費やした労力を調べます。

テストに多大な労力が必要であることがわかった場合、そのデータを管理者に渡します。これは、リクエストを裏付ける説得力のある証拠になります（現在よりも説得力があります）。

それ以外の場合（テストに時間がかからない場合）、それを改善するために追加の労力を投資することを検討します（またはその方法を学習します）。あなたが経営陣と計画している追加の労力について交渉してください-彼らは代わりにテスターを雇うことを好むかもしれないので。:)

...新しいテスターを雇うことをお勧めします。仕事をしている人はテストであり、テストのみです。公式のプロテスター。

ただし、問題は、スクラムマスターと利害関係者が開発者（または設計者）もテスターである必要があると考えていることです。

認めざるを得ない、あなたの会社の経営者は私にはかなり下手に見えます。私が意味する- [OK]を、見つけることは本当に難しいかもしれないどのように多く、細かなプロジェクトのための最高のだろうテスター。

しかし、少なくとも1人のテスターがいるのは安全な賭けです- 彼らがスクラム/ アジャイルであることを主張しながら、試してみるのをheするのは本当に面白いです。

さて、最初の開発者が入力画面にいくつかの変更を加えた後、2人の開発者にクロステストを実施しました。これは、通常のテスターが産休で休んでいたときでした。

彼は基本的に、ユーザーが「編集」ボタンで編集するためにズームインする前に請求書を選択するために使用した請求書リスト画面を変更しました。元のリストは破棄され、新しいグリッドビューが挿入され、フィルタリング、グループ化、ソート、あらゆる種類のクールな機能が追加されました。

テストは順調に進み、翌日に顧客に変更をアップロードしました。2週間後、顧客から電話があり、「私たちはあなたが入れた新しいものが本当に好きです。今、あらゆる種類の情報を見ることができます。しかし...えー.....今どこに請求書を編集しますか？ ??」

開発者はチェックボックス（選択用）と編集ボタンを取り出し、開発者は常にダブルクリックしてアイテムを選択したため、いずれも問題を発見しませんでした......

開発者とユーザーは異なる世界に住んでおり、クロステストを行う方が開発者が自分の作品をテストするよりも優れていますが、それでもまったく同じではありません。

ここで他の人が言ったように、開発者はお互いのコード（ユニットまたは機能テスト）をクロステストでき、おそらくスクラムマスターと製品所有者が統合テストを支援できますが、ユーザー受け入れテストについては、あなたが取得していることを確認する必要があります顧客のテストからの多くのフィードバック -これは、実際のユーザーが行う方法で作業できる頻繁な展開と、本当に開かれたコミュニケーションチャネルを意味します。

テスト容易性を念頭に置いて設計する必要がありますが、専用のテスターがいなければ、ソフトウェアの設計、実装、テストの両方に十分な時間がないので、いくつかのことが単純にひっくり返ってしまいます。

ソフトウェアのテストは、フルタイムのプロフェッショナルな仕事です。優れたテスターに​​なるには、優れた頭脳、才能、豊富な経験が必要です。テストが日々の仕事のほんの一部に過ぎない場合、ソフトウェア開発者がどれほど賢くてもプロのテスターに​​近づくことができると考えるのはばかげています。

さらに、ソフトウェア開発者が無意識のうちにバグを見つけたくないという問題があります。

開発者/デザイナーはコードをテストする必要があるという点に同意します。コードのセクションを作成したデザイナー/開発者は、ライブにコミットする前にそのコードの唯一の「目」ではありません。それがすべてをつかむわけではありませんが、少なくとも開発中に自分のコードをテストして再テストする際に忍び寄る盲目を避けるのに役立ちます。

ユースケースの言及から、コードカバレッジツールも使用していると思いますか？そうでない場合は、テストされていないコードを確認するのに役立ち、特定の条件で予期しないバグが発生する可能性があります。

そうは言っても、十分な仕事がある場合、または組織の規模が十分であれば、プロのQA担当者が必要であり、全員の役割をもう少し集中するのに役立ち、また、見逃されており、さらに重要なことは、それを修正する方法です。