同じスプリントでのコーディングとテスト

すべてまたはほとんどのコーディングがスプリントの終了まで行われない場合、テストはコーディングと同じスプリント内でどのように処理されますか？（スプリント内の単一のPBIの「スープからナッツ」への開発とテストに言及しています。）

私がオンラインで見た回答のほとんどはQAの自動化に関係していますが、自動化されたテストを記録または作成するための機能的なUIが一般的に必要なので、それも実際には不可能です。機能を開発し、新しい要件を発見するにつれて進化し続けるストーリーボードしかありません。

私の場合、新しいデスクトップアプリケーションを開発しています。通常、デスクトップアプリは自動テストにあまり適していません。自動化された単体テストがいくつかありますが、QAの専門家が行う手動の機能/統合テストではありません。

ですから、私が今いるのは、私のスプリントが明日で終了するということです、私はまだコーディングを終える必要があります、そして私のQAの人々はまだテストするものが何もありません、そして私が手を持たずに私が彼らに与えるものをテストする方法がわかりません。

私はこのジレンマを持っている最初の人ではないと確信しています。

過去に、パイプラインを実行しました。現在のスプリントでは、テストチームが前のスプリントで実装された機能をテストします。私の現在の仕事では、PMはこのアプローチを「ウォーターフォール」と呼んでいます。

ユーザーストーリー（米国）をテストせず、受け入れ基準が満たされていることを確認しない場合、このストーリーは実行されません。それが行われていない場合、この米国はもちろん次のスプリントに進みます。すべての米国がこの状態にある場合、スプリントはプロジェクトに付加価値なしで終了します。クライアントの観点からは、これを休暇中の開発チーム全体と区別することはできません。

無駄のない原則（アジャイルはスクラムで終わらない）の1つは、「品質が組み込まれている」と述べています。定義した品質基準を満たす場合にのみ、何かが実行されます。これは、真のアジャイルプロセスを実現するために非常に重要です。ゼロバリューで春を終わらせるか、開発とは別のテストを行うことは、大きな問題の症状です。

できることはたくさんあります。

• 自動化は成功の鍵です。少なくとも単体テストレベル、およびCIなどの他のプラクティスも重要です。これでは十分ではありませんが、これらのタイプのテストをうまく行えば、手動テストでバグがほとんどまたはまったく発見されません（通常はUIの小さな問題）。献身的なQAスタッフがいる場合は、受け入れテストを自動化する人になる可能性があり、この自動化の一部はスプリントを完了する前に開始できます。

• ユーザーストーリーのサイズを確認します。スプリントの最初の2日、3日目に終了した米国がある場合、QA担当者がテストできます。私の意見では、小さな（SMART）ユーザー履歴があることは、アジャイル開発で成功するための最も重要なことの1つであり、多くの人はこれを認識していないようです。

• テスターと開発者の間のコラボレーションは、成功のもう1つの重要な部分です。私の以前のプロジェクトでは、米国が開発者によって完成したとき、QAの人が開発者と「ペアテスト」を行います（手動でも、自動化されたものを起動することもできます）。

本質的な問題は、コーディングはするがテストはしないプログラマーと、テストはするがコーディングしないテスターがいることです。

その問題を解決すれば、この問題は発生せず、間違いなくより効率的なチームになります。

過去に私のために働いていた1つの方法は、完全にテストされたストーリーを提供するという明確なタスクとストーリーの組み合わせをコーダーやテスターに​​提案することでした。それとともに、すべての形式の「開発完了」思考を消去しました。スクラム/カンバン/トレロボードに「開発完了」列はなく、コーダーによる「開発完了」態度もありません。

何が起こった：

• ペアはストーリーを配信する責任があり、ストーリーが完了していない場合は両方とも失敗します。彼らはソフトウェアの配信を担当する責任ある専門家として扱われ、ほとんどの場合そうしました。

• テスターが単体テストと統合テストにさらされたため、テスト作業がはるかに少なくなり、同じテストを手動で繰り返しませんでした。

