テスト界の第一人者、高橋寿一さんに実践的、かつ効率的な開発者テストに関してご解説いただくこのコラム。最終回である今回は、ウォーターフォールモデルからアジャイル開発へシフトするとき、テストはどう変化していくのかについて。さぁ、少々辛口（！）な高橋寿一さんの解説を読み進めていきましょう。
この記事でわかること
- 2週間で収まる単体テストの自動化を勧める、その理由
- システムテストより、単体テストを増やすことのメリット
- なぜ「単体テストのプログラムを書くスキル」を習得するといいのか
情報工学博士。1964 年東京生まれ。フロリダ工科大学大学院にてCem Kaner 博士（探索的テスト手法考案者）、James Whittaker 博士（『How Google Tests Software』著者）にソフトウェア品質の指導を受けたあと、広島市立大学にてソフトウェア品質研究により博士号取得。Microsoft シアトル本社・SAP ジャパンでソフトウェアテスト業務に従事、ソニー（株）ソフトウェア品質担当部長を経て、株式会社AGEST 執行役員。
昨今、アジャイル開発に（なんちゃってアジャイルも含め）皆さんシフトしているのではないでしょうか。それに従い、アジャイル開発のテストの重要性も高まっていると思います。ただし、「アジャイル開発においてのテスト」と聞くと、漠然としたイメージさえも浮かばない方が多いのでは？
ウォーターフォールモデルでは、最終工程にシステムテスト（という名の大変面倒な作業）を取る時間が多くありました。では、アジャイルではどうでしょうか。2週間のイテレーションのあとにシステムテストをさらに2週間取ります！なんて言ったら、その品質担当者は……。
チームワークを重視する「スクラム」という手法で品質保証する場合は、基本2週間や4週間ほどの短いイテレーション内でテストを終わらせなければならないのです。
今まで数ヶ月かけて要求仕様からシステムテストまでしてきた活動を「ぎゅ～」っと絞らなければなりません。テスト手法というものがいくつあるのかは知りませんが、時間が長くかかるテスト手法は今後淘汰されるのではないでしょうか。
そういう意味で次の２つのテストは重要な活動に。
- 要求仕様のテスト
- ソースコードのテスト
例えば、ソースコードの品質担保をするために2週間で収まる単体テストの自動化はおすすめです。要求仕様の抜けや漏れをなくすことも、どのイテレーションにおいても重要な品質保証活動になります。
そして、2週間というより、毎日完了するような単体テストを目指すのも良い考えです。単体テストでソースコードの品質を担保することは短い時間で可能ですが、膨大なマニュアルで行うシステムテストは１つのイテレーションでは終了しないため、NGです。
デイリーでテストが完了するようなテスト手法はアジャイルに向いています。逆に言えば、毎日定量的な品質が示せないような古いテスト手法、例えば膨大な数のシナリオテストや組み合わせテストは、アジャイル時代には淘汰されるのではないでしょうか。
テスト費用の使い方の変化を紐解くことで、今身につけたいスキルがわかる
初回で解説したテスト費用ですが、アジャイルであってもテストにかかる費用構成はあまり変わらないと思います。
アジャイルになって変わるのは、テスト費用の使い方です。例えばウォーターフォールモデルでは、下図のようにシステムテストでテスト全体の費用を70%使っていて、単体テストでは30%しか使っていないような時代でした。
それがアジャイルでは、以下のようにほとんどのテスト活動が単体テストになるかもしれません。
このように変化することで、シフトレフト効果でバグの総数も減っていきます。バグ１件あたりの修正費用も減っていきます。これは良いことずくめですね！しかし、１つだけ問題が起こるかもしれません。それは、今までシステムテストに従事していた方たちが、「単体テストのプログラムを書くスキル」を身につけるなどの必要が出てくるということです。
実は日本のソフトウェアテストの方法は、アメリカでの方法と違う箇所が多く、不思議なやり方だったりします。システムテストは協力会社に任せればいいや、コードを書けない人が担当でしょ。のような、風潮があると私は思っています。
一方、多くのアメリカの企業では、テスト担当者はコンピューターサイエンスの大卒を応募基準にしています（ソフトウェアを開発者と一緒に作る人なのだから、当然ですよね！）。
しかし、日本のテスト部門においてコンピューターサイエンスの大卒を応募基準においている会社は稀です。システムテスト中心だったウォーターフォールモデルからアジャイル時代になれば、多くのシステムテストに従事していた方は「単体テストのプログラムを書くスキル」を身につけるなどの必要が出てくるのではないでしょうか。
じゃあ一体どうすれば…と思われた方、心配しないでください。今後の業務に役立つスキルを獲得する「リスキリング」という言葉を耳にしたことはありますか。アジャイル時代に合わせるためのテスト担当者のリスキリングは、私は実は容易だと考えています。
なぜなら、例えアジャイルのテストが単体テスト中心の世界に移ったとしても、テスト技術は残るため、テストエンジニアはただ単に初歩的なプログラミングを覚えるだけでリスキリング完了です！開発者になるためのプログラミング学習は大変な努力を要するものですが、比較的短い学習で単体テストは書けるようになるものだと私は思っています。
・・・
全4回の連載「ソフトウェア品質を高めるために知りたい開発者テストの最前線」は、いかがでしたか。バグが出てから潰すのではなく、バグが出ないようにするにはどうするといいのか。今押さえておきたい、その仕組みと考え方をこのコラムではご解説いただきました。ぜひもう一度、第1回から読み直してみませんか。
▼これまでのソフトウェア品質を高めるために知りたい開発者テストの最前線
【第1回】なぜテストは必要なの？
【第2回】シフトレフトの本質とは
【第3回】知っていますか？テスト必要性から考える「テスト手法」
