最初に行われる受け入れテスト…これはどのように達成できますか？

ほとんどのアジャイルメソッドの基本的な要点は、機能が開発され、テストされ、多くの場合リリースされるまで、「完了」しないことです。これは、スクラムプロセスの「スプリント」など、時間の短いターンアラウンドで発生するはずです。

アジャイルの共通部分はTDDでもあり、テストが最初に行われると述べています。

私のチームは、多くの特定の描画などを行うGUIプログラムに取り組んでいます。テストを提供するために、テストチームは、少なくともテストしようとしていることを実行しようとする何かを処理できる必要があります。この問題を回避する方法は見つかりませんでした。

基本的に不可解なインターフェースをターゲットにしたソフトウェアを書こうとした場合、非常に苦労することになるので、それらがどこから来ているのか非常によくわかります。動作はかなり明確に規定されていますが、自動化に関してさまざまなUI要素を操作する正確なプロセスは、機能に固有すぎて、テスターが自動化スクリプトを記述して、存在しないものを駆動することはできません。たとえできたとしても、多くのことが後で仕様から欠落していると判明します。

私たちが行うことを検討したことの1つは、人間が「自動化」できるように、ユースケースの観点から説明した、実行する必要のある一連のステップのようなテスト「スクリプト」をテスターに​​記述させることでした。これは、開発者が機能を作成したり、他の誰かが検証したりすることで実行できます。テスターは後で機会を得たときに、主に回帰の目的で「スクリプト」を自動化します。しかし、これはチームに追いつくことにはなりませんでした。

チームのテスト部分は、実際にはかなりの差で遅れています。これが、人間が実行する「スクリプト」を開発するための明らかに余分な時間が発生しなかった理由の1つです。開発者に追いつくために危機に瀕しています。それらを待っていた場合、何も実行されません。それは本当に彼らのせいではありません、彼らはボトルネックですが、彼らは本来あるべきことをしていて、できるだけ速く働いています。プロセス自体はそれらに対して設定されているようです。

非常に多くの場合、テスターが最終的に確認したバグを修正するために行った作業を1か月以上前に戻す必要があります。私が何かをしたいのは醜い真実です。

では、この失敗のカスケードを解決するために他のチームは何をするのでしょうか？テスターを私たちの前に置いて、どのようにしてスプリントで実行する機能のテストを書いて、その間に親指をいじる必要がないようにすることができますか？現在のところ、アジャイル定義を使用して機能を「完了」させるには、開発者を1週間作業させ、次にテスターを2週間作業させ、開発者が思いついたすべてのバグを修正できるようにする必要があります。過去数日間。それが妥当な解決策であると私が同意したとしても、それは起こりません。より良いアイデアが必要です...

最初に、「テスター」と「開発者」の間の分離を取り除きます。みんなテスト

第二に、TDDでは、開発者は機能/ストーリーをコーディングする前にテストをコーディングします

あなたが説明したのはTDDではありません[スクラムかもしれませんが、スクラムは、開発方法論に依存しないプロジェクト管理方法論です。スクラムは問題に関係ありません]

自動テストが不可能なシナリオは非常にまれです。自動テストが困難、高額、または不便なシナリオは、はるかに一般的ですが、自動テストが最も必要とされるのは、まさにこれらのシナリオです。

漠然とした説明から、ソフトウェアは画面上に何かを描画していると思います。描画されているものがデータ、数式、または機能ステップによって決定される場合、少なくともデータ/数式/機能ステップのレベルでテストする自動テストを記述します。画面出力が確定的である場合（同じ手順で毎回同じ図面出力が生成されます）、手動で1回テストしてスクリーンショットを撮り、今後のテストで出力と検証済みのスクリーンショットを比較します。画面出力が非決定的であり、データ、数式、または関数の手順に支配されていない場合、自動テストが不可能である可能性のあるまれな領域にいます。しかし、私はそれを疑います。

テストがこれまで自動化されていない唯一の理由は、開発者がそれを気にしていないことだと思います。TDDでは、開発者がテストを行うため、すべてのバグがなくなるまで、同じ62ステップのプロセスを100回テストするという退屈な繰り返しの痛みを感じます。開発者にテストを行わせるよりも早く自動テストソリューションを開発することはできません。

私のチームは、TDDはGUIテストの設計には不十分であることを発見しました。私たちが使用したすべての自動化されたGUIレベルのテストフレームワークでは、テスト前にコードを記述する必要がありました。そこで、行動駆動型開発に切り替えました。もちろん、テストは自動化されていませんが、UIが最初から「完了」しているかどうかを測定する方法を提供しました。

