はじめに
こんな記事やStorybookのガチ批評記事を書いてますが、AIを毛嫌いしているわけではありません。
ただ、AIはまだ全知全能ではなく、得意不得意があります。
品質保証の中には、まだAIの不得意な領分が存在している、ということを知っていただければ幸いです。
AIにテストを一任できない、たった１つの理由
テストは大きく２つに分けられる
テストの分け方として「機能テストと非機能テスト」「ブラックボックステストとホワイトボックステスト」などがありますが、今回の主題は「Checking/Testing」です。
「Checking/Testing」とは何か
かなり概念や感覚的な話となってしまいますが、ご容赦ください。
Checking≒確認
こちらは「正常に動作することを確認する」ことが目的のテストです。
言い換えれば「想定した通りに操作すれば、想定した結果が得られること」を確認します。
つまり、コードや仕様書に書いてある操作をします。
目的は「1000件の確認をして1000件がOKであること」です。
通常通りの使用であれば問題がないから品質が良い、と言いたいテストです。
Testing≒試験
一方、こちらは「問題が起きないことを確認する」ことが目的のテストです。
「想定外の操作が行われても、問題が発生しないこと」を確認します。
つまり、コードや仕様書の想定外、書いてないことをします。
目的は「1000件の試験をして1件の未知の問題を検知すること」です。
そして、検知できた未知の問題を直すことで品質が良くなった、と言いたいテストです。
AIとTestingは相性が致命的に悪い
すでに多くの方が予想されるかもしれませんが、
AIとは、過去のデータや既知のパターンに基いて、確率が高い事象を予測するツールです。
そのため、未知の事象を検出しようとするTestingは、AIの特性と逆のものです。
テストには、CheckingとTestingの両方が含まれます。
AIにすべてを任せるとCheckingばかりとなり、Testingの性質が薄れ、重大な不具合を見逃す可能性が高まります。
すべてをAI任せにせず、必ず人の手も入れるようにしましょう。
おわりに
現状、テストをすべてAIに任せることはできません。
しかし、いずれAIでもTestingの領域に強くなれると信じています。
何故ならば、QAや品質保証部門がTestingのテストを作れる理由は、
多くのテスト経験と遭遇してきた不具合たち、そしてそれを基とした直感を頼りにするからです。
AIの進化が目まぐるしい昨今。
来年にはこの記事が時代遅れになり、AIがTestingにおいても強力なツールとなることを期待しています。