6か月前、ソフトウェアテストに没頭し、興味があり、これが本当に私のものであることに気付きました。 私は何時間もテスターのフォーラムに固執し、文献を読み、ソフトウェア開発プロセスを研究しました。 フォーラム、グループ、および会話で、テスターと開発者の相互作用に関するジョークにしばしば気づきましたが、これらのジョークを理解できず、注意を払っていませんでした。 少なくとも、あるソフトウェア開発会社でインターンシップを取得するまでは。
数ヶ月後、私はこれらのジョークの意味と「テスター対開発者」の活発な議論に追いつき始めました。 私がこの会社の最初のテスターだったので、快適になるのは困難でした。 説明が空のタスクに終わりはありませんでしたが、「テストと登録解除」、「サイトの確認」、「アプリケーションが機能しない」という名前で、開発者とプロジェクトマネージャーはQAの概念をまったく知りませんでした。 誰もがこのフレーズ「TKなし-HZの結果」を知っているので、そこで同じでした。 このすべてに加えて、誰も控えめに言っても製品が「曲がった」ことを気にしませんでした。 ほとんどの場合、これは次のようなものでした。「テスト」タスクを取得します-テストし、検出された欠陥についてレポートを作成し、開発者に渡しますが、開発者はこのタスクを数か月保持できます。 その結果、シェフはその州のテスターは不要であり、この悪夢は私にとっては終わったと考えましたが、製品は「曲がった」ままでした。
さまざまな論争、意見の相違がありますが、そのような場合を避けるための簡単なアプローチを考え出す時が来たようです。
ソフトウェアテスターの会話のスクリーンショット：
欠陥を見つける-文書化する-修正のために開発者に提出する。 しかし、開発者のミスに対する反応ではないにしても、すべてが単純に思えます。 彼はおそらく、テスターの仕事がオブジェクトの機能のエラーと失敗を探すことであることを忘れていたのでしょう。 その結果、私たちは友好的なコミュニティとして、貧しい女性にさまざまなアドバイスをし始めました。 多くは、チームリーダーを通じて問題を解決することを提案し、一部はそのような態度で顔をいっぱいにすることさえ提案しました。 さて、私は自分の選択肢を提案しましたが、多くの人にとっては奇妙に思えました。
しばらくして、プロジェクトマネージャーがテスターと開発者の架け橋となる興味深いプロジェクトに参加しました。 この概念がどれほど効果的かはわかりませんが、私たちはこれまで口論をしたことがありませんでした。 バグ追跡システムとして、Trelloを使用しました。 このシステムは、すべてボードに基づいて構築され、その中にあるすべてのものが1つの画面上にあるという点で便利です：タスク、変更の履歴、およびコメント。 しかし、これはプログラムの主なマイナス点でもあります。 単純すぎて、大規模なチーム向けには設計されていません。
プロジェクトマネージャーからタスクが飛び、テスト中に各バグが個別のカードで発行され、「バグ」ブロックにラベル「Shortage」と詳細な説明が添付されました。 次に、プロジェクトマネージャーはカードに優先順位を設定し、開発者の1人にそれを投げました。 納期が過ぎている場合があり、顧客と会う前に最も重要な点を確認する必要があります。 この場合、プロジェクトマネージャーはビジネスロジックに関連するバグを優先し、UIに関連するバグは後まで延期されました。 多くの人は、「だれが製品の失われたバグの責任を負いますか？」という疑問を抱くでしょう。
このプロセスで最も重要なことは、テスターが開発チームと対話しないことです。したがって、叫び声、口論、紛争はありません。
-はい、これはバグです！
-いいえ、これは機能です！
チームに適切なプロジェクトマネージャーまたは製品所有者がいる場合は、このアプローチをテストしてみてください。 多くの人が好きになると思います。
もちろん、開発者とテスターの比率が理想的な企業もあります。 たとえば、本番環境でのバグの紛失やユーザーの苦情に対して開発者が責任を負う場合。 この場合、開発者はテスターとの良好な関係に関心があります。 しかし、再び、「この原則に取り組んでいる企業はいくつですか？」という疑問が生じます。
ご清聴ありがとうございました。