直感的なテスト。 トリッキーなバグを見つける方法は？

「アドホックテストは、計画と文書化なしで実行されるソフトウェアテストで一般的に使用される用語です」

直感的なテストの利点：

1.「擬似カオス」テスト

ソフトウェア開発に近い人からよく聞かれますが、「すべてのテスターはオタクです」などのテストフレーズからはほど遠いです。 おそらく、この意見は、私たちテスターがほとんどの時間を日常業務に費やさなければならないという事実のために形成されたものです。新しいビルドがリリースされるたびに。 このような作業は、テストプロセスの明確な明確さ、つまり ケース番号1を取り、手順を再現し、通路にマークを付け、ケース番号2を取ります。 創造性がなく、左右のステップ=撮影。

したがって、このルーチンはテスターの健康で若い脳を落ち込ませずにはいられません。テスターは仕事を得て、インターネットで「テスターは創造的な人」であると読みます。 、そこをクリックして、ここに行きたいのですが、データベースに手を出したいです。一見したところ、ここは創造性ですが、それほど単純ではありません。 多かれ少なかれ経験豊富なテスターは、頭の機能のテストを開始する前に、テスト計画と、同じテストケースNo. これは、プレフィックス「疑似」について説明しています。 したがって、直感的なテストとテストケースの通過を交互に行うことで、脳からのストレスを軽減できます。

2.新入社員の強制トレーニング

各テスターは少なくとも自分のプロジェクトを知っている必要があります。 新しいテスターの登場により、「プロジェクトを知る方法を彼に教える方法は？」という疑問が生じます。 一部の企業では、テスターはすぐに戦闘に投入されます-彼らは、実行のために数百のケースを与えます。 実際、すべてが手順に書かれているのなら、なぜ教えるのか。 したがって、同社は、テストキットのほとんどをパスするまで、3〜5か月間「サル」を取得します。 その後、テスターは、ステップを再生する以外の機能を実行するのに十分なプロジェクトを熟知しています。 同じテスターが1週間（40〜50時間）ケースを調べる代わりに、興味のあるオブジェクトに関する仕様とdzdoksを読みながら、必要なバグをランダムに検索する必要があると想像してみましょう。 1週間以内に、テスターは3〜5か月でケースを渡すことで知っていることの70％を知っています。

3.この方法の主な利点は、再現が難しいだけでなく、再現方法が不明な「トリッキーで潜行性のある」バグを検索できることです。

たとえば、プレイヤーは、Habrahabrの呪文を勉強した後、クライアントが倒れたと書いています。 最も簡単な再生手順は次のようになります。

1.魔法の塔に入る

2.呪文「Habrahabr」を学ぶ

期待される結果：クライアントはクラッシュしてクラッシュしました。

実際の結果：呪文が学習されます。



バグが再生されなかった場合、どうすればよいのでしょうか？ 彼が最後の15分前にやったことをすべて思い出すように頼むことができます。 80％は覚えていません。 その後、ed Hockのみが残ります。 「すべてのコストでプレイする」というモットーの下で、私たちはクライアントを開き、あらゆる種類のユーザー行動アルゴリズムで脳を攻撃します。 合計：2〜100時間後、バグが再現され、プレーヤーの耳は費やした時間に比例して燃えます。 そしてバグは単純であることが判明しました。icq6でメッセージを受信中に、Skypeがインストールされているコンピューターで安定したクライアントがクラッシュしました。