QA で働いていると、頭の中で 声がよく聞こえます。時には役に立つきっかけになることもありますが、そのまま放置しておくと問題になり始めます。以下では、この厄介な とそれがどのように現れるかについてお話します。 「本当にすべてチェックしましたか?」という 内部バグ この記事では、この現象を研究して得た私の考えや洞察を共有したいと思います。皆さんにとって役立つものになれば幸いです。また、コメント欄で皆さんの意見を聞かせていただければ幸いです。結局のところ、フィードバックは自分自身を外から見て改善するための最良の方法の 1 つです。 内なるバグの利点: 「すべてを確認しましたか?」 最も単純なタスクであっても、細部まで注意して慎重に取り組むよう促します。 あるとき、タスクを切り替えてテストを終えた後、念のためすべてをダブルチェックすることにしました。そのとき、小さいながらも重要な詳細に気づきました。タスクには、新しい関数が実行するはずの計算式が含まれていなかったのです。不思議に思い、タスクの説明とエピックの両方を読み直してみたところ、驚いたことに、計算式はどこにも指定されていませんでした。では、どうやって計算していたのでしょうか? 恥ずかしいことですが、私は別のタスクの計算式を使って計算を検証していました。2 つのタスクは関連していましたが、計算式は独立して機能するはずでした。この見落としに気付き、すぐに正しい計算ルールを要求してタスクを再テストしたところ、開発者も同じミスを犯していたことがわかりました。開発者も別のタスクの計算式を使用していたのです。 この厄介な小さなバグにより、重大なエラーを発見し、製品の信頼性を高めることができます。 テスト計画を確認すると、この小さなトラブルメーカーは、「クライアントが大きなフォントサイズや古い OS を使用したらどうなるか」といったアイデアを出し始めます。 おかげで、テストをより徹底的に文書化でき、レポートにビデオやスクリーンショットを含めることもよくあります。 これは、テストが完了し、機能が稼働しているときに突然エラーが発生したときに非常に役立ちます。エラーが特定され修正された後、テスト記録をチェックして、テスト中に問題を見逃したのか、それとも運用後に導入されたのかを判断します。スクリーンショットや録画に隠れているバグを見つけることもあります。このような場合は、なぜ見逃したのか、なぜそれを検出するためのテストケースがなかったのかを詳しく調べます。 自己反省的な観点から、この内なる声のマイナス面について考えてみましょう。 たいていは理由もなく不安が増す これは、何かの失敗の後に起こることもありますが、理由もなくリトルバグの声が鳴り響くこともあります。何度か、私が寝た後もリトルバグが私を放っておかなかったため、他に何をチェックすべきかをメモする羽目になったこともあります。 非常に複雑なテストケースで時間を無駄にしてしまうことがよくあります これは最初のポイントの直接的な結果です。不安は私の頭の中に最も奇妙で悪夢のようなシナリオを生み出します。その瞬間はそれらは重大なもののように思えますが、振り返ってみると、それは「月明かりの下、松の木でツグミが口笛を吹いたらどうなるか」のようなものであることがよくあります。 他のタスクに集中できなくなる 時々、タスクを次のステータスに移動して何か新しいことを始めた後でも、それらのテスト ケースについての考えが頭から離れず、新しいタスクに集中できなくなることがあります。そのような場合、不安な Checker-Bug をオフにすることが難しい場合があります。 では、このバグをどう活用して有利に働かせ、バグが蔓延しないようにするにはどうすればいいのでしょうか? まず第一に 欠点について書いていたときに頭に浮かんだのは、マントラのように繰り返している 「徹底的なテストは神話だ。バグは常に存在する」というものです。 どれだけ徹底しても、あらゆるアクションとシナリオの組み合わせを予測することは不可能であり、つまり、ユーザーより先にすべてのバグを見つけることはできません。 特に、常に変化する世界では。 これはただ受け入れて先に進むしかないのです。 私がこれを受け入れるのに役立ったのは、製品バグの根本原因を分析することでした。これは、 と呼ばれることもあります。これは、関係者全員と話し合い、バグがどのように発生したか、そして再発を防ぐために何ができるかを考え出す作業です。 事後検証 そして、重大な欠陥は単純な見落としによって引き起こされることが多いことを学びました。たとえば、空の値を持つテスト ケースがチェックされなかったために、特定の製品がストアに表示されなかったり、ローカリゼーションが失敗して画面タイトルが空白になったりすることがありました。 しかし、事態は悪化しませんでした。作業は続行され、私たちは全員、以前に失敗した部分にさらに注意を払いました。 2つ目は 厄介な Checker-Bug を静めるために、私はテスト設計手法 (決定表と状態遷移図) を実装していました。 これらは、アプリケーション ロジックを視覚化し、考えられるテスト ケースをより明確に把握するのに役立ちます。つまり、テスト ケースを見落とすことがないように自信を持つことができます。 復習しておくと、意思決定表とは、列と行に条件とルールを入力する表です。すべての条件とルールのオプションを指定したら、予想される結果を入力します。 状態遷移図は、さまざまな状態を持つオブジェクトがあり、そのオブジェクトが特定の条件に基づいて状態を変更する場合に使用されます。常に適切な図とは限りませんが、会計サービスの開発に取り組んだときには、非常に役立ちました。これらの図のオブジェクトは、レポート、アプリケーション、デジタル署名などでした。 三番目、 その厄介な内なるバグに対する解決策は、実は私自身が見つけました。それは、テストケースのピアレビューと、失敗した後のコミュニケーションであることがわかりました。 シンプルで、おそらく明白ですが、うまく機能します。 そして4番目 脳を落ち着かせる方法は、効果とリスクを評価することでした。内なる虫が耳元で「テストケースをもう少しチェックして」とささやき始めたら、チームリーダーを思い出して次の 3 つの質問をしました。 どのくらい時間がかかりますか？ メリットは何でしょうか? これによって何か重要なことが発見される可能性はどれくらいでしょうか? はい、言語設定を変えたり、暗いテーマや明るいテーマを変えたり、フォント サイズを大きくしたりして、複数の OS バージョンでテストすることが理にかなっている場合もありますが、多くの場合、これらのチェックは不要です。 このようなテストの実行中にバグが見つかったと想像してください。そのバグの優先度はどの程度でしょうか? 再現するための具体的な手順により、クラッシュであっても優先度が低くなる可能性があります。 これらのチェックにはどのくらいの時間がかかりますか? 5 分から 10 分です。大した時間ではありませんが、その時間さえも常に確保できるとは限りません。その時間があれば、平均的なサイズのタスクの説明を読むことができます。 まとめます（そう願っています） 他のツールと同様に、あなたの内なる悩みは、恵みにも呪いにもなり得ます。何かを効果的に使用する方法を学ぶには、多くの場合、経験と時間が必要です。この記事が、あなたの内なる批判を早く抑え、神経を落ち着かせ、自信を高めるのに役立つことを願っています。 私はただあなたをサポートしたいだけです。そして、疲れ果てるまで戦うのではなく、この小さな獣と協力して味方にする方法を見つけるかもしれません。
