システムテストの自動化はソフトウェア開発を取り巻く状況やツールの劇的な進化などによって、既にソフトウェア開発を行う上でかなりメジャーな手法になってきています。アジャイル開発のプラクティスにおいてもテストの自動化は必須だし、それはもう今やテスターとかプログラマとかの垣根なく取り組むべきものになったのではないでしょうか。
以前からテストの自動化に何となく片足だけ突っ込んだだけの状態でノホホンとしていた自分としては、気が付いたら時代の流れにあっという間に引き離されてしまった現実がありまして。例えば、最近読んで気に入った参考文献がもう既に5年前に発表されたものだったりとか・・・。そんなことを目の当たりにすると非常に悲しいというか、「この10年で君はいったい何をやってきたんだい？」と自戒する日々なわけです。
とまぁそんな泣き言っても仕方ないし、この状況だからこそ今、自分の立ち位置から見たシステムテスト自動化によって、テストエンジニアはどんなことができるんだろう？とか、自分が実現させたいソフトウェア開発の夢って何だろう？とかを語りたいと思います。
- テストの自動化について学ぶメリットとはなにか？
- なぜ今、テストの自動化を学ぶ必要があるのか？
- テスト自動化スキルを備えたテストエンジニアの可能性とは？
- システムテストの自動化でソフトウェア開発にどう貢献できるのか？
1. 受け入れテスト・スモークテストの自動化
プロダクト開発の最終工程で行う受け入れテストや、ウォーターフォール開発の各フェーズゲートなどで行うスモークテストの自動化は、今も昔も引き続きテストエンジニアへの要請としてあり続けると思っています。なぜなら、フェーズ毎の確認を重視したソフトウェア開発はこの先もまだまだ無くならないと思っているし、それらのテストを自動化することがQCDを向上させる手段のひとつになりうるからです。（得られる効果の程度には賛否両論ありつつも）
- 自動化でテストの確実性を担保する（確認ミスなどの属人生を排除する）
- 自動化で最終工程におけるテスト※の実施に要するコストを低減する
- 自動化で最終工程におけるテスト※のスピードを早めて短納期に対応する
※システムテストの自動化によって全てのテストが省コスト短納期になるわけじゃないことは、もはや自明のことでしょう
これらの目的で自動テストを「適切に構築」し「効果的に運用」できるスキルは、今後も引き続きテストエンジニアとしての強みになりうるはず。ただし、「ただ自動で動くだけ」のテストを構築できるだけでは有用なスキルにはならないですね。まだまだ世の中には打ち捨てられてゴミになった多くの自動テストで溢れかえっているというのが実情ですし、効率性や保守性の高い自動テストの需要に対して供給が追い付いていない。つまり、よりモダンで実用的な自動テストを構築できるテストエンジニアが不足している、と言えるんじゃないでしょうか。
この現状からみてもテストエンジニアがテスト自動化スキルを身に付けるための意義はまだ充分にあると思います。
2. 継続的インテグレーションでの自動テスト
続いて今、自動テストに求められている役割について考えてみます。
ソフトウェア開発の進歩は目覚ましいものでXPに代表されるような、より良い開発のための新たなプロセスや仕組みが使われています。継続的インテグレーション（Continuous Integration、CI）もそのひとつで、実装したコードのビルドやデプロイ、テストなどを自動的且つ継続的に実行していくことが、プロダクトの納期短縮や品質改善を行うための一般的なプラクティスになっています。
CIの実現にはテストの自動化が必要不可欠であり、そのサイクルの中で開発者がより質の高いフィードバックを得るためには質の高いテストが必要です。単体テストのみならず結合テストやシステムテスト、エンドツーエンドテストと呼ばれるエンドユーザーの利用を想定した最も外側のインターフェースに対するテストについても自動で繰り返し実行できれば、得られるフィードバックの質を高めることができるはずです。それらのテストを効果的且つ効率的に設計/構築/運用する能力、またはそれらを支援する能力が備わったテストエンジニアであれば、CIという手法の中でもテストの観点や品質向上の取り組みを担えるのではないかと思います。
3. 振る舞いのテストがプロダクトの創造を駆動する
更に先へと目を向けてみます。
実践テスト駆動開発でSteve FreemanとNat Pryceによって語られているエンドツーエンドのテストからプロダクションコードを創出していく開発手法では、テスト駆動開発（TDD）やビヘイビア駆動開発（BDD）、受け入れテスト駆動開発（ATDD）などとのシームレスな連動によって、プロダクトの振る舞いの正しさを担保しながらソフトウェア開発を進めることが提言されています。従来の単体テストレベルで行っていたTDDから、システムテストレベルでのTDDへ進化しています。
実践テスト駆動開発の解説については平鍋健児さんのブログが秀逸です。
「実践テスト駆動開発(GOOS)読んだ」
http://qiita.com/kenjihiranabe/items/b951b6d98672167347fd
具体的には、エンドユーザーが利用する一番外側のインターフェースに対して行うテストをプロダクトコードを書き始める前に作成しておいて、実装を進めながら事前に作成したテストがOKになることによって正しく実装が行われたかを確認していく、という開発方法です。例えばWebアプリケーションの開発であれば、ブラウザを使ったユーザー操作や表示される期待結果をテストコードとしてあらかじめ作成しておいて、そのテストがパスするようなWebアプリケーションを開発していくようなイメージです。
つまりプロダクションコードを書く前にシステムテストのプログラムを書く。そのテストがプロダクトの開発自体を駆動させていく。ということになります。
4. テストエンジニアとして担うべき役割とは
このことから、利用者を想定したテストが開発を駆動する時、従来から行われてきた「作られたものに対するテスト」から「これから作るものに対するテスト」へのシフトが可能になるのではないか、と妄想しています。
つまり
守りのテストから攻めのテストへの変革が起こせる！（かもしれない・・・）。
「この自動テストケースがOKになるプロダクションコードを実装してね」
「この自動テストケースがOKになったら実装完了だね」
と、テストエンジニアとプログラマがコラボレーションしたり、テストエンジニアがテストコードを実装しながら開発者がプロダクションコードを並行で実装するようなペアプログラミング（？）もできちゃったりするんじゃないか。
更には実際のユーザーにテストエンジニアがヒアリングして、どんなものを必要としているのかを自動テストケース化できれば、出来上がってから「コレチガウ」って手戻りを少なくすることができるんじゃないか。
とか・・・。
勿論、テストエンジニアとプログラマと顧客の三者が協業するアジャイル開発のような環境であることが前提だし、プロダクト自体の性質によって適用できないケースもある。一番最初の自動テストをどう設計するのかとか、テストケースの肥大化対策はどうするのかとか、いろいろ課題はあるとは思うけど・・・。
システムテストの自動化ってひとつの自動テストシステムをコンピューター上に作り上げることだと思っていたけれど、その先にあるのは人と人との繋がりを生み出すってことなんじゃないかな。なんか楽しそう。妄想は尽きません。
前述の通り既に世の中ではテストが製品を創造し始めています。そこで行われるテスト自体は品質を保証するのとは少し違う意味でのテストなのだけれど、その事実が持つ意味はテストエンジニアにとって非常に重要な流れだと思っています。
テストがプロダクトを創造する時、私達テストエンジニアは何を担うべきなのか。そんな時代の渦中にいることを認識し、テストエンジニアとしての存在価値を改めて自己に問い直しています。より良いプロダクトを開発するためのコラボレーション基盤として自動テストを活用できるようなテストエンジニアになりたいと思っています。
夢は語らなければ現実になる可能性も無いもんね。
うん、頑張ろう。
