how test an application without requirements
技術的には、要件のないアプリケーションはありません。特定のことは何もしないが、コードの行が次々と伸びるだけのソフトウェアを想像してみてください。どこにも通じない階段になります。
すべてのソフトウェアには要件があり、特定のタスクを対象としています。具体的には、問題の解決策です。そう 要件なし ソフトウェアは可能性がありません。
ただし、要件が文書化されていないソフトウェアは、残念ながら私たちのほとんどがより頻繁に直面する現実です。 私たちが好き。さらに悪いのは、ドキュメントが不十分、不正確、またはひどく古くなっていることだけです。悲しいことに、これも起こります。
正直なところ、精巧なユースケースとモックアップ画面を備えた、十分に文書化された機能/システム要件ドキュメントに代わるものは実際にはありません。急速な開発サイクルと最小限のドキュメントまたはドキュメントなしへのパラダイムシフトにより、これは業界では珍しいことであることを認めなければなりません。
したがって、この記事は、これらの状況で自分自身を見つけたときに私たちが従ったいくつかの実践の試みです。
また読む:
経験豊富なソフトウェアテスターのサンプル履歴書
最初にいくつか見てみましょう そもそも、ドキュメントがない理由:
- 棚上げされたプロジェクトが再開されます
- ドキュメントのない作業形式-プロセス
- ドキュメントが存在する可能性がありますが、詳細または完全ではない可能性があります
- 継続的なリリースと古いバージョンの関連情報はアーカイブされていないため、既存の機能が新しい機能とどのように反応するかについての理解にギャップが生じています。
これらはすべて、テスターが勇敢に乗り越えて成功するために必要な障害です。でも正確には?
要件なしでアプリケーションをテストするための上位3つの方法は次のとおりです。
方法#1:
手に入れることができるどんな小さなドキュメントでも作業してください。これは、基本的な単純なバックログ(アジャイルプロジェクトの場合)、ヘルプファイル、電子メール、古いバージョンのBRD / FRD、または古いテストケース(ALMツールでこれらを確認すると見つかる可能性があります)などです。
調査し、周りに尋ねると、たとえそれが薄いものであっても、常にいくつかの文書化された裁判があります。
これがうまくいかない場合は、ソフトウェアユーザーとしての経験を軽視しないでください。例えば、銀行口座の送金操作をテストする必要がある場合、誰もこれを行う方法を教えてくれる必要はありませんね。オンラインバンキングの顧客として、私たちは皆、送金に利用できる多くの資金を持った口座との間で必要であることを知っているからです。
すべての状況がそれほど単純になるわけではないことに同意しましたが、繰り返しになりますが、そうなる可能性もあります。
方法2:
ソフトウェア製品の将来のリリースをテストするための参照として、アプリケーションの古い/現在のバージョンを使用してください。さて、これは「アプリケーションを参照として使用してテストケースを作成しない」というルールに反していることを認めます。ただし、完璧とは言えない状況で作業している場合は、ニーズに合わせてルールを作成する必要があります。
そうするときは、次の側面を視野に入れておくと役立ちます。
- アプリケーションにバグが含まれている可能性があるため、登録後にシステムが直接Screen1(この例では特定の架空の画面)に移動する場合は、それが正しい動作であると思い込まないでください。また、フィールドが英数字を取り、電話番号である場合、その質問であり、期待される機能の当然の例としてアプリケーションを取り上げないようにしてください。
- 上記の状況では、あなたの判断を使用し、アプリケーションの助けを借りてジャンプスタートを提供しますが、それが機能していることを疑うことには批判的です。
方法3:
プロジェクトチームのメンバーと話します。
- 彼らの会議に出席することを申し出る。
- ユニットと統合テストの段階に参加できるかどうかを尋ねます。
- そうでない場合は、開発チームがユニットと統合テストの結果を共有できるかどうかを尋ねます。
- 都合の良い時間に知識の伝達のための時間を手配します。
それでは、例のメソッドを適用してみましょう。
ショッピングカートに商品を追加できるショッピングサイトがあるとしましょう。理想的には、ドキュメントがあれば、アイテムを追加する方法、特定の時点でいくつのアイテムを持つことができるか、追加したアイテムが突然在庫切れになったときに何が起こるか、最大数を教えてくれる必要があります同時に購入できる同じアイテムの数など。私たちの状況では、現時点ではそのどれも利用できません。
方法#1を適用します。
可能なドキュメントを見つけてください。開発チームにモックアップ画面があるかどうか、ALMツールを見るかどうかなどを尋ねます。あなたが何かを見つけたら、それは良い出発点になるでしょう。しかし、この方法で何も起こらない場合は、 テスターの判断/直感。
ショッピングカートがどのように機能するかは誰もが知っているので、仮定を立てて、次のようないくつかの基本的なシナリオに到達します。
- アイテムは、閲覧または検索された後、ショッピングカートに追加できます
- ショッピングカートにアイテムを追加すると、アイテムのリストが更新されます
- カートにアイテムをいくつか追加した後でも、ユーザーは買い物を続けることができるはずです。
- 同じアイテムを2回追加すると、追加されたアイテムの数が増加します
- アイテムは更新できます
- アイテムは削除できます
- 合計は、追加されたすべての価格の合計に相当する必要があります
- 税金は、入力した郵便番号に基づいて計算する必要があります
- それに応じて送料を追加する必要があります
私たちは続けることができますが、あなたが写真を撮ると確信しています。
方法2を適用します。
古いバージョンのアプリケーションが利用可能な場合、クリックする場所、入力を入力する場所、確認する内容などの正確な手順を記述する必要があるため、これはテストケースの作成に役立ちます。スクリーンショット/モックアップ/ワイヤー-フレーム–利用可能な場合は、優れた代替品にもなります。
下の画面からわかるように、これらのことは明らかです-フィールド名、ボタン、または存在する他の要素など。 (画像をクリックすると拡大表示されます)
さて、この時点で、テスターには次のようないくつかの質問があります。
- 金額ボックスに文字を入力するとどうなりますか?
- アイテムを追加しすぎるのはいつですか?
- 最大数はいくつですか。これが取ることができるアイテムの?等。
方法#3を適用する :
質問のリストをBA、開発者、さらにはクライアントに持っていき、説明を求めてください。方法3が完了すると、詳細なテストケースを作成し、詳細なドキュメントが利用可能になったときと同じくらい自信を持ってテストを実行するために必要なすべての情報をほぼ身に付けることができます。
それはもっと多くのステップともっと多くのフォローアップであることに同意しましたが、品質テストを確実にするために、これらのステップは避けられません。
結論として、 ドキュメントが存在しないか不十分な場合でも、すべてが失われることはありません。まだ希望があります!同様の状況での経験を共有してください。
著者について: この役立つ投稿は、STHチームメンバーのSwatiSによって書かれています。
いつものように、あなたのコメント、質問、提案は大歓迎です。