タグ付けされた質問 「acceptance-testing」

TDDと単体テストは、現時点では大きな絶賛のようです。しかし、他の形式の自動化されたテストと比べて本当に便利なのでしょうか？ 直感的には、自動化された統合テストは単体テストよりもはるかに便利だと思います。私の経験では、ほとんどのバグはモジュール間の相互作用にあるようで、各ユニットの実際の（通常は制限された）ロジックではありません。また、モジュール間のインターフェイスの変更（および変更された事前条件と事後条件）のために、しばしば回帰が起こりました。 私は何かを誤解していますか、またはなぜ統合テストに比べて単体テストがそれほど重視されているのですか？それは単に統合テストがあなたが持っているものであり、ユニットテストが開発者として適用するために学ぶ必要がある次のものであると仮定されているからです。 それとも、単体テストは、自動化の複雑さに比べて単純に最高の利益をもたらすでしょうか？ 自動化された単体テスト、自動化された統合テスト、および自動化された受け入れテストでどのような経験がありますか？なぜ？ 次のプロジェクトで自動化するために、テストの形式を1つだけ選択する必要がある場合、それはどのようになりますか？ 前もって感謝します。

29 testing  unit-testing  automation  acceptance-testing 

「スタブ」、「何かをスタブする」、「スタブ」などという言葉をよく耳にします。 プログラミングでスタブとは何を意味し、その言葉はどこから来たのですか？どのコンテキストで使用できますか？

26 unit-testing  testing  integration-tests  acceptance-testing  stub 

私たちの会社では通常、Webサイト/ Webアプリのエンドツーエンドのテストを必ず作成します。つまり、URLにアクセスし、フォームに入力し、フォームを別のURLに送信して、ページの結果を確認します。これは、フォームの検証、HTMLテンプレートに正しいコンテキスト変数があることなどをテストするために行います。 また、基になるロジックを間接的にテストするためにも使用します。 同僚から、この理由は、エンドツーエンドのテストに合格する限り、任意の時点で基になる実装をリッピングおよび変更できるためだと言われました。 この種のデカップリングが理にかなっているのか、それとも小さなコード単位のテストを書くのを避けるための方法なのだろうか？

23 unit-testing  tdd  acceptance-testing 

ユニット/機能テストなしの大規模なエンタープライズレベルのアプリケーションがあるとします。非常に厳しい締め切りのために、開発中にテスト駆動型の開発プロセスはありませんでした（わからない場合、締め切りを約束するべきではありませんが、何が行われたかはわかりません！） すべての期限が過ぎ、物事が落ち着いたので、誰もが生産的なTDD / BDDベースのチームに私たちを変えることに同意しました。 問題は、すでにあるコードについてです：（1）すべてが完全に正常に動作していても、ほとんどの開発を停止し、最初から可能なテストケース全体を書き始めることはまだ大丈夫ですか？ ？または、（2）何か悪いことが起こるのを待ってから、修正中に新しい単体テストを作成するか、（3）以前のコードを忘れて、新しいコードのみの単体テストを作成し、次の主要なリファクタリングにすべてを延期する方がよいでしょう。 このようないくつかの良い関連記事があります。私たちには非常に限られた時間しかなく、他の多くのプロジェクト/作品が私たちを待っているので、これに投資する価値があるかどうかはまだわかりません。 注：この質問は、開発チームの完全に厄介な状況を説明/想像しています。これは私や同僚のことではありません。それは単なる想像上の状況です。これは絶対に起こらないか、開発マネージャーがそのような混乱に責任があると思うかもしれません！しかし、とにかく、行われたことが行われます。可能であれば、これは絶対に起こらないと思われるからといって、投票しないでください。

17 unit-testing  testing  tdd  bdd  acceptance-testing 

ここで何が尋ねられているかを伝えるのは難しいです。この質問は曖昧、曖昧、不完全、過度に広範、または修辞的であり、現在の形式では合理的に答えることができません。この質問を明確にして、再開できるようにするには、ヘルプセンターに アクセスしてください。 8年前に閉鎖されました。 どのようなソフトウェアテストを知っていますか？テスト駆動開発、単体テストなどについて聞いたことがありますが、それらの重要性と違いを理解できません。たとえば、なぜ回帰テストや受け入れテストを使用するのでしょうか。彼らが提供する利点は何ですか？

16 unit-testing  testing  tdd  integration-tests  acceptance-testing 

