ぼくのかんがえたSoftware Test & Quality
はじめに
メリークリスマス。@numehaです。昨日はB'zのライブに行って来ました。品質は最高でしたw
Software Test ＆ Quality Advent Calendar 2011の25日目です。トリです。
本エントリーでは、B'zのライブがいかに品質が高いのか、ではなく、ぼくのかんがえたSoftware TestとQualityに関して、熱くるしい思いを皆にぶつけてみようと思います。温かいご意見お待ちしております。
私とテストと、時々、品質
私がテストの勉強を始めたのは2009年頃でした。それまでは「スパイク」のみで、テストなんてものはなく、ある程度動くコードだけでした。その時はそれで良かったんです。なぜならアイデアを形にし、それが有用であるのか検証することが目的だったからです。その動くコードに問題があっても誰も困りません。お客様は、新しいシステムのイメージが出来ればいいんです。品質なんて求めていませんでした。
が、しかし、それからプロダクトコードを書くようになり、テストが必須になりました。なぜテストが必須なのか？それは、そのプロダクトがお客様のビジネスに影響するものだったからです。問題があったらお客様が困ります。それが2009年です。
その時に初めて気がついたことがあります。
「お客様によって品質の定義が変わる」
ということです。今思えば当たり前の話ですが、当時の自分にとっては大きな気づきでした。
テストの目的って何だ
既にテストの分類については、多くのかたがエントリーされていますね。特に、元同僚の@ikasam_aのこちらのエントリーは凄く良いエントリーですので、是非皆様も読んでいただきたいと思います。（タイトルもパクらせていただきましたw）
皆様は何の目的でテストをしていますか？
テストという大きなカテゴリで議論をすると人によっては衝突してしまうことがよくあります。それは開発者テストの話なの？QAテストの話なの？まぁそんな感じです。
けど私は、テストの目的だけはもしかして同じなのでは？と思っています。
その目的とは、
「お客様に自信を持ってリリースすること」
です。
例えば、開発者テストは開発者が開発を円滑にするためのテストとよく言われますが、それは目先の目的であって新の目的は違うのかなと思います。もしも本当に「リリースすること」とは全く関係のないテストコードなのであれば、それは不要なテストであると考えています（言い過ぎかなw）。いくら、小さなメソッドの単体テストであろうともそれはリリースするためにやっているはずです。
リリースに関係のないコード（例えば、前述したような「スパイク」で開発したコード）に、テストは必要ないと思います。もしもこのようなケースでもテストをするのであれば、これこそ開発者のためのテストではないでしょうか。
だから私は、テスト設計を行うときにはお客様の事を一番に考えています。まずお客様とは、誰なのかはしっかりと決めることは原則です。それはエンドユーザなのかもしれないし、開発者なのかもしれません。
それを踏まえて、こういうことをお客様がやったらどうなるか、こういうときに問題はおきないのか徹底的に考えます。それが単体テストであろうが結合テストであろうが全てのテストに共通しています。
それを具体的なテストケースにして全てが通ったプロダクトには自信を持てると思います。お客様がどのように使っても問題なく動く！！そういう自信です。
そういう自信をもってリリースするために私たちはテストをするべきだと思います。
品質って何だ
皆様の品質の定義とは何でしょうか。どういうソフトウェアが品質が高いといえるのでしょうか。
バグが0件だ。カバレッジが100%だ。障害発生率がx%以下だ。。。
本当にこういう条件を満たしたら品質が高いのでしょうか。
残念なことに、私の身近でもこのような話を聞くことがあります。そして、それをリリースの完了基準にすることがあります。本当に残念です。
そんな完了基準になったらもう最悪です。開発メンバーがバグを0件にすることが目標になり目的になり、気がつくと本質的なことを見失ってしまいます。
バグは0件になったけど、うちらって何のために開発してたんだっけ？まぁそんな感じです。
また、品質保証（監査）部門がいる会社は、品質の解析に時間をかけ、解析レポートを要求され、本質的である品質を上げる時間を奪うことが多いように感じます。
お客様は品質の解析レポートなんて求めていません。
お客様がそのプロダクトを利用して、
「ビジネス価値を上げられるのか」
それだけだと思います。
例が悪いかもしれませんが、私は昨日のB'zのライブに行ってとても満足しました。音と映像のタイミング等、何度もテストして品質をあげていったことでしょう。
私はそのライブに17000円(8500円×2枚)を払いました。私にとってそれだけの価値があるからです。
「品質を決めるのはお客様」
なんです。
いくら、開発者が完璧なコードを書こうが、品質保証部門がテストをしようが、お客様が品質が悪いと思えば悪いのです。バグがあってもお客様がそのプロダクトでビジネス価値をあげられれば品質が高いと言えるでしょう。
プロダクトによってお客様も品質基準も変わってきます。そのプロダクトのDoneの定義を決めることが重要です。そうでなければ、過小品質や過剰品質を生むことになると思います。
小さく、早く、そして簡単に
さて、ここまでテストと品質について書いてきましたが、皆様これで品質が高いソフトウェアをリリースできるでしょうか。
う〜〜〜ん。。。難しいですよね。
こうやれば、間違いなく品質が高いソフトウェアをリリースできます、なんてそんな魔法みたいな方法なんてないのです。
ただ、私が最近特に意識していることがあります。
それは、
「小さく、早く、簡単にリリースする」
ということです。
小さく
これは、リリースする単位をできるだけ小さくするということです。
例えば、Webアプリケーションがリリース対象だとすると、提供する機能に優先度をつけて、全て完成してからリリースするのではなく、優先度順に最小単位でリリースするということです。もしも10の機能をリリースするときに、1週間毎に細かくリリースする場合と、2ヶ月に1度リリースする場合どちらがいいでしょうか。
もしもリリースが1度だけなのであれば、お客様がビジネス価値を上げられない可能性が高まります。私も経験があるのですが、お客様にリリースしたときにすぐにクレームになったり、そんな機能いらないからこの機能が欲しい、みたいなことがありました。
やっぱり人間なので、使ってみると想像と違っていたり欲がでることは当然だと思います。
もしも1週間毎にリリースされたものを利用していたとしたら、いきなり10の機能の評価でなく、1つの機能の評価になります。そうすると、クレームが小さい意見となり、開発予定だった機能が不要になりお客様にとって重要な機能の開発が増えるかもしれません。
それは、お客様から
「継続的なフィードバックを得ている」
からということになります。
継続的なフィードバックは、品質を高める手法です。前述した通りですが、いくら開発者が良いと思っていてもお客様の意見が品質に直結します。
もしも、お客様との間にフィードバックループを作れないのであれば、仮想的なお客様でもいいので利用してもらうことが重要です。
小さくリリースするためにリリース計画をするのも一つの技術であると私は考えています。
早く
これは、リリースを極限まで早くするということです。
早くできない理由は、前述したリリース単位が大きいのも1つでしょう。その他にもいくつかあると思いますが、手動テストが多いとリリースは遅くなります。
私の経験談ですが、QAテストのために派遣を雇い、膨大なテスト仕様書を書き、それを全て手動でテストをしていた時期がありました。テストを全て行うのに1ヶ月もかかりました。もちろん1回でテストが終わるはずもなく、テストが終わるまでに3ヶ月を要しました。
開発が完了してからQAテストをするという完全なWFってやつですw
その時の1番のミスは、膨大な手動テスト仕様を量産してしまったことです。その時は、後にこれが多大な負債になるとは考えていませんでした。それからというものこの手動テスト仕様は、類似製品にも利用されるようになり、ベースとなる仕様として位置づけられたのです。
このままでは、リリースが遅くなる一方です。そこで、私は徹底的な自動化への移行を推進しました。その仕様の約70%を自動化しました。この自動化への移行の作業の大変さは想像を絶していました。初期の開発中に自動化への努力を行なっていれば、このような苦労は少なかったと思います。
リリースを早くするには、開発の初期段階からテストの自動化環境を整え、手動テストはなくす努力をすることです。プロダクトの性質によっては完全に自動化することは難しいものもあります。これは逆転の発想で、設計時に自動テストができるように設計しておくことが重要です。もちろん理想論ですが。
簡単に
これは、「早く」と類似しているのですが、本番環境にリリースするまでに簡単に実現できていることです。
それは、テストだけでなく、ビルドとテストとデプロイを完全自動化することが最善の策です。要するにデプロイ・パイプラインを作り、ワンクリックでリリース可能な状態にするということです。
この辺の話は@ryuzeeさんの資料が素晴らしいので読んでみることをお勧めします。
私が取り組んでいるデプロイ・パイプラインは、テスト環境構築→モジュール単体テスト→モジュール結合テスト→ステージング環境にデプロイ→リリーステスト ってな具合です。
ここまで自動が進むと人的ミスがほとんどなくなります。手動が入ると、デプロイ1つにしても間違ったモジュールをデプロイしてしまった、なんてことは日常茶飯事です。そういう時間って無駄の何ものでも無いんですよね。そして、それが手動だとある特定の人しかできないということが多いです。その人に負担がかかってしまい、本当に良くない状態と言えるでしょう。
後回しにしがちなデプロイ・パイプラインは早期に実現しておくことがいいと思います。これは開発者にとってもお客様にとっても重要なことだと言えます。
終わりに
今回は、ソフトウェアテストと品質について、わたしの考えを経験談を踏まえてエントリーさせていただきました。
この手の考え方に正解はないと思います。ただ、それを強い信念を持ち突き進められるか、関連するメンバーが全員納得して進められているのか、それが重要です。
例えば、私が今回エントリーした内容を全て実現できていたとしても、関連するメンバーがYESと言わなければ会社や組織としてうまく機能しないでしょう。それを根気よく周りに浸透させることがまずは必要だと思いますし、私もそのような努力をしています。
開発者もお客様もHappyになれる仕組み作りを皆で目指しましょう！！
