超高速開発ツールの「テスト」はどう考えるか?セミナーに登壇してきました

さった9月6日に超高速開発コミュニティが主催するセミナーに発表者として登壇してきました。発表資料はこちらです。

www.slideshare.net

当日は他にキヤノンITソリューションズ様より Web Performer におけるテストシナリオ生成のお話と、SCSK九州様より自社開発の手順に OutSystems を適用した事例のお話があり、それぞれ面白かったです。その後のパネルディスカッションで会場からいただいた質問について即興で回答したのですが、それを補足する形でブログにまとめてみます。

超高速開発ツールを適用するとテスト工程を削減(あるいは短縮)できるのか。

Wagby, Web Performer, OutSystems いずれの立場も、単体テストは不要なので削減できるが、E2Eテスト(社によって「総合テスト」「受け入れテスト」「検収」など呼び名は異なる)の工数は変わらない、ということがはっきりしました。これは私の予想通りです。

超高速開発ツールを使えば不具合がゼロになる(のでテストは不要)ではないのか。

それは誤解です。ツールに入力する設計情報(リポジトリ)の記述ミスをゼロにすることはできませんし、そもそも仕様の解釈誤りや、仕様そのものに齟齬があることもあります。

ただし、ツールを使うことでこれらの不具合をかなり早い段階で検出できるようになるとともに、修正もその段階で行うこともできます。さすがに仕様変更はインパクトが大きいですが、それでも手作りの場合と比較すると、変更を反映するための工数が少なく済むことはメリットです。つまり不具合をゼロにすることはできませんが、検出と修正の時間を大きく短縮できる効果があります。

プロセス品質とプロダクト品質のどちらに効果があるのか。

ツールによってはテスト計画書やテスト実施レポートを出力するものもあるので、プロセス品質の改善に貢献できます。Wagbyの場合は OSS 製品の Jenkins などと連携した自動テストの枠組みを構築することを提案しています。
そしてなんといっても回帰テストの自動実行はプロダクト品質の維持に大きく貢献します。ただ、これは超高速開発ツールとは切り離して捉えることができます。言い方を変えると、どのツールを使ってもテストおよびそれがもたらす品質向上は別途、用意する必要があり、またきちんとやれば効果があるという話です。

E2E テストのシナリオをツールが自動生成できるか?

E2E テストは「(テスト)プログラム」を開発することになるため、その自動生成は誰もが一度は考えることでしょう。現時点ではどのツールも対応できていません。私見では "無理" だと思います。AI の発展でテストプログラムの自動開発は期待できるか?というツッコミもありましたが、私はそれにも否定的です。システムの設計と、受け入れテストのシナリオ作成は、エンタープライズアプリケーション開発で人間が最後まで関わりつづける分野でしょう。"私が必要としているシステムはどういうものか?それを確認するテストシナリオとはどういうものか?" を人に代わって AI に考えてもらうというのは、いくらなんでも、ね...

Wagbyの場合は、テストシナリオ(を実行するテストプログラム)を書きやすくする環境を提供するという立場です。

回帰テストはどうしているのか。

私がもっとも興味をもっていた部分です。このセミナーに参加して他社の発表を聞き、参加者とのやりとりもとおしてわかったことは、回帰テストは現状、ほとんど、実施されていないか、実施していても(このやり方でいいのか)悩んでいる、という現実です。

パネルでは言いそびれましたが、回帰テストの実施率が低い理由は次の3つだろうと推測しています。

1. 回帰テストのためのテストシナリオを起こせる人材がユーザ企業、SIerの双方に乏しい。
2. 回帰テストプログラムを書くことが面倒である。
3. 回帰テストの開発費を(プロジェクト予算に)盛り込んでいない。

1 は「業務を可視化し、さらにリデザインできる人材が乏しい」ということと同じような問題です。会社の枠を超え、さらにユーザ企業も巻き込んだ、人材育成のための体制・枠組みを検討すべきと思います。

2. はツールベンダーの努力が必要です。OSS で優れたフレームワークも登場していますし、当社のように製品に特化したフレームワークを提案することも良いと思います。

3. は業界全体への啓蒙活動が求められています。予算に盛り込むということはお客様(発注側)がお金を出すということです。回帰テストについて、お金を出すことの費用対効果は何でしょうか。

私は「バージョンレス環境への、攻めの対応」と説明するようにしています。エンタープライズアプリケーションを PaaS 環境で稼働させることや、利用者のPC環境(Windows 10 や Web ブラウザ)が常に最新版に自動アップデートする時代、環境変化によるデグレードを早めに検知するためにも回帰テストは必要です。もちろん超高速開発ツールのバージョンアップを行いやすくするという視点もあります。「変化に強いシステム」とはどの営業も提案するキーワードですが、変化を受け入れるためにデグレードがないことをきちんと担保する仕組みが必要です。このような説明を通して、回帰テストの重要性を業界全体として積極的にアピールするといいと思います。


おまけ

今回のセミナーはもう一つ面白いことがありました。SCSK九州は、私が大学を卒業して最初にお世話になった就職先なのです。当時大変お世話になった方々と、こういう場で再会できるのはまさしく "朋あり遠方より来る..." の感があって楽しかったです。担いでいるツールこそ違えど、この業界に何らかの貢献をしたいという気持ちは同じだと再確認できました。引き続きがんばっていこう、と気持ちを上げることができました。