第184回： 「ソフトウェアテストしようぜ」1 新連載のテーマ
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、休憩回ということで「転職」の話題でした。
1番大切なことは、RCCのキャリアコンサルタントが仰った、「ご自身が、転職に際して一番大切にしたいことを考えて書き出してください」をすることだと思います。
『自分のことだから分かっている』と思う人が多いと思います。でも、私はわかっていませんでしたし、多数の転職者のコンサルティングをおこなってきたRCCのコンサルタントも「なんとなく、周りの人の行動と合わせる人が多いのよね」って言っていました。（口調が女性なのは、私を担当してくださったコンサルタントは、女性だったからです）
2番目に大切なことは、「職務経歴書を年に一度くらい見直して更新する」です。頻度的には、3年に一度でもよいけれど、定期的に、例えば年明けに、見直してみる方が更新することを忘れにくいですし、やったことを憶い出しやすいので、良いと思います。
さて、今回から新連載のスタートです。新連載のマガジンのタイトルは、「ソフトウェアテストしようぜ」にしました。そして今回は、なぜこのテーマにしたのか、連載で何を書くのかについてです。
≡ テーマ選定の理由
改善提案書にあるような見出しになってしまいました。
前回をお読みの方はご存じなので繰り返しになってしまいますが、ここ一年、
仕事ですが、まず、バグが出ていないので、自分の専門のテスト技術の出番がありません。どのプロジェクトもテスト期間中に見つかるバグは数件ですし、リリース後の本番障害なんて、全プロジェクトで年間あるかないかです。
という状況が続いています。転職をした当初は、「そんなことは、あるわけがない。きっと“しょぼいテスト”をしていてバグがでていないだけでしょう？」って思っていました。それで、テストケースを見せていただき、「やっぱりね」と思いました。
私は、一応テストの専門家です。
テスト技法も大好きですし、“NGT/VSTeP”や、“ゆもつよメソッド”といったテストの進め方も勉強してきました。CFD法についてはnoteにマガジンを書いてしまうくらい好きです。
テストの専門家からみたら、たしかに穴のあるテストケースでした。でも、大切なことは、前回の引用の後半にある「リリース後の本番障害なんて、全プロジェクトで年間あるかないか」という事実です。
テストがいくらしょぼくたって、そもそもバグが出ていないソフトウェアを作れているのなら問題ないじゃない！？ ということです。
品質コストの外部失敗コスト（Fコスト）が限りなくゼロのときに、評価コスト（Aコスト： appraisal cost）を増やすことが適切な対応となるか？という話です。
バグゼロよりも品質向上に貢献する施策があるのではないか？と思いました。例えば、UI/UXをはじめとする非機能要件の品質向上や開発スピードのアップ等々。
「顧客先で発生しないバグを見つけるテストを増やすことで、そのソフトウェアの価値は上がるのか？」そんなことを考え続けた一年でした。
で、結論として、【重要な問題がないことを網羅的に確認するテスト】のみを追加する方向で検討中です。その一つとして以前ツイートしたテスト観点の整理をしたりしています。
以上の経緯から、今の会社では、私がテストをする機会はありません。テストが大好きなのにテストができない一年でした。
でも、そんなにつらくはありません。何故ならテストは仕事でなくてもできるからです。しかも、私はテストを実行することも好きだけど、テストを作ることの方がもっと好きだから。
この楽しさを伝えたい。
【よし、新連載はこれでいくか】となりました。
≡ 何を書くのか
私は、普段の生活で何かを見たり触れたりすると、つい、「自分ならこんなことをテストする」と妄想してしまうので、それを書きます。この妄想は、“気がついたらテストを頭に浮かべて遊んでいた”という感じのものです。
普通の人から見たら“頭のおかしい人”かもしれないけど、テスターなら分かってくれると思います。
具体的には、毎回、一つの「お題」について「こんなテストをしちゃうぞ」というのを書きます。
要は「テストの素振り」です。故 清水吉男さんも「いつも電車の中で見つけた何かについて、『なんの要求に対してそれが存在しているか？』を考える“要求獲得の素振り”をしている」とおっしゃっていました。
≡ テスターなら……
もし、あなたがテスターなら、見つけたバグをプログラマーにお知らせしたときに、「なんでこんなことしようと思ったワケ？」と言われたことがあると思います。（プログラマーなら言った記憶があるかもしれません）
こちらの図はほとんどの人が見たことがあると思います。「ハインリッヒの法則」という名前がついています。以下はWikipediaからの引用です。
ハインリッヒの法則（ハインリッヒのほうそく、Heinrich's law）は、労働災害における経験則の一つである。1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常（ヒヤリ・ハット）が存在するというもの。「ハインリッヒの災害トライアングル定理」または「傷害四角錐」とも呼ばれる。
以下は、同じフレームワークでバグとテストの関係を図にしたものです。
「なんでこんなことしようと思ったワケ？」と言われた1件のバグの背後には29件の実行済みのテストがあり、さらに、その背景には300件の試したいことが存在するという図です。
もっと打率が良いテスターの方もいらっしゃると思います。1 : 29 : 300は、あくまでも、私の感覚的な数値です。
つまり、何が言いたいかというと、「なんでこんなことしようと思ったワケ？」の「こんなこと」は、330個のネタ（テストしたいこと）のうちのひとつということです。
下手な鉄砲も数撃ちゃ当たるそこで、本連載ではテストすらされなかった300個の試したかったことの「供養」をします。
つまり、「テストするぞ」ってなったときに、私が何を考えているか、その思考を紐解くことになります。
テスト技法もでてくると思いますが、テスト対象をどう理解するかの話の方が多くなるような気もします。
そうそう、「なんでこんなことしようと思ったワケ？」と言われたときに、「怒られた！」って感じる人もいるようです。
私は、単にすげーなと言われたと思って「いえいえ、そんなことは」なんて謙遜しちゃうお気楽さんなんだけど、『褒めてねーよ』って思われているかもしれません。😅
ということで、繊細な心をお持ちの方に対しては使わない方が良い言葉かも。
≡ 次回のお題
次回のお題はこちらです。
これはなにかというと、我が家の冷蔵庫です。もうちょっとズームインして正確にいうと、冷蔵庫の扉を開け閉めすると、冷蔵庫内の灯りをオン/オフするためのスイッチです。
次回は、こちらのテストについて書きます。「自分ならこんなテストをする」って考えてから読んだ方が面白いんじゃないかな？ と思うので、毎回、このように、次回のお題をお知らせします。
実際に我が家にある物を使い、明示する仕様は最低限とします。ソースコードを持っているものはないので基本的にブラックボックステストとなりますが、勝手にソースコード（やメカニズム）を想定してそれに対するテストを作ることはあるでしょう。
なお、今回は「扉を閉めるとスイッチが押されることによって、冷蔵庫内の灯りをオフにする」だけが仕様書（マニュアル）に書いてあったとします。
もちろん過去の経験から『冷蔵庫を開けっ放しにすると庫内の灯りは消える』ことを思い出すことは大切です。常識（暗黙の仕様）は仕様書には書かれませんからね。
それからこのスイッチは部品原価数十円だと思います。したがって、ソフトウェアはもちろんのこと、電子回路すらないと思います。まあ、そこはソフトウェアがあると妄想してください。
（……最近の冷蔵庫は扉を閉めるタイミングでなかの写真を撮ってそれを外出先でスマホから呼び出せるようなので、ひょっとしたら庫内の照明もソフトウェアで制御しているかもしれませんけど、我が家の冷蔵庫にはそんな便利な機能（魅力的品質）は付いていません）
逆に言いますと、ハードウェアの評価は本連載では対象外とします。例えば、「扉を10万回開け閉めしたときの耐久性」や、「庫内が冷えすぎてスイッチが結氷して動かなくなることがないこと」などの確認はハードウェアのテストではすると思いますが、本連載では考えないことにします。ソフトウェアテストの実務でもハードウェアの信頼性は十分に高いという前提を置いたテストを作ることが多いですし。
さて、『自分なら、こんなテストをする』って考えるだけじゃなくて、自由にツイートしたり、ブログに書いたりしてもらって構いません。（いつのタイミングでもOKです）
特にnoteを読むと「私ならこんなテストもしたいと思うぞ」ってアイデアが浮かんでくると思うんですよね。
そういう“他にどんなテストが考えられるか”について知りたいですので、このnoteへのコメントや自身のブログ等に書いていただけるとうれしいです。
あと、実際のテストには時間やテスターのリソースの制約（仕事の前提条件）がありますので、思いついたテストを全て実施するわけではありません。そこは、重要なテストから順番に頑張るのではないでしょうか。（先のピラミッドも「330個のテストを思いついても、実施するのは30個」という図でした）
≡ おわりに
今回は、新連載で何を書くかの話でした。
次回は、冷蔵庫のアレ（上の写真のブツ）のテストがテーマです。
名前がないと不便なので、「庫内スイッチ」って呼ぶことにします。メーカーによって呼び方は違うみたいです。
ところで、クローゼットの照明は、センサーライトが多いようです。何故似た機能なのにメカニズムが違うのかと考えるとテストのヒントになるかもしれません。
