『 AI が来てもソフトウェアテストをナメると不具合に刺される。』

こんにちは！ホワイトマーリン・スタッフの德永です！

本日のブログは、以前にも この場で " 講義 " をしていただいた、ホワイトマーリン『就労継続支援A型』を利用されている " IT エンジニア " の方に執筆をお願いしました。

『就労継続支援A型』とは、障害をお持ちの方たちがその特性を活かしつつ働くこと へのサポートを行う事業です。

ガルヒでは IT に特化した活動に力を入れており、利用者の方々の多くがパソコンでの作業をされています。その中でも この方は、システム開発にむけたコーディング（ ≒プログラミング ）をゴリゴリ進めておられるエキスパートです。

それでは よろしくお願いいたします！

どうも、お疲れ様です。

最近は AI のコーディング支援環境も整ってきて、コードを書くのがずいぶん楽になりましたね。

ただ、「AI がコードを書いてくれるなら、テストも適当でいいんじゃない？」と思ってしまうと、後々 本番環境の不具合で痛い目を見ることになります（なりました）。

今回は、AI 時代になってもなぜ人間がテストを考える必要があるのか、少し整理してみました。

1. ソフトウェアテストで何が判明してほしいか

AI が来ようが、テストで見つけたい情報は昔から変わりません。大きく分けて以下の３つです。

・Never（あってはならないこと）：  客先の環境を壊す、個人情報が漏洩するなど。

・Must（できなければならないこと）：  要件に定義された機能。電卓アプリなら、正しく計算ができること。

・Want（できたらいいこと）：  見た目の分かりやすさや、使い勝手の良さなど。

テストとは、これらが満たされているかをソースコードや実際の動作から割り出す作業です。

2. ホワイトボックステストとブラックボックステスト

テスト手法には、大きく分けて２種類あります。

・ホワイトボックステスト： ソースコードの構造が見える状態で行うテスト。

・ブラックボックステスト： ソースコードが見えない状況で、入力を放り込んで結果を見るテスト。

AI によるテストは、ホワイトボックステストに関しては人間を超えうると思うので、任せてもいい領域です。

一方で、ブラックボックステストに関しては（自動化できないこともないですが）、まだ人間がやったほうが問題に気付きやすいです。例えば Web のレスポンシブ対応（サイトを見る端末のサイズに合わせて表示が最適化されること、モニターでは大きく・スマホではスリムに、など）の崩れなどは、目で見たほうが AI より普通に早くて確実です。

そういうわけで、今の環境でもまだ人間がテスト技法を身に着ける必要があります。私はコードを書く側なので、今回はホワイトボックス的なアプローチを中心にお話しします。

3. テストの前提

例えば、パスワード入力枠 の入力値検証を行うとします。仕様は「16文字以上72文字以下を受け付ける」です。

さて、ここで問題です。「全ての」ケースをテストする場合、どのくらいの組み合わせになるでしょうか。

答えは、無限大です。文字数はアルファベットと数字で最低62文字ありますし、上限は「72文字以下」とあっても、ユーザーは100文字だろうが入力してきます。愚直にすべてのテストをやろうとすると、どれだけ時間があっても足りません。

そのため、星の数ほどある状態から必要なテストケースを絞り込み、一つのテストケースから得られる情報を大きくしてやる必要があります。

例えば、「1122334455667788」という文字列と「0022334455667799」でテストしても、どちらも16文字なのでコード上は同じパスを通ります。得られる情報は、この２つで変わりません。

ですが、「11223344」ならどうでしょうか。これは先ほどとは違って、文字数でバリデーションに弾かれるパスを通ります。これでちゃんと弾かれることを確認できたならば、文字数で弾く処理は機能していることが分かります（少なくとも、その可能性が高いです）。

「テストケースの選び方で、テストの数を減らして、有効なテストの割合を上げる」というのが、本質的な考え方になります。

4. 一例：境界値テスト

先ほどの「文字数」の話の続きです。「16文字〜72文字」を受け付ける仕様ですね。

このとき、「8文字」と「12文字」のテストでは、いずれも「16文字」の境界より下なので、両方やる意味はあまりありません。「75文字」と「100文字」を両方テストケースとして選ぶのも同様です。

（※現環境だと bcrypt が72文字しか見ないという問題はありますが、これは余談なので今回は割愛します。）

一方で、「15文字」と「16文字」、「72文字」と「73文字」のテストで得られる情報は大きいです。

仕様の裏を返せば「15文字以下が弾かれる」わけですから、その限界値の「15文字」でテストするのが一番有用なわけです。「16文字」「72文字」「73文字」に関しても同様です。

これで「0文字から100文字」の101パターンから、４パターンに絞り込むことができました。　ヤッタネ！

5. まとめ

AI がどれだけ台頭してきても、結局のところ、ソフトウェアの品質を担保できるのはまだ人間だけです。

先に挙げた例はあくまで一例ですが、「人間がやる」ソフトウェアテストは漫然と行うものではないことはご理解いただけたかと思います。

一つ一つのテストに、意味を持たせましょう。

可能であれば、一つ一つのテストがコード上のどの部分をテストするかを意識して行ってみてほしいです。

6. なんでこれ書いたの？

管理部門：マネージャーが「動作確認」の指示を出したとき、バグがほとんど上がってこないためです。

動作確認のフェーズでは、むしろバグは上げてほしいです。本番で不具合が出るよりずっとマシですからね！

以上です。

[参考書籍]

ソフトウェアテストの教科書

https://www.sbcr.jp/product/4815608750/

ガルヒ就労支援サービスではパソコン初心者の方からでも気軽に見学・体験を行っています。　

ご興味がある方は是非お問い合わせください！！

皆様のご連絡お待ちしております！

【事業所名】ガルヒ就労支援サービス ホワイトマーリン

【所在地】〒 880-0904 宮崎県宮崎市中村東２丁目１番 36号２F

【電話番号】( 0985 ) 33-9208

【F A X】( 0985 ) 33-9209

【営業時間】月~金曜日 ( 10:00 ~ 18:00 )　土曜日 ( 12:00 ~ 18:00 ) ※祝日を除く

【事業内容】就労移行支援・就労継続支援A型