現在、夏休みを楽しんでいます。
実家に帰って、中学校のクラス会に参加しました。
今週末はまた高校のクラス会があります。ブームですね。
今日は、プログラミングを独学されている方に役立つ本をご紹介します。
＜目次＞
なぜテスト？
最近、自分がつくるプログラムが肥大化していまして、バグも多くなってきました。
プログラミングを学校で習ったり、または会社で仕事として行っている方は、バグを取り除くためのテストの手法についてはある程度ご存じだと思います。
私の場合には、プログラミングは独学がほとんどなので、テストについての知識が抜け落ちていました。
というわけで、ここ数ヶ月は、テストの方法について少し学んできたので、その中の１冊です。
この本を選んだ理由
この本にひかれた理由は、「マインドマップ」を用いているから。
「マインドマップ」をあえて、ソフトウェア開発の現場で使っている方は、おそらく発想に柔軟性があったり新しいことを取り入れようとされている方だと思いました。
そんなわけで、そのような人の本を読みたいと思い、書店で手に取って内容を確認する前にアマゾンで購入。
期待以上の内容でした。
この本で紹介されている手法は、マインドマップだけではありません。
「マンダラート」や「三色ペン」といった比較的有名な仕事ツールも紹介されています。
「マンダラート」については、実は去年の今頃、マクロで作成したソフトがありなじみがあります。
「三色ペン」は、この本を読んでから購入してみて、その効果を楽しんでいるところです。
本書の内容
我流でマインドマップでメモをとっていますが、自分にあったノートの取り方だと思っています。
この本では、「ソフトウェアのテスト」がなぜ必要で、そのための具体的な考え方が書かれています。
具体例もわかりやすいので、私のようなテスト初心者でもおおざっぱな概要がつかめて、さらに実践に生かせるように思います。
実際に役立ったこと
１．テストをする視点として、お客様目線を持てたこと
私の場合、どうしても自分のやり方を押しつけがちでしたが、使っていただいている「お客様：ユーザーの皆様」の視点に気がついたことが大きな成果。
ユーザビリティテストと呼ばれています。
あと、テストの仕様を決めるときの視点として非常に有効だと思います。
テストを闇雲にするのではなく、「テストの仕様を決定する」という考え方自体も役立ちました。
言われてみたら当たり前かもしれませんが、我流でやると、どうしてもやりやすい点や、自分が知っているやり方でしか、テストしませんからね。大切ですね。
２．ストレステストをしたこと
現在、とあるソフトを作っていますが、このソフトの対象となる「ボリューム」を想定して、そのストレスに耐えうるのかどうかをテストしています。
開発段階では、ここまではつかわないでしょ？という「最大になるボリューム」を想定していました。
その後、試運転では、最大になるボリュームよりも小さな値で動かしていましたので、この最大値を超える値で作動させたときの動作確認ができていませんでした。
今回、ストレステストという概念を取り入れたので、最大ボリュームを超えたときのエラー処理やメッセージ文を工夫することができました。
よかった。
その他、テストの工程の組み方など、おおざっぱな概念が上手に説明されている本だと思います。
少しずつ、不具合をなくしていきます。