qa - QA は厳密にブラックボックスの観点からテストする必要がありますか?

Question

単体テストが開発によって処理されると仮定すると、QA が製品の仕組みの詳細を知る必要がある理由はありますか? つまり、彼らはバックグラウンドで何が起こっているかを知る必要があり、通常の UI を使用せずに製品のセグメントをテストする必要があるのでしょうか? たとえば、テスターがデータベースに入り、手動で値を変更して何が起こるかを確認することは理にかなっていますか?

編集:
非開発者が使用するアプリケーションで作業していると仮定しましょう。API が添付されたものには取り組んでいません。

Answer 1

それは、アプローチと作成しているソフトウェアの種類によって異なります。QAにはさまざまな種類があります。ソフトウェアがフォールト トレラントである必要がある場合、QA はフォールトをシミュレートする必要があります。また、製品がどのように機能するかを知ることは、QA が潜在的に問題のあるケースを考え、より徹底的にテストするのに役立ちます。

一方、製品がどのように機能するかを知っていると、QA がユーザーの観点から完全にテストすることができなくなる可能性があります。したがって、最初に内部を知らずに基本的なテストを設計し、次に潜在的な問題に基づいてより詳細なテストを設計する必要があります。

Answer 2

確かにそれはアーキテクチャに依存します。私は、別の建物の完全に別のチームによって db 層が開発、管理、およびテストされるプロジェクトに取り組みました。彼らの QA は、手順、クエリなどすべてがさまざまなテスト条件で実行されるかどうかを確認するために、データを徹底的に調べました。

あなたがUIエンドにいる場合、2つのレベルがあります。1つは、QAがアプリケーションの実用的な知識を必要としない単純な機能テストです（おそらくすべて自動化する必要があります）。次に、アプリがやるべきことをします。2 番目の種類については、QA チームがその仕組みを知っていると非常に役立ちます。最初にばかげたバグを拒否することで多くの時間を節約できますが、さらに重要なことは、ユーザーがユーザーのように振る舞い、より複雑なオーバーレイ シナリオを試すエンド ツー エンドのユース ケースを持つ必要があることです。このようなテストを設計するには、アプリケーションに関する十分な知識が必要です。

Answer 3

テスターがソフトウェアの実装についてできる限り多くのことを知っていることは、まったく理にかなっています。それは彼らがより良いテストをするのに役立ちます.

ブラックボックス テストは便利で必要な手法ですが、内部で何が起こっているかを少し知っておくと、本当に興味深いテスト ケースを定義しやすくなります。

ホワイトボックス テストのすべてのニーズを開発者の単体テストに依存することの問題点は、開発者は概して、特に自分が作成したコードに関しては、あまり徹底したテスターではないことです。

Answer 4

私が関わったプロジェクトでは、QA はユーザーの観点からテストされ、そのテストは要件を満たすという観点から行われました。彼らのテストはブラックボックステストでした。ホワイトボックステストは開発者によって行われました。QA 担当者が DB クエリ ツールを開いて手動で値を変更するとは思いもしませんでした。これは、開発者の単体テストの責任でした。

Answer 5

それは、QA チームが特定のプロジェクトで果たす役割に依存すると思います。データベースに特定の値が存在することから生じる状況はテストケースで表現する必要があるという議論ができると思います。そのように表現できる場合、開発者はそれらの状況の単体テストを作成する必要があります (作成する必要がありました)。 .

コード インスペクションを使用して欠陥を特定して修正した場合は、QA を舞台裏で公開する必要はないかもしれません。ユーザー エクスペリエンス以外のコードをテストすることが役立つプロジェクトもあると思いますが、ホワイト ボックス テストやクリア ボックス テストではなく、ブラック ボックス テストに QA チームを使用する可能性があります。

Answer 6

QA 担当者がアプリケーションの仕組みに関する詳細な内部知識を持っていないのには、あらゆる理由があると思います。QA スタッフは、ターゲット ユーザーとほぼ同じレベルのコンピューター能力を持っている必要があります。

その理由は簡単です。QA 担当者がアプリケーションの構築方法を知れば知るほど、通常のユーザーが遭遇する通常のユーザビリティの問題を回避できる可能性が高くなります。

QA は、アプリケーションが機能するかどうかをテストするだけではありません。また、平均的なユーザーが理解できるかどうか、つまり実際に使用できるかどうかをテストする必要もあります。

更新
これは長すぎてコメント ボックスに収まりませんでした。

@testerab さんの質問について。

私は QA を、1. ビジネス要件が満たされていることを保証する責任を負う人またはグループと定義します。2. これらの要件に関するアプリケーションの機能にエラーがないこと。したがって、モニカ「品質保証」。QA に関連すると私が考える 3 つ目の項目は、単純に使いやすさです。

