コードレビューと同様にテストのピアレビュー

誰かが機能テストのために「コードレビュー」プロセスを実践していますか？便利だと思いますか？私の現在の雇用主がSCRUMを実践している方法では、特定のスプリントの「必須」の一部として機能テストを含めています。

スクラムも練習しています。そしてあなたと同じように、機能テストも定義の一部として含まれています。

私の経験から、私はそれが信じられないほど便利だと感じています。機能テストを強制するだけで、コード内のバグの数を大幅に削減しました。

コードレビューの2つ目の良い点は、実際の機能について別のビューを提供し、顧客/クライアントが望んでいたものと100％一致することを確認することです。誰かがコードと機能を調べて、「行ってください、これは正しくありません...」と何度か言いましたが、コードを実装している人が何かを誤解していることがわかりました。

Good heavens yes（私はSO; pでexp辞を使わないようにしています）。機能テストをピアレビューすることは、基本的に要件と分析をピアレビューすることです。これは非常に重要です。キュウリのようなBDD言語を使用する場合は、プログラマー以外も参加できます。

エンドユーザーが機能テストで問題を見つけたとき、それはすごいことであり、開発プロセスの大部分を「私もコードを読むことができます!!」と感じさせます。

それは私にとって完全に理にかなっています。コードが内部でのみ使用され、顧客によって実行されることはない場合でも、作成するコードは他の人が確認する必要があります。

テストに非常に重きを置く方法論では、テストのレビューがより重要になり、おそらく必要になり、コード自体のレビューよりも重要になることがあります。テスト結果。

テストが正しいことを確認することは1つの側面であり、テストが十分に完了しており、正確/代表的であることも非常に重要です。

この点を見逃していることは、これらの方法論を外部のレビュー担当者に見栄えの悪いものにする原因の1つです。

ペア検査ができます！

ペア検査は次のとおりです。

オーサリングとドキュメントの制作サイクルの一環として、ドキュメントを積極的かつ非公式にレビューします。

これがテストでうまく機能する理由は次のとおりです。

1. 要件またはドキュメントを複数の目で頻繁に検査できます。
2. 開発者だけではなく、テストリードでBAを、PMでBAを、開発者でBAを試してみてください。
3. アジャイルプロセスの一部として再硬化ミーティングを設定できます。チームメンバーからの確固たるコミットメントで、それについて真剣に取り組むようにしてください。
4. これらのペアの検査は、関係者との信頼関係の構築とコミュニケーションの演習の一環として使用できます。会話を始めましょう！

私たちは機能テストを少なくとも何気なくピアレビューします。組織ではすべてのコードをレビューすることを強くお勧めします。

レビューの目標に基づいてレビュアーを選択することをお勧めします。コード化されたテストは、開発者（主にコード品質のため）と別のテスター（主にテストカバレッジのため）の両方で最適にレビューされる可能性があります。コードのないテスト（データ駆動テストなどのハーネスを使用）は、別のテスターのみがレビューするのが最適です。ピアレビューは、テスターがお互いから学ぶことを奨励する素晴らしい方法でもあります。