testing - 手動テストによるBDD?

Question

私たちは、古典的な「ウォーターフォール」モデルから、よりアジャイル指向の哲学に切り替えています。BDD を試してみることにしました (Cucumber) が、「古い」方法論のいくつかを移行する際にいくつかの問題があります。最大の疑問符は、手動テストがサイクルにどのように統合されるかです。

プロジェクト マネージャーが機能といくつかの基本的なシナリオ アウトラインを定義したとします。テスト チームと共に、この機能のために約 40 のシナリオを定義しました。自動テストができないものもあります。つまり、手動でテストする必要があります。機能ファイルしかない場合は、手動テストを実行してください。たとえば、過去のテストの失敗率を確認できるようにしたいと考えています。ほとんどのテスト ケース マネージャーはこのような機能をサポートしていますが、機能ファイルを操作することはできません。外部のテスト ケース マネージャーで手動テストケースを維持すると、機能ファイルとテスト ケース マネージャーの間で終わりのない更新の問題が発生します。

誰かがこの「中盤」をカバーできるかどうか、またその方法を知りたいです。

Answer 1

@Eswar の回答に追加するには、Cucumber (またはその兄弟の 1 つ) を使用している場合、1 つのオプションは、テスト ランナーを手動で実行し、テスターが特定の側面を確認するためのプロンプトを含めることです。その後、彼らは自分の判断に従ってテストを合格/不合格にします。

これは、クロスブラウザー レンダリング、要素の配置、正しい画像の使用などの美的側面に役立つことがよくあります。

@Eswar が述べたように、これらのテストにタグを付けることで、自動実行からこれらのテストを除外できます。

例については、この記事を参照してください。

Answer 2

これは非常に珍しいケースではありません。アジャイルであっても、すべてのシナリオを自動化することはできない場合があります。私が一緒に働いているスクラム チームは、通常、機能ファイルで @manual scenario としてタグ付けします。夜間ジョブの実行中にこれらのタグを無視するように自動化スイート (Cucumber - Ruby) を構成しました。これに関する 1 つの問題は、あなたが言及したように、テスターがローカルで結果を文書化するため、手動テストの結果が何であったかがわからないことです。

これに対する私の提案は、各反復の結果を目的に合った YML またはその他のファイル形式で文書化することでした。このファイルは、自動化スイートの一部である必要があり、リポジトリでチェックする必要があります。まず、自動化スイートとともに結果が文書化されます。後でリソースと時間ができたら、自動化スイートに機能を追加して、このファイルを読み取り、他の自動化結果と一緒に、または個別にレポートを生成できます。それまでは、バージョン管理が以前のすべての結果を追跡するのに役立つはずです。

お役に立てれば。

Answer 3

スクリーン ショットを撮るのは良い考えのようですが、検証を自動化することはできますが、さらに多くの作業が必要になります。たとえば、Selenium を使用している場合は、Sikuli を追加して (NB: ヘッドレス テストを実行できません)、結果 (画像) を比較したり、ロボット (java.awt) でスクリーンショットを撮ったり、OCR を使用してテキストを読み取ったり、アサートまたは検証 (TestNG) したりできます。