アプリケーション開発の経験はたった2年です。この2年間で、開発に対する私のアプローチは次のようになりました。 要件を分析する Identity Coreコンポーネント/オブジェクト、必要な機能、動作、プロセス、およびそれらの制約 クラスの作成、クラス間の関係、オブジェクトの動作と状態の制約 機能を作成し、要件に従って動作上の制約を使用して処理する アプリケーションを手動でテストする 要件の変更によりコンポーネント/機能が変更された場合、アプリケーションを手動でテストします 最近、TDDを紹介し、開発されたコードが存在する強力な理由があり、展開後の問題の多くが軽減されるため、これは開発を行うのに非常に良い方法であると感じました。 しかし、私の問題は、最初にテストを作成できないことです。むしろ、実際にコンポーネントを作成する前に、コンポーネントを特定し、テストを作成しています。私の質問は 私はそれをやっていますか？そうでない場合は、正確に変更する必要があります 書いたテストで十分かどうかを確認する方法はありますか？ 1 + 1 = 2に相当する可能性のある非常に単純な機能のテストを記述するのは良い習慣ですか、それとも単なるやりすぎですか？ 機能を変更し、それに応じて要件が変更されたかどうかをテストするのは良いですか？

15 programming-practices  unit-testing  tdd  acceptance-testing 

SCRUMプロセスにテストプロセスを統合しています。私の新しい役割は、後で自動化するためにWebアプリケーションの受け入れテストを作成することです。テストケースの作成方法について多くのことを読みましたが、複雑なWebアプリケーション用のテストケースを作成するための実用的なアドバイスを提供してくれる人はいませんでした。 テストケースは短くする必要があります。CMSの例を取り上げます。短いテストケースは、保守が容易で、入力と出力を識別するのが簡単です。しかし、長い一連の操作（たとえば、ドキュメントの追加、他のユーザーへの通知の送信、他のユーザーの返信、ドキュメントの状態の変更、ユーザーへの通知など）をテストする場合はどうでしょうか。むしろ、テストケースは完全なシナリオを表す必要があるように思えます。しかし、これにより、明らかに複雑なテスト文書がどのように生成されるかがわかります。 テストでは、入力と出力を特定する必要があります。：動作が異なる、相互作用するフィールドが多数ある長いフォームがある場合はどうなりますか。すべてに対して1つのテストを作成しますか、それとも1つのテストを作成しますか？ テストケースは独立している必要があります。しかし、アップロード操作のテストに接続操作の成功が必要な場合、どのように適用できますか？そして、それはテストケースの作成にどのように適用されますか？各操作に対してテストを作成する必要がありますが、各テストはその依存関係を宣言しますか、それとも各テストのシナリオ全体を書き換える必要がありますか？ テストケースは、軽く文書化する必要があります。この原則は、アジャイルプロジェクトに固有のものです。それでは、この原則を実装する方法について何かアドバイスはありますか？ 受け入れテストケースの作成は簡単だと思っていましたが、私がしなければならないすべての決定に圧倒されました（参考：私は開発者であり、プロのテスターではありません）。私の主な質問は次のとおりです。複雑なアプリケーションの保守可能な受け入れテストケースを作成するために、どのような手順またはアドバイスがありますか。ありがとうございました。 編集：私の質問を明確にするために：受け入れテストは要件から開始し、アプリケーション全体をブラックボックスと見なす必要があることを認識しています。私の質問は、テストドキュメントを作成し、テストケースを特定し、テスト間の依存関係に対処するための実用的な手順に関するものです...複雑なWebアプリケーションの場合

14 testing  documentation  acceptance-testing 

（これは良いインタビューの質問になると思いますが、私の場合はそれよりも実用的です。） 数十の化学成分間の非常に長く洗練された化学反応プロセスをモデル化する大規模で複雑なアプリケーションがあります。私たちは、アプリケーションの受け入れテストを設計する段階にありますが、テストするのに手に負えないほどの数の可能性のあるパスにやや気が進まないのです。私たちの状況は、Googleマップの開発チームが「ルートの取得」機能でルート計画アルゴリズムをテストするときに直面したものと非常によく似ていることがわかりました。明らかに、すべての可能なルートをテスト（検証および検証）することはできませんでした。では、どのような状況でもアプリケーションが機能するという自信をどのようにして得たのでしょうか？ そして、私は彼らがそれをどのようにしたかを知ることを期待していないので、あなたに尋ねましょう：特定のアプリケーションが堅牢であることを満足させるために、適切なコードカバレッジを備えたテストスイートをどのように設計しますか？システムを通るすべての潜在的な経路を調査するために？ 私が探しているのは、手に負えない問題を小さく扱いやすい部分に分解するために使用する原則です。その合計は、全体の満足のいく推定を提供します。「すべてをテストすることはできませんが、これをテストすることはできます、これ、そしてこれで十分です。」「確かに正しい」アプローチを探しているのではなく、実際の予算/時間の制約を考慮して、慎重なアプローチを探しています。 （Googleマップの例を使用して、できるだけ具体的な回答を求めています。）

13 acceptance-testing  test-coverage 