• 開発者がテスターが必要とするものをよりよく理解したときに、一部のテストが自動化されました。

• 一部の人々は動揺しました。

• コードコミットプルテストサイクルがほぼ瞬時になったため、ストーリーは平均してより速く配信されました

もちろん、これは私の逸話的な経験にすぎませんが、可能であれば自分で試してみてください。

あなたの場合、テスターと開発者はあなたの会社で正式に分離されているというあなたのコメントを考えると、メッセージは私には明らかなようです。会社の規則によって定められたコミュニケーションとコラボレーションには明らかな障壁があります。

これは通信の問題であり、アジャイルの問題ではありません。アジャイル方法論を採用することは、単にそれを明らかにすることです。サイロ化されたチームは、既知の管理アンチパターンであるため、この場合はアジャイルの非適応性を受け入れます！

QAの実際の役割は、受け入れテストに近いものです。これは、開発チームの一部ではなく、製品の所有者として機能する別のチームによって行われると思います。

例：スプリント中に、さまざまな基準で検索結果をフィルタリングできる機能を追加する必要があります。検索メカニズムはすでに実装されていますが、結果はアルファベット順に並べられています。

• スプリント中：

  1. チームは、新機能の設計と実際のコードベースへの影響を作成します。

  2. 開発者は、順序付けが期待どおりに機能することを確認する単体テストを作成し、同時に実際のコードを作成します。

  3. 新しい機能は、何も壊さないこと（回帰テスト）および期待どおりに動作すること（ユニットテスト）を確認するために、慎重にテストされています。

  4. 可能かつ適切であれば、ほとんどのプロジェクトではそうではありませんこれは、製品の所有者（とあなたのQAチームがそう）常に間違った方向に行くチームを防ぐために、新しい機能を評価することができます。これには、毎日何十ものビルドとの継続的な統合が必要です。

• スプリントの後、製品の所有者は新しい機能を評価して、顧客のニーズに対応していることを確認します。スプリント終了後、QAチームは実際にここにいます。

実際の問題は次のとおりだと思います。

• 範囲。スプリントはあなたのチームに関係するものであり、あなたのチームのみに関係します。製品所有者としての役割を果たす実際のQAには関係しません。

• テスト。QAチームがいるということは、コードを書くだけでいいということではありません。あなたのチームの仕事は、期待通りに機能する機能を提供することであり、他の人がテストするためのコードを捨てることではありません。QAチームに頼ってテストを行うと、バグはほぼ瞬時に修正されるのではなく、1〜2週間後に修正されるため、全体のコストが増加します。

すべてまたはほとんどのコーディングがスプリントの終わりまで行われない場合

早く終了しないのはなぜですか？この重要な制限が問題の原因であり、2つのアプローチが成功するのを見てきました。1つはアジャイルアプローチによく適合し（他の一般的なプラクティスではない）、もう1つはアジャイルを少し汚染します（しかし、より一般的です）。

1つ目は、スプリントの終わりまでコーディングしないことです。実際にコードを書くことは、開発の比較的小さな部分です。スプリントの約半分を終えると、QAが仕事をするのに十分な時間が与えられます。また、ドキュメントを書いたり、技術的な負債を整理したり、バックログ項目の設計をしたりするための十分な時間を残します。高品質の製品のために必要な他のすべてのこと。私がこれまで見た欠点の1つは、機能を取得するのがほとんど不可能であり、ユニットテストを迅速に実行できることです。個人的には、QAに機能性の調査を開始させた後にユニットテストを行うことは完全に問題ないと思いますが、TDD支持者（およびその他）は同意しません。

2番目のオプションは、PMが嫌うような開発スタッフの背後でQAにスプリントを運用させることです。私もこれを嫌う傾向があります。リリースのエスカレーションプロセスがある場合でも、スプリントの最後に「リリース可能な製品」という概念がなくなります。さらに悪いことに、QAがテストからの質問やバグで彼らにやってくると、開発者は「新しい」ことに集中するでしょう。開発者は、この配置のバグを修正する可能性も低くなります。しかし、私はそれが時間通りに高品質のソフトウェアを生産するのを見てきました。

