はじめに
この記事は、技術系ブログや書籍などに書かれているプログラミングの「アンチパターン」を読んだとき、わたし（テスター）が、どのようなことを考えているのか紹介したものです。
もし「アンチパターン」で実装されていたら
わたしはよく「過去の不具合を使って（同じような）不具合が起きないかを確認する」ということをするのですが、この「過去の不具合」を「アンチパターン」に置き換えて、テスト対象のソフトウェアが、もし「アンチパターン」で実装されていたら
- どのようなこと（ミス、不具合）が起きそうか
- どのようなテストをやってみたいか
を考えます。この２つが対になるように考えてもいいし、テストが思いつかないときは「こんなことが起きそう」だけでもOKです。要はより多くの「起こりそうな嫌なこと」を描くトレーニングです。
題材さえあればいつでもどこでもできます。一人でもできますが、何人かで集まってやると自分では思いつかなかったこと（他人の思考）を、自分のものとして頭の中に取り込めるのでお得です。時間を制限してやると瞬発力がつきます。なお、わたしたちのチームは（特別に集まることはなく）普段からこのようなことを話しています。
今回は、伊藤 淳一さんの こちらの記事 を題材にしてやってみたいと思います。サンプルコードや解説がとても分かりやすい！テスターのみなさんにも、ぜひ読んでもらいたい記事です。
なお、実際に開発してる製品を絡めた形では書けないので、架空のシステムを想定した、やんわりとした内容になっています。
主要な変数が全部連番、かつあらゆる変数がグローバルなシステム
どのようなこと（ミス、不具合）が起きそうか
- プログラマーが打ち間違いをしそう*1
- コードを見ても間違っていることに気がつかない
- 実装に時間がかかるので、十分なテストができないかもしれない
- 指定するテーブルやカラムを間違うことで、お客さまがやりたいことと無関係なデータを表示、変更、削除してしまう
- 仮にテスト対象が電子カルテシステムだった場合
- 別の患者のカルテで治療計画を立ててしまう
- 患者の体位と向きの表示を間違えたまま開腹手術してしまう
- ループ用の変数もグローバル変数で宣言されているのか……
- データは取得できても、中途半端に表示することがあるかもしれない
- 件数は合っていても、前回のデータを残したまま表示することがあるかもしれない（初期化が中途半端）
- 主要なテーブルやカラムについては目に触れることも多いし、みんなが気にして確認するけど、そうではないものは確認が手薄になりそう
どのようなテストをやってみたいか
- この実装だと間違える要素がありすぎるので「間違っているものを探す」というよりは「正しいものを探す」という気持ちでテストしたい
- 単にデータが取得できた、変更できた、削除できただけでなく、データの中身まで確認したい
- 全テーブル、全カラム、全てだ！
- テストデータは適当な文字列の羅列ではなく、テーブルごとに意味のある内容にしたい
- テストデータを見ただけで「どのテーブルのどのカラムのデータ」が分かるものを用意したい（テスト結果を見たときに、指定先の間違いに気づきやすい）
- 指定するインデックスも間違うかもしれない。応答速度（検索、ソートなど）も気にしたい
- とすると、テストデータの量も調整しながらテストしたい
- ループ用の変数もグローバル変数で宣言されているので「件数」を気にしたい
カンマ区切りで複数のコード値を格納しているテーブル
さっきのもすごいけど、これもすごいな（こういう実装を思いつくのがすごい）*2
どのようなこと（ミス、不具合）が起きそうか
- マシンスペックが良すぎると、案外サクッと動いてしまうかもしれない
- 性能問題に気づけないのが問題
- 売上げテーブルの商品コードカラムに、商品マスタに存在しない商品コードが登録できてしまうかもしれない（外部キー制約をつけられそうにないから）
- カンマ区切りで複数のコード値を格納しているテーブルは、この売上げテーブルだけではないかもしれない
- データの整合性に関して何もかもが怪しく思えてくる
どのようなテストをやってみたいか
- プログラマーの開発PCより遅いマシンスペックでテストする
- システムで推奨してるマシンスペックより劣るもので動かすと、早いうちに問題に気づきやすい
- たくさんの商品を１回で購入するような操作をしてみたい（売上げテーブルの商品コードカラムを溢れさせたい）
- 商品を購入した後に、商品マスタのマスタデータを削除してみたい
- 商品マスタの商品コード自体にカンマを入れてみたい
- 商品名にもカンマを入れておきたい（ITEM_NAMEからコードを逆生成することがあるかもしれないので、念のため）
おわりに
テストの定義はいろいろありますが、わたしが一番好きなのは、マイヤーズの「テストとは、エラーを見つけるつもりでプログラムを実行する過程である」というものです。この「エラーを見つけるつもりで」という行為は、より具体的な「エラー」を頭の中で描けないと難しいと思っています。絵本『ウォーリーをさがせ！』を想像してみてください。ウォーリーを知らないと探すことはできませんよね。ウォーリーを見つけるための手がかり（どんな顔をしていて、黒縁メガネをかけていて、ひょろっと痩せていて、赤と白のしましまの長袖Tシャツを着ていて、赤いボンボンのついた帽子をかぶっていて…）を知っているから探せるのです。
今回この記事で紹介したのは、より多くの「起こりそうな嫌なこと」を描くためのトレーニングの一例になります。「起こりそうな嫌なこと」は「エラーを見つけるための手がかり」の１つです。いつでもどこでも「起こりそうな嫌なこと」を描いてしまう癖がつくと、思考のバリエーションがどんどん増えていき、ソフトウェア開発の各場面で活かせるのではないかと思っています。実際、わたしが普段やっている Testing はこういった癖（トレーニング）で習得した要素が含まれています。きっと明日のテストでは、入力項目に思わず「カンマ」を入れてしまうと思います。
- 作者: J.マイヤーズ,M.トーマス,T.バジェット,C.サンドラー,Glenford J. Myers,Todd M. Thomas,Tom Badgett,Corey Sandler,長尾真,松尾正信
- 出版社/メーカー: 近代科学社
- 発売日: 2006/08/01
- メディア: 単行本
- 購入: 7人 クリック: 267回
- この商品を含むブログ (47件) を見る
伊藤 淳一さんのチェリー本も載せておきます
プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)
- 作者: 伊藤淳一
- 出版社/メーカー: 技術評論社
- 発売日: 2017/11/25
- メディア: 大型本
- この商品を含むブログを見る
