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

近年、私は大規模なプロジェクトや小さなツールの人々のために小さなコンポーネントのみを作成しました。私はユニットテストを書いたことがなく、常にそれらの書き方を学び、実際にユニットテストを作成するのは、単にプログラムを起動して実際にテストするよりもはるかに時間がかかります。 私はちょうど完了するのに数か月かかる可能性があるかなり大規模なプロジェクトを開始しようとしていますが、（いつものように）書いているときに要素をテストしようとしていますが、ユニットテストで時間を節約できるかどうか疑問に思っています。 誰かが良いアドバイスをすることができるかどうか疑問に思っていました： プロジェクトの開始時に単体テストを検討し、TDDアプローチを採用する可能性があります。 各セクションが完了した後、テストを書くだけです。 プロジェクトを完了し、最後に単体テストを作成する必要があります。

29 testing  unit-testing 

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

29 testing  unit-testing  automation  acceptance-testing 

俗語のプログラミング用語を忘れてしまいました。これは意図的なバグまたは気晴らしとして使用されるおとり機能です。使用例は、「ボブ、QAが今日レビューを行っています。$THING実際に見つけるべき問題があるようにモジュールに入れてください」。 これは、実際の問題から注意をそらすものとして発見するための非常に明白な意図的な欠陥を持つために、否定的に使用することができます。 これも積極的に使用できます。被災地を捜索するときに、常に救助犬に被害者を「見つけさせる」方法と同じです。また、QAプロセスが実際に欠陥をキャッチしていることを確認するためにも使用できます。 私が探している用語は何ですか？

28 testing  terminology  debugging  quality  jargon 

Ruby on Railsで最初の実際のプロジェクトを開始し、TDDテストの作成を強制します。テストを書くことに本当の利点はないと思いますが、それは非常に重要だと思われるので、試してみます。 静的ページを含むアプリケーションのすべての部分をテストする必要がありますか？

28 testing  tdd 

私の現在の職場では、テスターはいません。その理由は、経営陣からの根拠です：「テスターがいれば、あなたはあなた自身のコードをまったくテストしないでしょう」。この種の考え方は、製品の品質に悪影響を与えるようです。自分のコードをテストしている間は、システムを裏返しに知っていて使用方法がわからないという事実だけでなく、見落としがちなことがたくさんあります。それは「間違っています」。専用のテスターが陥る落とし穴を無意識に回避するため、ブラックボックステストは実際には機能しません。私の多くの時間は、実動コードに滑り込み、エンドユーザーによって発見されたバグの修正に費やされます。 問題のシステムは大規模ですが、私だけが開発しています。また、これにより、スケジュールの定義や仕様の作成など、管理業務の一部が私の膝の上に置かれました。 この種のタスクは私の責任ですか？自分は厳密にプログラマーであり、他の何者でもない。そして、これらが私の責任であれば、どの程度ですか？プロジェクトがテスターを必要とするほど大きいのはいつですか？プログラマーは仕様を改良し、プロジェクトの管理について心配する必要がありますか、それともカスタマーサポートを提供する必要がありますか？ 注意 私は自分の責任を広げることに反対しているという印象を持っている人もいるかもしれません。そうではありません。より多くの管理職を含む役割を手に入れたいと思っていますが、現在は職務内容にありません。私がそのように正式に雇用されるまで、または追加の職務が私の給与に現れ始めるまで、私は自分を「単なる」プログラマーだと考えます。残念ながら、ジュニア開発者として、管理職への移行はすぐには起こりません。 これまでの優れた答えは、何か追加したいことや共有したい個人的な経験がある場合は、それらを続けてください！

28 project-management  testing 

私はTDDアプローチにかなり慣れており、最初の実験では、1行の機能コードを記述することは、2〜3行のテストコードを記述することを意味します。したがって、1000 LOCを記述する場合、テストを含むコードベース全体は〜3500 LOCのようなものになります。 これは正常と見なされますか？あなたが書くコードの割合は何ですか？

27 testing  unit-testing  tdd  metrics 

これが次の概念的な質問をする場所であるかどうかはわかりません（Stackoverflowは間違いなくそうではありません）。 この質問は、ISTQB試験に似た多肢選択試験（単一回答）で見ました。 同じ問題/チケットでいくつかの欠陥を報告することが推奨されないのはなぜですか？ a。レポートを簡潔かつ明確にするため。 b。開発者が修正できるバグは1つだけだからです。 c。テストグループのテスターは、発見したバグの量によって評価されるためです。 d。バグ管理システムは、複数のバグのこの機能をサポートしていません。 私の唯一の意見は、それaが正しい答えだということです。 b-fix-feedback-resolved-closedがそのケースを回避するはずなので、それはできません。 c-明らかに間違っています。 d -Redmine / Tracプラグインは複数のフィールドをサポートします。 解答用紙によると、答えはbです。 誰かが理由を説明できますか？回答に関する意見を含むコメントを歓迎します。

26 testing  development-process  bug-report 

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

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

Webフォームサイトを単体テストするにはどうすればよいですか？それの多くは状態とユーザー入力に依存するので、それは実行可能ではないように思えます。 実行可能でない場合、有効な自動化された代替手段はありますか？

