開発者はテスターとしても機能する必要がありますか？
私たちは、3人の開発者、1人のデザイナー、スクラムマスター、および製品所有者のスクラムチームです。ただし、チームには公式のテスターがいません。私たちが常に抱えている問題は、アプリケーションをテストし、それらのテストに合格してバグを削除することが、PBI（製品バックログ項目）を完了したと見なすための基準の1つとして定義されていることです。
しかし問題は、私たち（開発者3名と設計者1名）がアプリケーションをテストしてユースケースを実装しようとしても、いくつかのバグが見られず、プレゼンテーション（ マーフィーの法則 ）が台無しになることです。利害関係者。
対策として、新しいテスターを雇うことをお勧めしました。仕事をしている人はテストをし、テストのみをするでしょう。公式のプロテスター。
ただし、問題は、スクラムマスターと利害関係者が、開発者（またはデザイナー）もテスターであるべきだと信じていることです。
彼らは正しいですか？開発者（設計者も）もテスターになる必要がありますか？
事前：何がテストされていないものをテストしていると見なされるかについては、多くの混乱があるようです。もちろん、すべての開発者はコードを作成するときにテストする必要があり、コードが機能することを確認する必要があります。彼女/彼は彼/彼女がそれが完了し、十分だと思う前にテスターにそれを渡すことができません。しかし、開発者はすべてを見ているわけではありません。彼らはバグを認識しないかもしれません。これらのバグは、徹底的なテストが行われた開発サイクルの後半でのみ発見できます。問題は、開発者がそのようなテストを行うべきかどうかであり、私の考えでは、これはプロジェクトマネージャーの観点から検討する必要があります。
開発者はテスターになることができますが、テスターであってはなりません。開発者は、意図せず/無意識に、アプリケーションを壊すような方法でアプリケーションを使用することを避けがちです。それは彼らがそれを書いて、そしてそれが使われるべき方法でそれをほとんどテストするからです。
一方、優れたテスターはアプリケーションを拷問しようとします。彼/彼女の主な意図はそれを壊すことです。多くの場合、開発者が想像もしなかった方法でアプリケーションを使用します。開発者よりもユーザーに近いため、多くの場合、ワークフローをテストするための別のアプローチがあります。
また、開発者をテスターとして使用すると、開発コストが増加し、専用のテスターを設置する場合よりも製品の品質が向上しません。テスターが安くてもっとうまくやれるようになったら、開発者に彼らの作品のクロステストをさせないだろう。開発者とテスターの間のフィードバックループが高すぎる場合にのみ、開発者がお互いのコードをクロステストすることになりますが、私の経験ではこれはまれであり、プロセスに大きく依存します。
これは、開発者がずさんですべてをテスターに任せる必要があるという意味ではありません。ソフトウェアを単体テストでバックアップし、ソフトウェアをテスターに渡す前に技術的なエラーを最小限に抑える必要があります。まだ、ときどきここで修正を行ったり、問題を解決したり、または開発者が予測できない他のバグ、それで問題ありません。また、統合テストは主に開発者が行う必要があります。テスターの主な目的は、要件が満たされていることを確認することです。
そのような小さなチーム（およびアプリケーションのサイズによっては）で、単体テストとUIテストを作成するテスターがハイブリッドの役割でいるのを見ることもできます。 間違いなく採用する必要があります。
しかし、テスターよりも重要なのは、定期的なフリーズ/ブランチです。適切にテストされていないものは提示しないでください。機能を追加したり、何かを変更した場合は、その周辺のすべてを再度確認する必要があります。あなたの会社がそうでなければ、あなたは悪い評判を得ます。不安定なものをリリースしないでください。お客様が特定の日付までにソフトウェアを入手したい場合は、開発を十分に早く停止して適切にテストすることで、バグ修正のための十分な時間を確保できます。多くの場合、適切にテストせずに不十分に実装したりリリースしたりするよりも、土壇場の機能要求を拒否する方が良いです。
開発者は、他の開発者のコードのテスターになることができます。
ただし、独自のコードをテストすることは良いことではありません。開発者は自分のコードについて精神的なブロックを持つ傾向があり、包括的または適切なテストを設計することが困難です。
これをうまくやると思っている開発者は常にいますが、通常はそうではありません（そして、私には多くの盲点があることは確かです）。
あなたが本当にテスターを雇うことができるなら、開発者にお互いにクロステストしてもらいます-つまり、Aがコードを書いてユニットテストを行ったら、Bにそれらのユニットテストを調べて、他に追加できるものがあるかどうか確認します。そして、Bに（ユーザーとして）コードをテストしてもらい、欠陥を報告してもらいます。
これは完璧ではありませんが、1人の開発者がすべてをしようとするよりはましです。
同僚はソフトウェアを壊すのが本当に得意な場合があります。なぜなら、彼らはそれを楽しんで、それほど気にしないからです。なぜなら、彼らのコードではないからです。
ジャーナリストは正しく書く傾向がありますか？つまり、文法上の誤りをすべて見つけるのは、修正者と編集者の仕事です。
それにもかかわらず、ジャーナリストは自分でいくつかのスペルチェックを提供します。それにもかかわらず、コレクターは別の重要な職業です。
QAが開発のさらに重要な部分であるという事実を除いて、開発者とテスターについて同じです。優れた開発者であっても、すべてのテストケースを徹底的にテストして、製品がサポートするすべての環境、ブラウザー、OSをカバーする時間はありません。
開発するだけでなく、常にその仕事をしている場合でも、それは単純な事実を意味します-彼は非常勤のテスターです。
私たち（3人の開発者と1人の設計者）がアプリケーションと実装されたユースケースをどれだけテストしようとしても、いくつかのバグは見られず、関係者へのプレゼンテーションを台無しにしています...
1つまたは2つのスプリントに対して「制御された実行」を実行し、開発とテストの取り組みを別々に追跡することを検討してください。そのような実行の最後に、収集されたデータを分析して、テストに費やした労力を見つけます。
テストに多くの労力がかかることがわかった場合は、そのデータを管理者に渡します。これは、要求をサポートする説得力のある証拠です（実際よりもはるかに説得力があります）。今）。
それ以外の場合（テストにほとんど時間がかからない場合）、それをよりよくする（またはその方法を学ぶ）ために追加の労力を費やすことを検討してください。経営者と計画している追加の労力について交渉します。テスターを雇うことを好む可能性があるためです。 :)
...新しいテスターを雇うことをお勧めします。仕事をしている人はテストをしているだけで、テストしているだけです。公式のプロテスター。
ただし、問題は、スクラムマスターと利害関係者が、開発者（またはデザイナー）もテスターであるべきだと信じていることです。
認めざるを得ませんが、あなたの会社の経営陣は私にとってかなり下手に見えます。つまり、わかりました。プロジェクトに最適なテスターの数を見つけるのは本当に難しいかもしれませんが、結構です。
しかし、少なくとも1人のテスターを持つことは安全な賭けです-彼らがhesitate自分自身を主張しながら試してみるscrum/ agile。
さて、最初の1人がエントリ画面にいくつかの変更を加えた後、2人の開発者のクロステストを行いました。これは私たちの定期的なテスターが出産休暇に出ていたときでした。
彼は基本的に、ユーザーが請求書を選択して[編集]ボタンを使用して編集する前に請求書を選択するために使用する請求書リスト画面を変更しました。元のリストは破棄され、フィルタリング、グループ化、並べ替え、およびあらゆる種類の優れた機能を備えた新しいグリッドビューが挿入されました。
テストはうまくいき、翌日に変更を顧客にアップロードしました。 2週間後、お客様から電話があり、「私たちはあなたが入れた新しいものが本当に好きです。今ではあらゆる種類の情報を見ることができます。しかし...ええと....ここで請求書をどこに編集しますか？ ??」
開発者がチェックボックス（選択用）と編集ボタンを取り出したことがわかりました。開発者は常にダブルクリックして項目を選択しているので、問題はありませんでした。
開発者とユーザーは異なる世界に住んでいるため、クロステストを行う方が開発者が自分の作業をテストするよりも優れていますが、それでもまったく同じではありません。
開発者はお互いのコード（ユニットまたは機能テスト）をクロステストでき、おそらくあなたのスクラムマスターと製品の所有者は統合テストを手伝うことができますが、ユーザー受け入れテストについては、 たくさんのフィードバックお客様のテストから-これは頻繁な展開が実際のユーザーと同じように使用できることを意味します本当にオープンなコミュニケーションチャンネル。
ソフトウェアのテストは、フルタイムの専門職の仕事です。優れたテスターになるには、優れた頭脳、才能、そして多くの経験が必要です。テストが日々の仕事のほんの一部にすぎない場合、ソフトウェア開発者がどんなに賢いとしても、プロのテスターに近づくことができると仮定するのはばかげています。
その上に、無意識のうちにソフトウェア開発者がバグを見つけるためにwantをしないという問題があります。
テスト容易性を念頭に置いて設計する必要がありますが、専用のテスターがいない場合、ソフトウェアの設計、実装、およびテストの両方を行うのに十分な時間がないため、いくつかのことが単純に亀裂から抜け出します。
開発者/設計者はコードをテストする必要があるという彼らの意見に同意します。コードのセクションを作成した設計者/開発者は、ライブにコミットする前にそのコードに対する唯一の「目」のセットではないことに注意してください。これですべてをつかむわけではありませんが、開発中に独自のコードをテストおよび再テストするときに忍び寄る盲目を回避するのに少なくとも役立ちます。
ユースケースの説明から、コードカバレッジツールも使用していると思いますか？そうでない場合は、どのコードがテストされていないかを確認するのに役立ち、特定の状況で予期しないバグが発生する可能性があります。
とは言っても、十分な仕事があるか、組織の規模が適切であれば、専門のQA担当者が必要であり、全員の役割にもう少し焦点を合わせるのに役立ち、また、何かに関するパターンがあるかどうかを確認することもできます。見逃されており、さらに重要なのは、それを修正する方法です。