スクラムガイドでは、チームが機能横断的であることが要求されています。すべてのチームメンバーは、個々の専門分野に関係なく、開発者と見なされます。サイロ化された個人（コーダー、テスター、qa、uxなど）はスクラムでは役に立ちません。チームメンバは、できる限りどこでも助け合います。「アイテムをqaに渡す」という概念はありません。

あなたの状況では、まるで見積もりの​​問題があるかのように聞こえます。製品のバックログアイテムを見積もるときは、コーディング、テスト、ピアレビュー、展開、統合など、すべてのアクティビティを検討する必要があります。

大まかな目安として、5〜15個の製品バックログアイテムをスプリントに入れることを想定してください。これにより、各製品のバックログアイテムの大きさを把握できます。また、スプリント内で作業を「完了」する絶好の機会を提供します。

最後に、チームのタスクは、1つの製品バックログアイテムを「完了」に移動してから、次のアイテムに移動することです。時々、これを行うことは、人々がお互いのつま先を踏んでいることを意味するため、一度に複数の製品バックログをスピンアップすることが理にかなっています。ただし、進行中の作業（WIP）を削減し、製品のバックログアイテムを完了に移動することをガイドラインとしてください。

テストとコーディングは密接に関連しています。モジュールごとにスケジュールできます。モジュールが完成したら、テスターに​​提供できます。このシナリオ全体は、作業中のテストのフェーズにも依存します。スパイラルSDLCモデルは見栄えが良いです。その点で、同時テストとコーディングは便利です。別のアプローチはVモデルである可能性があります。

私の答えは、おそらく最初は非常に奇妙ですが、コードの副作用に対してテストを行う必要があると考えるため、テストする時間を見つけられません。副作用とは、コンピューターサイエンス用語を意味します。

関数（...）は、値を返すことに加えて、（...）外界との（...）観察可能な相互作用がある場合、副作用があると言われています。

「外の世界との相互作用」の部分を強調するために引用を挙げました。画面に印刷されているUIでテストを実行したい場合（「テストを開始するには」は一般に機能する必要があるため、実際には不可能です）自動テストを記録または作成するためのUI」）。

他の回答では、この「受け入れテスト」を自動化するように指示されているため、迅速に実行できます。これは正しいですが、元の問題を完全には解決していません。受け入れテストを書くのに十分な時間がない場合はどうでしょうか？

コードが外の世界と相互作用したら、つまり、何かを出力し、何らかの入力を期待したら、テストの見方を手放さなければなりません。副作用の問題は、実際にはテストできないことです。これは、Guido van Rossumとのインタビューを読んでいるときに思いつきました。彼は、コンピューターをシャットダウンするステートメントは、実行することによってのみ機能することが証明されたと言いました。

その「テスト不能性」の解決策は、一度ステートメントが機能することを証明したら、どこでもそれを使用して、そのステートメントを使用して作業を実行できることを理解することです。関数でそれを分離し、他のすべてをテストします。

その例をあなたの質問に近づけると、この関数はおそらくライブラリーまたはフレームワーク全体になり、コンピューターをシャットダウンする代わりに、ユーザーインターフェイスという何かを出力します。アプリケーションのその部分に入ると、高価な受け入れテスト、つまりある種の外部観測を介してしかテストできないため、呼び出しをできるだけ愚かで安定した状態に保ちます。

あなたが提供していないライブラリのロジックをテストする必要はないので、UIを「外国の領土」と見なすことは実際には正しい視点です。おそらく驚くべきことに、それは現実的な視点です。呼び出しをテストするMyWidget.draw()ことを期待します。例えば、単一ピクセルのレベルで、あなたが期待することをしますか？

これは、受け入れテストが重要ではない、またはスキップできると言うことではありません。他の答えが示唆するように、それを維持し、自動化することはそこに大きな利点があります。ただし、同じスプリントでテストとコーディングを行う時間を見つけたい場合は、可能な限り副作用が発生しないようにしてください。