4

間違った場所でこの質問をしている場合は、心からお詫び申し上げます。(おそらく、キャリア アドバイスと QA に固有のミニ スタック オーバーフローの 1 つです) 私は最近、プロジェクトの単体テスト フレームワークについて学び、実装することにかなりの時間を費やしました。

単体テスト フレームワークが導入される前は、コードを記述し、手動でテストし、コミットし、問題が発生したり、問題が発生したりしないことを願っていました。非常に反応的なシステム。

今では、物事をテストする必要があり、自動化されたテストが効率的で優れていることを誰もが理解しています。ただし、現在の役割は「テストを行います」と「自動テストを書く」のようです

手動でテストを行うことは可能ですが、圧倒され (常にバグが存在するため)、自分のスキルが十分に活用されていないように感じます。

リクエストの 2 番目の部分を達成するのに苦労しています。コードがテスト可能に設計されていない場合、自動テストを作成することは困難です。

私は QA を担当していますが、テスト駆動開発に関するリソースしか見つかりません。

他の開発者がまだテスト可能なコードを作成することに関心を持って書いていない場合、QA の役割をより効果的にするには、どのような方法を使用できますか?

4

5 に答える 5

2

Test-driven developmentとunit-testingという名前の問題点は、それらがソフトウェアのテストに関するものであることを暗示していることです。そうではありません。TDD と単体テストは設計に関するものであり、基本的に開発者の責任です。

QA アナリストの役割は、TDD を実践するどのチームにおいても依然として最も重要であり、良心的な QA としての仕事を失うまでには、長い時間がかかるでしょう!

受け入れテスト駆動開発を見て、おそらくFitNesseなどのツールを使用して、自動化された受け入れテストを作成することにより、要件段階でさらに関与することを検討してください。

もちろん、手動の探索的テストは今でも有効です。しかし、回帰テストを繰り返すことは基本的人権の侵害と考えるべきです!

于 2010-08-29T11:30:52.213 に答える
1

開発者は少なくともユニットテストを書くべきだと思います（おそらくTDDを使用して）。これは、チェックインするコードが潜在的に機能していることを保証するための最小限の標準です。

ソフトウェアがクライアントの要件を満たしていることを確認するために、より高いレベルのテストを提供する人物としてのQAの役割を理解しています。したがって、実際には個々のクラスではなく、モジュールまたはアプリケーション全体をテストします。開発者が単体テストを提供しなくても、エンドツーエンドのテストを自動化できるはずです（これには通常、テスト環境のセットアップの自動化などが含まれます）。ただし、作業はさらに苛立たしくなります:)

于 2010-08-26T16:13:50.130 に答える
1

開発者が単体テストに慣れるのがあなたの主な関心事だと思います！そうすれば、誰もが勝者になります。

その時点まで、実際にはレガシーコードを使用しているので、Michael Featherの著書「レガシーコードを効果的に使用する」には、そのようなコードのテストに関する多くの有用なアドバイスが含まれているようです。

あなたはおそらくこれをすでに知っているでしょうが、自動統合テストの作成に関する多くのことを含むビヘイビア駆動開発（BDD）もチェックしてください。これはあなたにとって興味深いと思います。

于 2010-08-26T16:13:51.863 に答える
1

私も数年前に同じような仕事をしていたので、お気持ちはよくわかります。開発者が単体テストに慣れるために、メンタリングとペア プログラミング セッションをお勧めします。うまく設計されていないクラスの最初の単体テストを作成するのは、本当に大変なことです。最初のリファクタリングで愚かな間違いを犯す可能性を下げることは言うまでもありません。

@Grant で既に言及されているように、Feathers の本は、このための非常に貴重なリソースです。結果 (テスト範囲とチーム態度の両方) がゆっくりと現れ始める前に、最初の数か月間は辛抱強くやり遂げてください。

強力な管理サポートも必要です。これがなければ、試しても意味がありません。経営陣は、単体テストの構築は投資であり、現在、時間とエネルギーのかなりの部分を使用しており、将来の年にのみ元が取れることを理解する必要があります。彼らがこれまでと同じ締め切り圧力を維持することを主張するなら、あなたは必然的に失敗するでしょう. 開発者は、強いストレスや意欲を失っていると、新しいスキルや考え方を学び、実践することができません。

(コインの反対側は、もちろん、投資が利益をもたらすかどうかを考えなければならないということです。レガシー コードの単体テストを構築する価値があるのは、製品が何年にもわたって維持され、使用されることを経営陣が予測している場合のみです。来て。）

于 2010-08-27T14:05:40.300 に答える
1

私の経験では、人々はテストの作成について一夜にして好転することはありません。彼らを説得するのはプロセスです。プログラマーは最終的にはしぶしぶ試してみますが、支持者や常習者になるまでにはまだ数週間または数か月かかります。これは困難な戦いであり、上層部からのサポートと、チーム内からの優れた支持者が必要であることを認識してください。

自分でテストを書くことができます:

バグの約半分が以前のバグの「リグレッション」であることを考えると、あなたの状況では、新しい重大なバグのリグレッション テストを書くことに集中します。これは、通常の QA 作業に大いに役立ちますが、将来のバグに対する優れたセーフティ ネットにもなります。

開発者にすぐにテストを書くよう説得できなくても、開発者がすぐにその価値を理解する貴重なテストが得られます。この作業は、開発者が単体テストを作成するというアイデアを売り込むのに役立つかもしれません。

于 2010-08-27T05:42:14.950 に答える