26 testing  unit-testing 

私はプログラミングパターンとライフサイクルのプログラミングにまったく不慣れであり、最初に何をすべきか、コードレビューまたはテスト、それらは別々の人によって行われるのではないかと考えていましたか？ 一方では、それが機能するかどうか誰もチェックしなかったのに、なぜコードをレビューするのが面倒ですか？一方、テストの前にレビューを行うと、いくつかのエラーが早期に発見されます。 推奨されるアプローチとその理由は？

25 testing  code-reviews 

私は長い間開発者であり、請負業者であるため、いくつかの企業で多くのプロジェクトに携わってきました。 私はと推定して20％未満のプロジェクトを系統的にテストされています。綿密にテストされたとは、アドホックで計画的なテスト以外のテストを意味します。 また、チームの一部として専用のテスター、テスト計画ドキュメント、開発者が自動化されたテストを作成し、テストカバレッジを追跡し、結果を測定するプロジェクトでは、10％未満のプロジェクトが綿密にテストされていると推定しています。 2つの質問 この問題についての推定パーセンテージは何ですか？ ソフトウェアテストに関する専門的な経験は何ですか？ 追加メモ 系統的なテストの質問にはかなり偏った答えが得られる可能性があるため（人々は他の人より優れていることを自慢したい）、他の開発者（系統的なテストにさらされていない開発者）にも答えを提供することをお勧めします。あなたの会社を除いてどこでも行われています。

25 testing  metrics 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 基本的に、最悪または最良のケースである可能性のあるもの、およびそれらを取得する前に発生する可能性のある他の「エッジ」ケースをどのようにして見つけるのですか？

25 testing  algorithms  knowledge-base 

私の同僚が、私が面白いと思うアイデアを思いつきました。 TDDを行わないと想定してレビューを行う人が、コードレビュー中にテストを書くことは有益ではないでしょうか。 この質問では、これは純粋にアカデミックなプロジェクトであり、命にかかわることはないと想定しています。さらに、チームは4人です。誰もが言語を知っており、使用されるすべてのツール/ライブラリ/フレームワークに精通しており、テストを書くことができます。したがって、基本的には、上級のフルスタックではない人が忍者のエンジニアをリードしていますが、まともなコーダーです。 私が見つけた長所： レビュー中にコードのより深い理解を促し、意味のあるテストを作成します。 次に、テスト対象のコードの作成者が行ったテストのコードレビューを追加できます。 短所： コードの作成とテストの間のフィードバックループが拡大します。 編集：私はそれが「通常の」Webアプリケーションではうまく動作しないことを知っています。私が念頭に置いていたのは、細部に注意を払う必要のある複雑で科学的なアルゴリズムを実装するコーナーケースです。独自のグラフライブラリ、NLPなどの実装のようなものを想定しましょう。作成しているコードがデータベースから分離されているなど、理解するのが非常に難しいのは、ソースを理解する必要のある他の人ではありませんコードを作成し、意味のあるテストを行い、プロセス全体を、アプリケーションをクラッシュさせず、最終的に結果をゴミにするようなそれほど明白ではないバグを起こしにくくしますか？

24 programming-practices  unit-testing  testing  teamwork  workflows 

私はアジャイル手法を実践しようとする多くのチームに所属しており、多くの場合、これらのチームはテスト中心です。テストはアジャイル手法を実践するのに必要な部分ですか、それとも長年にわたって定着しているXPの実践ですか？

24 agile  testing  extreme-programming 

そのため、テストの価値を本当に理解していない人から何度も聞いています。物事を始めるために、私はアジャイルとテストのフォロワーです... 私は最近、製品の書き換えでTDDを実行することについて議論しました。現在のチームはどのレベルでも単体テストを練習しておらず、おそらく依存性注入手法やテストパターン/デザインなどについて聞いたことがないでしょうコードをきれいにするために）。 現在、私はこの製品の書き換えについて完全に責任を負っており、TDDのように試してみると、単にメンテナンスが悪夢になり、チームがメンテナンスすることが不可能になると言われています。さらに、それはフロントエンドアプリケーション（Webベースではない）であるため、テストの追加は無意味です。ビジネスドライブが変化すると（当然、改善を意味します）、テストは時代遅れになります。将来のプロジェクトはそれらを維持せず、彼らが修正するなどの負担になるでしょう。 現在、テスト経験のないチームのTDDは良く聞こえないことは理解できますが、この場合の私の主張は、周囲に練習を教えることができるということですが、さらに、TDDがより良い結果をもたらすことを知っていますソフトウェア。TDDを使用してソフトウェアを作成し、メンテナンスチームに引き渡す際にすべてのテストを破棄する場合でも、TDDを最初から使用しないよりも確実に良い方法でしょうか。 TDDを聞いたことがないチームのほとんどのプロジェクトでTDDを行うことについて言及したので、私は撃downされました。「インターフェイス」と奇妙な外観のDIコンストラクターの考えは、それらを怖がらせます... 通常、TDDを販売しようとするという非常に短い会話や、人々への私のアプローチについて、誰か助けてください。会社/チームにひざまずく前に、私は通常非常に短い議論の窓を持っています。

24 testing  agile  tdd  bdd