自動受け入れテストでユーザーストーリーを100％網羅したBDDを使用してプロジェクトを実行する場合、テスター/品質保証担当者の役割は何ですか？ 開発者が受け入れテストを製品所有者と一緒に書くことを想像していると思いますが、それが馬鹿げた仮定のように思えたら教えてください。

13 testing  team  qa  bdd  acceptance-testing 

私は年金と投資の面倒を見る銀行の大規模な金融取引システムに取り組んできました。15年間の機能変更後、手動回帰テストのコストはリリースごとに20万ドルに上昇しました。（1,000,000 LOC、1日あたり1,000万ドルの取引）。また、このシステムは、多くのデータを移動する社内の19の他のシステムと連動します。このシステムはJavaで実装されました。 ただし、「再利用」を行うほど、回帰テストのコストが高くなります。（理由は、「タッチするコードをテストする」必要があるためです。また、再利用/共有コードは、タッチされたときに多数の場所に影響を与えます。したがって、「DRY-Do Not Repeat Yourself」 -コードをコピーして貼り付ける金銭的なインセンティブを確認します。これは、回帰テストに大きな影響を与えるため、共有できるコードを変更したくないため、回帰テストのコストを削減するためです。 私の質問は、再利用と回帰テストのコストの関係を説明するソフトウェアエンジニアリングの原則があるかどうかです。 私がこの質問をする理由は、システムをテスト対象のより小さな部品に分解することには、おそらくコスト上のメリットがあるからです。 仮定： 「回帰テスト」とは、「受け入れテスト」を意味します。つまり、環境やデータのセットアップなど、ビジネスに代わってシステムに対して新しいテストを作成したり、古いテストを再利用したりする別のグループです。 大きなリグレッションテストコストに対する大胆な反応は、「より自動化されたテスト」です。これは良い原則です。この環境では、いくつかの課題があります。 （a）自動テストは、システムが高い自動テストカバレッジを持たない限り、システムの境界を越えてあまり有用ではありません。（影響範囲の課題）。 （b）システムが既に大きく複雑な場合、プログラマーの時間や高い自動化されたテストカバレッジへの資本投資に勢いをつけることは文化的に困難です。 （c）自動化されたテストの維持コストはプロジェクトに隠されているため、プロジェクトレベルで簡単に破棄されます。 （d）これは銀行で働くことの文化的現実にすぎません。 （e）私はこの問題を別の方法で解決しようとしています（分解）。

12 code-reuse  acceptance-testing  estimation 

一般にソフトウェア開発とゲーム開発の違いについてこの論文を読んでいて、著者はソフトウェアテストに関していくつかの良い点を指摘しました。たとえば、 ...ゲーム開発者は、ゲームデザイナーの創造的な欲求の変化に直面して、これらのテストが急速に陳腐化するため、自動テストの使用をためらいます。 それで、この読書は、ゲームを扱っている/テストしているときに、ソフトウェアテストの他のどの側面を異なるまたは特定と見なすべきかを考えさせましたか？誰かがこれを経験したことがありますか、それについて何か他のことを聞いたことがありますか？

11 testing  game-development  acceptance-testing 

REST APIをテストしています。JSON構造を返すとしましょう。サーバーをテストするための最良のアプローチは何ですか？各テストステップは、前のすべてが成功した場合にのみ成功します。 構造A：すべてを一度にテストする - Test method 1: - make server request - assert http response code was 200 - assert returned file is not empty - assert returned file has valid JSON syntax - assert returned JSON contains key X これが最善の解決策のようです。 利点： 1つのサーバー要求のみ 「サーバーはキーXのJSONを返しますか？」という動作全体をテストしています。 構造B：各テストにアサートを徐々に追加します - Test method 1: - …

10 testing  acceptance-testing 