GUIのATDDは困難/高額です。

通常、最初にフロントエンドを実行します。Webアプリケーションを作成するため、通常はHTML / CSS / JSで記述され、外観、フローなどが承認されます。これらは最終的に、適切な部分が動的ビットに置き換えられたテンプレートに変換されます。

UIモックアップが完成したら、Webリクエストを模倣するテストを記述します。XPathは、データが正しいHTMLタグに存在することをアサートするために使用されます。

このスタイルのテストは、私たちが費やす時間に良い価値を与えてくれます。データが返され、HTMLに関する一般的な構造がまだあることを確認します。モックアップステージで事前にルックをすでに作成しているため、ピクセル配置をアサートしようとする必要はありません。開発の一環として、およびダブルチェックの両方で開発しているため、ページを見るだけです。

GUIの非Web開発者の場合は、おそらくフロントエンドをスクリプト可能にするためにいくつかのフックを追加してみます。紙の上であっても、おそらくUIも最初にモックアップします。

 > Acceptance tests done first…how can this be accomplished?

この記事「SpecFlowとWatiNを使用したビヘイビアー駆動開発」で説明されているように、bdd-tddスタイルの開発を好みます。

例では、SpecFlow + NUnit + WaitNでの開発に.netを使用しています。（j）ruby / javaで開発している場合は、きゅうり+ junit +ウェイターを試すことができます

私たちが行うことを検討したことの1つは、人間が「自動化」できるように、ユースケースの観点から説明した、実行する必要のある一連のステップのようなテスト「スクリプト」をテスターに​​記述させることでした。これは、開発者が機能を作成したり、他の誰かが検証したりすることで実行できます。テスターは後で機会を得たときに、主に回帰の目的で「スクリプト」を自動化します。しかし、これはチームに追いつくことにはなりませんでした。

これは多かれ少なかれ私たちがやっていることです。すべての機能はテストケース（スクリプト）と並行して開発され、開発、テストケース、テストの3つのステップがすべて完了するまで、機能は実行されません。すべてのテストケースは、テスターに​​よる要件から作成され、開発者に確認されます。そのため、私たちは全員、問題について共通の理解を持っています。開発者が機能に取り組んでいるとき、およびテスターがテストケースに取り組んでいるとき、およびテスターがテストしているとき、開発者が次の機能を調査していることを除いて、「隔週」の提案と同様です。

あなたが持っている最大の問題は

チームの一部をテストしている彼は、実際にはかなり差をつけられています。[...]それらを待っていた場合、何も行われません。

テストチームはこれまでのところ遅れているので、実際に待つ必要があると思います。簡単にテストできるが、開発に長い時間がかかるいくつかの機能を開発するなど、あなたができる生産的なものがあると私は確信しています。また、スプリントを計画するときにテスト時間を考慮することも役立ちます。開発者もテスターも過労やアイドル状態であってはなりません。

受け入れテスト駆動型開発（テスト駆動型開発とは異なりますが、それを補完するもの）は、コーディングを開始する前に要件を確実に満たすための優れた方法です。

私のチームでは、私たち（製品所有者、QAアナリスト、開発者）が一緒になって、FitNesseの 2つの書き込み受け入れテストを使用しています。これらのセッションは通常QAによって推進されますが、全員が参加します。フィクスチャ（Wikiページと本番コード間の接着剤）を追加するための開発努力が必要なため、これらはすぐには実行されません。これらのテストは、ストーリーの受け入れ基準を形成します。FitNesseは、UIの下のレイヤーと相互作用するように設計されています。

次に、開発者として、これらの受け入れテストに合格するように取り組みます。これにはTDDを使用しますが、TDDをATDDと混同しないでください。

FitNesseのページが緑色に変わっても、ほとんど作業は完了です。まだやるべきことがいくつかあります（通常、QAが主導する探索的テストなど）。

たぶん、コード化されたUIテストを作成することが役立つでしょう。Visual Studio 2010を使用している場合は、「コード化されたuiテスト」と呼ばれるアドインを使用して、アプリのUIを操作するための非常に特定のスクリプトを記録およびコーディングできます。インタラクションをスクリプトに記録すると、UIに小さな変更を加えないように保護する抽象化のレベルが高くなります。ただし、この形式のテストを導入すると、テストを維持する負担も生じます。