テスターは開発者の設計とコードをピアレビューできますか？
私はスクラム/アジャイル開発を使用する中小企業のジュニア開発者です。私たちの長期的な目標は、CMMIレベル2で評価されることです。ユーザーストーリーを実装する3人の上級開発者と、サポートのための少数のジュニア開発者のチームがあります。
特に開発とテストの義務を分離することに関して、私たちは「3つのアミーゴ」方法論に向かっています（3番目のアミーゴは製品の所有者/ビジネスの利害関係者です）。このようにして、シニア開発者は実装に集中でき、ジュニア開発者は公平なテスターとして集中できます。
ソースコードなどの作業成果物を検証するための具体的な方法として、ピアレビューを使用しています。この論文 http://repository.cmu.edu/cgi/viewcontent.cgi?article=1208&context=sei は、p。 19設計とコードの最適なピアレビュープロセスは、設計とコーディングに費やされる時間の50〜65％の範囲であることがわかります。
私の質問はこれです：テスターが開発者の設計とコードをピアレビューするのは適切ですか？利点は、開発者がユーザーストーリーの実装により多くの時間を費やすことができることです。不利な点は、ピアレビューによってコードの共有所有権が作成されるため、テスターがシステムの客観的/公平なビューを犠牲にする可能性があることです。
あなたはあなたの質問でいくつかの問題を提起します、そして特にCMMi検査官があなたにそれらについてあなたに尋ねるためにあなたのキュービクルまたはオフィスに来るかもしれないならば、それぞれはいくつかの考えに値します。そこに行って、それをやった、あなたが準備ができていればそれは良いことかもしれません、しかし...まあ、あなたは準備したいです。説明からの問題は次のとおりです。
- 資格：ジュニア開発者は、テスターとしてサポートに割り当てられ、レビュー担当者になる資格がありますか？
- 認定可能性：アジャイル+ CMMi +コードレビュー-アジャイルを維持し、CMMiガイドラインを満たす方法は？
- 客観性：コードレビューアは、コードを見た場合、引き続き客観的なテスターになることができますか？
資格
ユーザーストーリーを知っていますか？ユースケース図と、代替フローを使用する個々のユースケースにフローされていますか？そうでない場合、上級開発者は、検査を開始するための適切な参考資料を提供するのに十分なドキュメントを完成していない可能性があります。
レビューされた作業成果物がコードである場合、言語とコーディング標準を知っていますか？
これらを知っている場合は、フィードバックを提供するための優れたツールがいくつかあります。
テスターとして、
ユーザーストーリーやユースケースのレビューに関与していない場合、ブラックボックスやその他の機能テストのテスト計画をどのように作成しますか？
同様に、ステートメントや意思決定の対象範囲のガラスボックステストに関与している場合、コードを読まない場合、テストケースをどのように記述しますか？
- ある程度のTDD（テスト駆動開発）と単体テストが含まれていない場合、私にとってのアジャイルはそれほど機敏ではありません。ユニットテストを実行したり、テストを作成したりする役割はありますか？潜在的に、これにはコードを読み取るだけでなく、コードを変更することも含まれます。
最終的に、コードレビューを行っているあなたにとっての私の結論は、経験豊富な開発者がチームの賢いが経験の浅いメンバーと判断とドメイン知識を共有するための素晴らしい方法であり、経験が浅いが最近訓練された可能性のある開発者が何を共有するための素晴らしい方法であるということです彼らは学校で、または他の会社での最近の経験から学びました。両方の開発者がお互いを尊重することを条件に、双方にメリットがあります。
Certifiablity
CMMiとスクラム/アジャイルは、特にコードレビューに高い割合（55〜60％）の時間を費やすことを推奨する部分では、互いに対立する場合があります。これは非常にプロセスが重いアプローチのように聞こえます（つまり、あまりアジャイルではありません）。多くのチームは、自動化とツール、およびそれをより速く行う方法を探します。
私が使用しているスクラムベースのチームは、作成者がコミットを識別し、ツールがコードを表示する、ツールを使用したコードレビューを促進しました。私たちのツールチェーンには、svnおよびAtlassianツールのJira、Fisheye、およびCrucibleが含まれていました。 Crucibleは、レビューに費やされた時間を追跡し、メモであるか、欠陥の分類を含む可能性のあるコード内の許可された注釈を追跡しました。作成者はメモに応答し、検査にも表示される変更を加えることができます。検査を終了するには、モデレーターはレビューの問題が解決されたことを確認する必要がありました。検査官と直接会うこともありましたが、必ずしもそうとは限りませんでした。このツールは、検査の仕組みを合理化するという素晴らしい仕事をしました。
ペアプログラミングは、ピアレビューと同じ分野のいくつかをカバーしています。 2組の目は、問題が発生したときにそれをキャッチするために多くのことを行うことができ、速度を上げたり、開発者間で知識を伝達したりできます。ある開発者が他の開発者に間違ったアイデアを話しかけるというグループの考えがあるかもしれませんが、ほとんどの場合、相互作用は、発見するものよりも優れた代替案を開発します。また、あなたが一人でいる場合は、後で不幸になるであろうインターフェースや他のデザインの選択を非常に簡単に行うことができます。
客観性
検証と妥当性確認のために製品について客観的であり続ける必要があるのはテスターだけではありません。一般に、スクラムを使用するアジャイルの人々は、「包括的なドキュメントよりもソフトウェアを操作する」ため、口頭で多くの情報を伝える可能性があります。顧客からテスト基準を取得しますか？ストーリーカードから？
結論としては、おそらく開発者からテスト基準の少なくとも一部を取得し、気分が良くなった場合は、コード以外のアセット（並行して進行しているドラフトユーザーマニュアルを含む）からできる限りのことを収集すると思います。開発で）、コードからものを取得します。
CMMi承認可能なピアレビュープロセスの例
Fagan Inspectionsのような古い方法論は、確かに前述の長い時間のコミットメントを使用していました。少なくとも検査期間中、Faganチームは、モデレーター、作成者、リーダー、テスターの4つの役割に編成されました。
- モデレーターは検査を監督して、検査が
方法論とコーディングまたは文書化の標準、作成者によるフォローアップのための欠陥の記録、および将来の欠陥検出に対する定量分析のためのメトリックをQAチームに提供します。 - 作成者は、検査されたコードまたはドキュメントを作成しました。検査中、彼/彼女の仕事は非常に注意深く耳を傾けることでした。検査後、著者は欠陥を修正し、モデレーターにフォローアップしました。
- 読者は、検査中にドキュメントまたはコードをチームに言い換えました。
- テスターは通常、作業成果物をハンドオフとして受け取る人でした。多くの場合、システムエンジニアが作成者である場合、開発者はテスターになります。開発者にとって、検査テスターの役割はソフトウェアテスターです。テスト計画を立てたテスターの場合、
時には彼らの検査官-テスターはシステムエンジニアになるでしょう。
このアプローチの利点は、ソフトウェア開発ライフサイクル全体で作業成果物が引き渡されるときに、主要な参加者間の重要なコミュニケーションを確立することです。テスター（および他の検査官）がグループ思考に引き込まれるのを防ぐのは良い仕事だったと思います。
- 各検査官は個別に準備しました。
- 著者ではなく読者が作業成果物を発表しました。
- 著者が頭の中に作業成果物にない何かを持っていた場合、彼は3人の検査官の前で問題に立ち向かう絶好の機会がありました。
- モデレーターには、思考を促し、エゴの戦いから保護する権限があり、コーディング標準と通常はシステムドキュメント、および経験があれば、チームの良心になる可能性があります。
コードレビュー/検査に十分な時間がありませんか？
コードレビュープロセスの定義に関与している範囲で、この記事をご覧ください。私は彼が販売する製品を支持しませんが、問題の彼の説明といくつかの代替案が好きです。
http://www.methodsandtools.com/archive/archive.php?id=66
彼の結論は、Fagan検査がゴールドスタンダードであるということのようですが、非常に時間がかかるため、彼の会社はコードの約1％しか検査しませんでした。
私は「クイックヒットコードレビュー」と呼ぶアドホックな手法を持っています。この手法では、1人の担当者が必要です。これは、ソフトウェアの技術リーダーが、朝一番にソース管理にコミットされたすべてのコード変更を読み取るだけだからです。これは、チームが別の大陸にいる場合、またはリードが早いまたは遅いライザーであり、チームの他のメンバーがそうでない場合にうまく機能します。レビュー率は1時間あたり400〜500行のコード（Faganの場合は1時間あたり100行）であるため、完全ではなく、あまり記録されません。
障害が見つかった場合のアクションは、作成者が行う必要のある修正について、またはレビューとプライベートの間でリードが行った修正について、著者にメールを送信することです。ビルドとスモークテスト。これがCMMi認定の方法論ではないと思います。それはリードの能力とコードの知識に大きく依存し、微妙な問題を見つけるのにほとんど役立ちません（彼らがあなた自身の過去の過ちのようでない限り）。メンテナンスが難しいコードで新しいチームができたときに使用しました。費やした時間は、テストの削減と作業と再作業の間の待ち時間の短縮によって報われたと思います。
テスターを開発者から分離することのポイントは、コードが適切に機能することを複数の人が検証したことを保証したいということです。テスターがコードを見た可能性があるという事実は、これを排除するものではありません。開発者としてコンポーネントをコーディングおよびデバッグすることと、テスターとして多くのテストケースを介してコンポーネントを実行することには大きな違いがあります。
ですから、先に進んで、コードとデザインを実際にレビューするのと同じくらい多くの目を持ってください。レビューは、ミスステップを防ぐために非常に貴重です。
ところで、スクラムの観点からは、「チームメンバー」以外のチーム内で効果的に役割を作成しているという点で、アプローチでいくつかのルールを破っています。これは世界の終わりではありませんが、常にコードの所有権を共有する必要があることに注意してください。チーム全体がコードを所有します。また、私はここでシニア/ジュニアの差別化要因を思いとどまらせます-あなたはあなたのジュニア開発者が数ヶ月以上立ち往生することを望みますよね？