メニュー

テスターとして悪い要件に対処する方法

how deal with bad requirements

問題を排除するために楽器を試してください

静かな会議室は窒息し、その中の誰もが混乱していました。 どうしてそれを見逃すことができますか 、みんなの顔が反映した質問でした。

結局のところ、ユーザーが既存のレコードを複製しようとしたときに関連するエラーが表示されず、複製を許可することは小さなバグではありませんでした。保険会社にとってもそうです。

問題を突き止めることに決めた後、全員が解散しました。そして、掘り下げている間、クライアントは要件文書のレコードの重複について何も言及しなかったため、関連する質問をしたり、それについて考えたりすることはありませんでした。

悪い要件

これはほんの一例です。

10年以上のキャリアの中で 、私はプロジェクトが悪いまたは不十分な要件のために苦しんだ多くのケースを観察しました。

しかし、彼らが言うように、この世界では完璧なものはなく、それに対処する必要があり、要件のないプロジェクトや不十分な要件のプロジェクトに対処することは、ある種の悪夢です。

説明させてください–

学習内容：

要件がどれほど悪く、貧弱で、矛盾しているのかが面倒です。

＃1）要件なし– 要件がないということは、仮定と推測を意味するため、自信がありません。ベースラインなしで製品/アプリケーションをテストすることは非常に困難です。そして、これらはより多くの仕事、クライアントからのより多くのバグ、そしてプロジェクトへのより多くの苦しみをもたらします。

  • どのようにあなたは 問題を報告する 動作を処理する方法の定義が利用できない場合のシステムクラッシュについて？
  • パフォーマンスに関連する要件がない場合、ホームページの読み込み時間が100秒では受け入れられないことをどのように伝えますか？

要件なしとテスト中に状況を処理する方法の詳細については、以前に公開された記事を参照してください– 要件なしでアプリケーションをテストする方法は？

＃2）不十分な要件– 引用、 不完全なことを知ることは、まったく知らないことよりも危険です。 、不十分な要件に対処することになると非常に真実です。

不十分な要件を解釈し、それを実装することは大きなリスクです。

  • 言及された唯一の要件が–検索結果が適切であり、検索中にどの基準を考慮する必要があるかわからない場合、検索結果を表示するポップアップが有効かどうかをどのように確認しますか。
  • これをどのように解釈しますか–ユーザーが忘れたパスワードを再生成/リセットしやすくするために、忘れたパスワードを実装する必要があります。顧客がパスワードを忘れた場合にどのワークフローを望んでいるかは不明ですが、開発者は自分が最善だと思うものを実装し、競合が始まります。

＃3）矛盾する要件– 誰かに2つの異なることを同時に行うように頼むことは、彼/彼女を混乱させるだけであり、システムも例外ではありません。

  • 上記の要件でアプリケーションをどのようにテストしますか？
    • アプリケーションは常にホームページで開く必要があります。
    • ユーザーは、アプリケーションにアクセスするためにサインインする必要があります。
  • 要件文書が以下の場合、優先順位をどのように決定しますか？
    • ユーザーが1000点を獲得した場合、ゲームアプリケーションはユーザーを次のレベルに昇格させる必要があります。
    • ユーザーが1000を獲得したら、無料のサブスクリプションページにリダイレクトする必要があります。

そしてそれが、悪い、貧しい、そして相反する要件が面倒を生み出す方法です。

ソフトウェア業界にいるので、顧客でさえ彼らが正確に何を望んでいるか、そしてそれをどのように表現するかわからないことがあるので、それはプロジェクトの一部であるべきです。

テストの観点からは、これらのあいまいな要件やあいまいな要件を処理することは困難ですが、完全に不可能というわけではありません。

考えられる解決策を見てみましょう。

悪い要件とそれらをテスターとして扱う方法：

方法＃1）探索して学ぶ：

他のアプリケーションを探索し、一般的に期待される動作について学び、ワークフローを理解し、ユーザーの利便性について考え、ロジックを適用することは、状況に対処する1つの方法です。また、 探索的テストに依存する 要件が明確でないこの種の状況で役立ちます。

ほとんどの場合、要件が明確でない場合は、ユーザーエクスペリエンスと利便性を優先することをお勧めします。

方法＃2）経験を活用する：

経験を生かす

ドメインの経験 、全体的なテスト経験、過去に直面した問題、および個人的な洞察は、混乱する状況や要件に対処するのに役立ちます。

方法＃3）ワイヤーフレームを参照してください。

ワイヤーフレームは一種の視覚的要件であり、詳細をほとんど見つけることができません。これらの詳細は、製品またはアプリケーションの予想される画像を作成するのに非常に役立ち、テストの側面をより適切にカバーするのに役立ちます。

続きを読む => ワイヤーフレーム–実際にテストする必要がありますか？もしそうなら、どのように？

方法＃4）ピアディスカッション：

Web開発に必要なツール

ピアディスカッション

どんなに混乱していても、たくさんの人と話し合うと、物事が明らかになります。誰もが異なる経験、期待、ユーザーの目、分析の見方を持っており、それらの貧弱な要件について仲間と話し合うことは、理解を具体化し、自信を高めるという利点に役立ちます。

方法＃5）お客様からの説明：

顧客は製品/アプリケーションの所有者であり、要件の明確さに関しては常に顧客にアプローチすることが賢明です。ただし、何百もの質問で顧客を攻撃することはお勧めできません。そうする前に、いくつかの宿題が必要です。

利用可能なベストプラクティスを見つけ、実装の利点を理解してから、質問と可能な解決策についてお客様に連絡してください。

結論

最後に、大まかに定義された要件または定義されていない要件はテスターの生活の一部であり、それらを受け入れる必要がありますが、楽観的になり、その解決策を決定してみましょう。結局のところ、私たちはテスターであり、アプリケーションを軌道に乗せ、フラットになるのを防ぎます。やったー:)

著者について： この感動的な投稿は、STHチームメンバーのBhumika Mによって書かれています。彼女はプロジェクトリーダーであり、10年以上のソフトウェアテストの経験があります。

いつものように、ハッピーテスト…..あなたの意見、コメント、意見を待っています。

推奨読書

^