彼らはビジネス要件を理解している必要があります。つまり、ビジネス アナリストやエンド ユーザー (存在する場合) と協力して作業する必要があります。私が一緒に働いた最高の QA メンバーは、これらの分野から採用されました。私が見た中で最悪の QA メンバーは、開発者であるか、そのように訓練されていました。また、テクニカル サポートから移動した人は、エンド ユーザーがどのような種類のゴミを試すかを正確に知っているため、優れた QA メンバーになる傾向があります。

アプリケーションにはさまざまなクラスがあります。最も一般的なのは、美化されたデータ入力です。情報を入力してボタンを押す画面がいくつかあります。その後、情報は必要な場所に保存および/またはルーティングされます。MS Word から CRM まで、すべてがこのカテゴリに分類されます。

したがって、QA 担当者の仕事は、最初にアプリが目的の入力を受け入れ、目的の機能を実行することを確認することです。2 番目のステップは、不適切な入力を送信し、アプリが望ましい方法で応答することを確認することです。たとえば、爆発したり、悪い情報が通過したりすることはありません。このような場合、自動テスト ツールが効果を発揮します。最後の部分は、その機能を 3 つのメニュー レベルの深さに埋め込むか、それとも簡単にアクセスできるようにするかを決定することです。

上記のいずれも、QA 担当者がコードを読んだり、ビットをいじったりする必要はありません。

一部のシステムには UI コンポーネントがありません。これらの場合、QA チームがデータを送信して結果を確認できるようにするテスト ハーネスを提供するのは、開発者次第です。これは、Web サービスと、想像できるあらゆるタイプの EDI を対象としています。

他のシステムは、それ自体が API です。これらには、そのような API 呼び出しを自分で実装するのに十分な知識を持つ QA 担当者、または開発者が API 呼び出しを簡単に呼び出して結果を記録する方法を提供する必要があります。この場合、QA チームは独自のプログラミングを行うことができますが、基になるコードにはアクセスできないことが望ましいです。

実際のコードをレビューする際の問題は、人が見ているものだけに集中する傾向があることです。これは悪いです。代わりに、数値入力が必要なテキスト ボックスにやみくもに「ABC」と入力できるように、人為的な制限から精神的に解放される必要があります。

---

何をテストするかを知るためにコードを「見る」限り、これはまったく別の問題であり、コード レビューの設定で訓練を受けた開発者がより適切に解決できる問題です。ここでの目的は、考えられるエラー、ベスト プラクティス、セキュリティの失敗などを特定することです。QA 担当者は、アクティブな開発者である必要があるため、このレベルの分析ができることはほとんどありません。

---

SDET について: 製品に開発者が他のものを構築するために使用する API または基盤がある場合、またはそうである場合は、通常の QA グループをサポートするために、ソフトウェアの実装に専念する 1 人または複数の人が必要になる場合があります。私はこの役割の必要性について確信が持てず、プロジェクトごとの決定になる可能性があると考えています。

API をテストするのにより適した 2 つのグループがあると思います。これらは、すでに実装しているエンドユーザーと、それを構築した会社の他の開発者です。ドッグフードは今や一般的な慣行であり、非常に費用対効果が高い. 結局のところ、うまくいかない場合は、すぐに修正されると確信できます。エンド ユーザーにとっては、開発チームが対応する実際の会話と見なされる限り、喜んで「テスト」してくれます。

私は 3 つの状況すべてに遭遇しましたが、エンド ユーザーとして、元の開発者にアクセスできることは問題の解決に大いに役立つと感じています。特に彼らが製品も使用している場合。通常、これらのプロジェクトに関連する QA 担当者への誤訳の量は、まさに恐ろしいものです。

---

要約すると、私はあらゆる種類の QA 担当者と仕事をしてきました。どうやって車で通勤したのかと思ったものから、アプリを詰まらせたコーナーケースを見つけることに長けたスーパースターまで。

1. プログラマーではなかった。2. ビジネスを理解した。3. エンド ユーザーが日常的に行っていることを正確に理解する。4. ソフトウェアの影響を受ける人々を正直に気遣う。

最悪の人の特徴は次のとおりです。 1. プログラマーだった、またはそう思っていた。2.ビジネスを理解していませんでした。3. エンドユーザーに会ったことがない。4.「ばか」という言葉を頻繁に使用しました。5. 使えるかどうかではなく、どのように機能するかという仕組みにとらわれた。

Answer 7

ハイブリッドアプローチはうまく機能すると思います。ホワイト ボックス テスト (単体テスト) とブラック ボックス テストを組み合わせて使用​​すると、より良いカバレッジが得られます。それぞれに長所と短所がありますが、他方の弱点を部分的にカバーしています。

コードの内部動作を理解すると、特定の方法でテストするようになりますが、これが特定の問題を発見する最善の方法であるとは限りません。