早くも2月後半となりました…という書き始めが最近多くなりました.
ホントに時のたつの早い、早すぎる.
ブログを書く時間がなかなか取れません、というよりももっと気軽に書けば良いのでは？と最近気づかされました.
文章を書くのは楽しい. 空き時間をつかって少しずつ書いていきます.
ということで、最近思っていることを書いていきます.
Table of Contents
バグのないソフトなどない
ソフトウェア開発を生業としている以上、バグとの付き合いは永遠と覚悟してます.
そして、いくらテストを行ってもバグのないソフトはない、とも思ってます.
これが長年、この業界にいて出た結論のひとつです.
10年近く前に開発されたソースコードをベースに新たなモデルを開発していますが、相当枯れたソフトウェアであるはずなのですが、それでもそんなコードでも予想だにしない箇所にバグが潜んでいるものです.
そう、そうなんです. バグのないソフトなどどこにもないのです.
バグは無くならない、無いように見えるだけ
バグがあってもしょうがないよ、と開き直るつもりは毛頭ありません.
バグは少なくすることはできます. そのつもりで開発を行っています.
繰り返しとなりますが、バグを完全にゼロにすることはできません. まぁ、見かけ上、バグ票をゼロにすることはありますが、潜在的にあるバグを全部無くすことは不可能です.
よく冷静になって考えれば、例えば製品寿命が約５年のスマートフォン、それが約１万台売れたと仮定して、１万人のユーザーが５年間、いろんな使い方、いろんなアプリを入れて、いろんな場所、シチュエーションで利用するケースをすべてテストする、それは
不可能
です.
製品の開発は限られた人数で限られた期限の中で行われます.
当然、テストする人数・期間も限られます.
もちろん自動化できるテスト項目もありますが、先に書いたようなすべてのユーザーの利用状況を網羅することは不可能です.
製品が出荷される時点では、限られたテストの期間で出たバグが改修されただけで、そこから未来永劫(まだ見つかっていない)バグが出ない、ということではありません.
ただ今そこにあるバグが無くなったように見える、だけ…だと思ってます.
限られたテスト期間、だからテスト設計が重要
何度も繰り返しとなりますけど、製品開発のテスト期間は限られています.
それに充てられる人数も限られます.
そして、開発の進捗が遅れると、
テスト期間が短縮される
ということがありがちです. 最近はそういうことは少なくなりましたが…
コードを書く進捗状況はコードという成果があるので、ある程度は見て取れます.
一方テストの進捗状況は実施したテスト項目数で評価されます…
しかしながら、そのテスト項目数ってホントに妥当なんでしょうか？
少なすぎる、あるいは無駄に多すぎないか？
そしてそれらのテスト項目はバグをあぶり出せる、刺さるテストなんでしょうか？
適切な内容で、過不足のない項目数のテスト項目を設計する、テスト設計が必要になります.
以前のソフトウェア・テストに対する印象は?
以前、ずーっと最前線でコードを書いてきたのですが、あるときテストに回る時期がありました.
そのときの感想は正直あまり良い気分ではありませんでした. 当時はテスト設計などソフトウェアテストについて何も知らず、テストなんざ新人に任せておけばいいや、なんてこと考えてましたから…
ソフトウェアテストの認識が変わった瞬間
すこし腐ってた私を見かねたのか、上司がソフトウェアテストの権威でソフトウェアテストの専門誌に記事を書いてらっしゃる堀明広さんにお話しをうかがう機会をもうけて頂きました.
こんな本があったのか!! というのが正直な感想です.
堀さんからテスト設計という概念を教えていただきました.
ソフトウェアテストに体系立てられた技術があったとは、恥ずかしながら初めて知り,そして、ソフトウェアテストとはクリエイティブなものであると認識を新たにいたしました..
堀さんから, この本を勧められました.
まずはこの本１冊でもよいから読んで、と勧められました.
テスト技法が初心者にもわかりやすく説明されてとても感動した記憶があります.
…ああ、ソフトウェアテストにこんな体系づけされた技法があるなんて…
あと,こちらの本も参考になるから,と紹介されたのがこちら
これらの本を購入したのが10年以上前なのですが, また改めて読みなおしたいと思います.
いずれにせよ, ソフトウェアテストはコードを描くのと同じくらいクリエイティブだというのを認識した経験です.
ソフトウェア開発に従事されている方々はぜひ一読ください.
いろいろソフトウェアテストについて、はたまたバグについて書きたいこと山ほどありますが、今回はここまで
では