職場では、かなり複雑なシステムがあります。このシステムをSystem_Aと呼びます。QAチームは別のシステムを作成しました。このシステムをSystem_Bと呼び、System_Aをテストします。 System_Bの使用方法は次のとおりです。入力（System_B自体を使用）INを生成し、そのような入力をSystem_Bを介して処理し、出力O_Bを生成します。したがって、プロセスは次のとおりです。 System_B(IN) -> O_B。 次に、System_Aにも同じことを行い、独自の出力O_Aを生成します。 System_A(IN) -> O_A。 いつでも、O_Bは期待される出力であり、O_Aは観測された/実際の出力であると想定されます。暗黙のうちに、O_Bは「ゴールド」ソース（真実）です。しかし、問題の組み合わせに遭遇しました。 O_Aは間違っている、O_Bは正しい O_Aは正しい、O_Bは正しい O_Aが間違っている、O_Bが間違っている O_Aは正しい、O_Bは間違っている O_Bが常に正しいと想定されている場合（または何が期待されている場合）、何が正しいかをだれが決定しますか まあ、それはO_Bが人間の検査と分析で時々（またはしばしば）間違っていることがわかりました。物事はこのプロセスを使用してQAに合格し、実際のユーザーは不満を抱きます。結局、O_Bが間違っていたことが判明するまで戻ります。 問題はこれです。実際のシステムをテストするための「テストシステム」を作成することは悪い習慣ですか？ 滑りやすい斜面はどうですか？それでは、「テストシステム」をテストするためにさらに別のシステムが必要だと主張できないでしょうか。 開発者は少なくとも2つのコードベースを学習する必要があり、おそらくSystem_BはSystem_Aよりも複雑であるため、コストは明らかに法外です。System_Bが組織にとってどれほど良いか悪いかをどのように定量化しますか？ System_Bを作成する本来の「説得力のある」理由の1つは、テストを「自動化」することでした。現在、完全に自動化されていることを非常に誇りに思っています（System_Bが入力を生成して、それ自体を使用して出力も生成するプロセスをブートストラップするため）。しかし、定量化できない方法で、より多くの危害を加え、より複雑さを導入したと思います。QAの仕事は完全に自動化されていますか？その理由は、並列システムを作成することを正当化するのに十分ですか？ 私の本当の懸念はこれです。System_Bが間違っていることは誰もが知っています（かなり頻繁に）。System_Bが入力の処理に非常に優れていて、その出力がゴールドソースである場合は、System_AをSystem_Bに置き換えてみませんか？それに対して、職場の誰も満足のいく対応をすることができません。 この問題に関するガイダンスは大歓迎です。

10 unit-testing  testing  qa  acceptance-testing  integration-testing 

少し前、私たちは、SQL Serverをバックエンドとして使用して、顧客の古いメインフレームシステムを新しいイントラネットASP.NETソリューションで置き換えるプロジェクトを任されました。これの一部は、ビジネスのリエンジニアリングでもありました。基本的に、システムを変更するとき、ビジネスをよりよく行うにはどうすればよいかを考えていました。 したがって、最初のタスクは、論理データモデルと物理データモデルを組み合わせて実行することでした。顧客はこれらの議論に参加しており、完全にサインオフしていました。次のフェーズは、各モジュールの設計と構築を実際に行うことでした。さて、長い話を簡単に言うと、プログラミングは完了しており、システムの並列テストに取り掛かっています。これまでのほとんどのモジュールで問題はありません。 私たちには1つのシステムがあります。ビジネスユーザーにアプリケーションとレポートのみを表示する場合は、すべて問題ありません。新しい統合ワークフローと連携し、以前の手動プロセスを自動化し、仕様どおりに機能します。移行されたレガシーデータについては、並行テストでいくつかの問題が明らかになりました。レガシーシステムのビルダーは、新しいスキーマとビジネスプロセスを理解するのに非常に苦労しています。したがって、レガシーデータを取得して新しいスキーマに入れる方法を理解するのに非常に苦労しています。このため、彼らはビジネスユーザーと利害関係者の会議を呼び出し、新しいシステムは古いシステムが提供したデータを提供しない（実際にはそうである場合）-これは新しいシステムの見た目を悪くします。 これは控えめに言ってもイライラします。新しいシステムはうまく機能し、必要なすべての機能を提供します。ITスタッフが新しいテーブルに古いデータを入力できない場合は、ビジネスユーザーは新しい機能に満足しています。 これを処理する方法についての提案を求めています。いくつかの政治的動きのために、新しい「アーキテクト」はシステムがどのように機能するかを理解しておらず、ITスタッフが要求している変更の影響を十分に理解できません。ITスタッフはシステムにいくつかの根本的な変更を望んでいます。これは本質的に不要であり、実際には悪い設計ですが、彼らは顧客です。 何かご意見は？

10 design  customer-relations  acceptance-testing 

私は社内の開発チームに所属しており、マーケティングチームの要件に従って会社のWebサイトを開発しています。受け入れテストのためにサイトをリリースする前に、従うべきテスト計画を提供するように依頼されました。 ただし、開発チームは、要求者からの要求であるため、何をテストするか、何を探すべきか、どのように動作するかなどについて最良の知識を持っているため、テスト計画は不要であると感じています。私たちは常にこれについて議論しています。開発者は次のようなことを書き留めるのは時間の無駄です。 ボタンAをクリックします。 フォームフィールドにXYZと入力し、ボタンBをクリックします。 動作Cが表示されます。 これは、要求された要件/機能ごとに繰り返す必要があります。これは基本的に、要件ドキュメントに既にあるものを言い換えたものです。 プロジェクトの管理にはアジャイルアプローチを使用する方向に進んでおり、これは各反復の終了時にも要求されます。 単体テストと統合テストは別として、エンドユーザー受け入れテスト計画を立てるのは誰ですか？それは要求者ですか、それとも開発者ですか？ よろしくお願いします。 CK よろしく

10 web-development  testing  websites  acceptance-testing