【JaSST’20 Niigataレポート】興味がある人は多いが、課題も多い「テスト自動化」(前編)

こんにちは、自動化エンジニアの矢野です。2020年9月28日にオンラインで開催されたJaSST’20 Niigata(ソフトウェアテストシンポジウム 2020 新潟)に参加させていただいたので、そのイベントレポートを書きます。

テスト自動化はうまく進んでいますか？

今回のテーマは、興味がある人は多いけれど課題も多い「テスト自動化」ということで、昨今の開発現場においては避けて通れないテスト自動化の話がメインでした。基調講演はテスト界隈で有名な和田卓人氏が次のタイトルでご登壇されました。

「組織にテストを書く文化を根付かせる戦略と戦術 JaSST 新潟版」

事例紹介としては次の2つの事例が紹介されました。
「継続的なテスト自動化のための取り組み事例」
「APIテストを自動化してリグレッションテストにしたら、安心で安全な開発ができて気持ちが楽になった」

それぞれのタイトルをよく見ると「テストを書く文化」「継続的なテスト」「安心で安全な開発」といったテスト自動化を行うには欠かせないキーワードが入っていることに気づかされます。

テストを書く文化を根付かせることができますか？

「組織にテストを書く文化を根付かせる戦略と戦術 JaSST 新潟版」
タワーズ・クエスト株式会社和田卓人氏

和田氏による基調講演では、前半にテスト自動化を促進し組織に文化として根付かせるために必要な戦略のことを説明され、後半にどうやってテスト自動化導入をやっていくかの戦術が解説されました。

今回のレポートでは内容と分量を考慮して、プリセールス含め営業やコンサルタントを行うときにも使える内容が紹介されている前半の戦略部分と、実際にテスト自動化を行うノウハウをまとめた後半部分に分けてレポートを書かせていただきたいと思います。

なぜテスト自動化が必要とされるのですか？

和田氏の基調講演では、まず大前提としてなぜテスト自動化が必要なのかというところから説明をされていました。現代の製造業のビジネスモデルが「モノからコトへ移り変わった時代」というのは世界の名だたる企業の状態をみても明らかで、ITが事業の中核になっていることは多くの人が感じているかと思います。

そして今の時代はVUCA(Volatility,Uncertainty,Complexity,Ambiguity)時代とも呼ばれ、以前よりもさらに未来が予測しにくくなっており、例えば新型コロナウイルスが多くの人々の生活様式に影響を与え、未来の予測困難性に拍車をかけたことは記憶に新しいことでしょう。

そして同氏はそのような時代に求められるキーメトリクスとして「LeanとDevOpsの科学」を引用し次の4項目を挙げられました。

リードタイム:コミットから本番稼働までの所要時間
デプロイ頻度:本番環境へのデプロイ頻度
MTTR(Mean Time to Recovery/平均修復時間):サービスダウンから復旧までの時間
変更失敗率:本番環境へデプロイ時のサービスダウン発生率

大別すると1と2が仮説検証プロセスをいかに迅速に回せるかを示す開発速度のメトリクスになり、3と4がいかに安心してデプロイできるかを示す品質のメトリクスになります。

開発速度のメトリクスは仮説検証プロセスを高速に回せるかどうかが分かるので、今の時代ではプロダクトやプロジェクトそして組織全体の競争力と生存力に直結する指標になるということです。

そして品質のメトリクスではMTBF(Mean Time Between Failure/平均故障間隔)よりも障害時にいかに素早くリカバリーできるかを示すMTTRの方が重要視され、リカバリーが早ければ品質が高いとみなされるということを述べられていました。

決してMTBFを捨てるのではなく、問題発見の時期をシフトレフトし早めることによって、欠陥の修正コストの削減と品質を早期からつくりこむことができるので、早期からのテストが必要になります。

次に2019年に実施された4つのキーメトリクスの調査から読み取れることを同氏は3つ挙げられました。

開発速度と品質はトレードオフではない
組織間の差はかなり大きく、さらに開いている(2016～2019)
圧倒的な差は継続的デリバリやDevOpsへの組織的な投資の差

そしてエリートとローパフォーマーを比較したときの差も歴然とのことでした。

リードタイム：106倍
デプロイ頻度：208倍
MTTR：2604倍
変更失敗率：7倍

これだけ差があると変化が激しく予測困難な時代で柔軟に生き残れるのがどちらかは火を見るよりも明らかであると感じます。

例えば手動デプロイと手動テストだけで高頻度高品質なデプロイをできるエリートになることはできるのでしょうか？エリートはもちろんのことハイパフォーマーになることさえ難しいと思えます。
問題発見をシフトレフトして品質を早期からつくりこみつつ、高頻度でデプロイすることを可能にするのは、CI/CD (Continuous Integration/Continuous Delivery)の基盤を整えてテスト自動化をすることは不可欠であり、テストを書くという文化を組織に根付かせる必要性に繋がるということですね。

テスト自動化したい目的は何ですか？

テスト自動化の必要性についてわかったところで、和田氏からはテスト自動化の目的はテストコストの削減がしたいからではないということを強く発言されていました。
テスト自動化の目的は、企業やプロダクトが競争力を得るためにはアジリティが必要で、そのアジリティを獲得するためにテスト自動化を行うということです。

なぜテストが書かれないのですか？

テスト自動化の必要性と目的を整理したところで、それなら全員がテスト自動化すれば万事解決ではないのか？と思いますが、そううまくはいかないことも多くの人が感じていることです。同氏は、テストのないコードはレガシーコードだと言われても、実際の現場ではテストを書くことを妨害する呪いのような二つのならわしがあることを指摘されていました。

テストを書く時間がない
動くコードに触れるな

まず一つ目のならわしについては、James Grenning氏の「テストを書く時間がないのではなく、テストを書かないから時間がなくなるのです」という言葉を引用して説明をされていました。これは納期などストレスの圧が強い現場ではテストが減り、テストが減ることでさらに時間がなくなりストレスが増えるという負の循環が存在することを端的に表している言葉です。

この負の連鎖を断ち切るために、テスト自動化を行うことでテストが増え、テストが増えることで時間ができ、納期などのストレスが減るので自動テストをさらに書くことができるという、正の連鎖である自動テストモデルが解決策になることを示されていました。

二つ目のならわしについては、現代においては動くコードも動かなくなるということを指摘されていました。
例えば動くアプリケーション自体のコードフリーズを行ったとしても、OSやファームフェアにブラウザ、アプリケーションが依存しているソフトのバージョンなどは否応なく変わっていくことはスマートフォンの状況などからもよくわかることかと思います。

つまり、今は「何もしていないのに壊れた」という時代ではなく「何もしていないから壊れる」時代であると表現されていました。動かなくなったら早期に検知し修正できるようにしなければいけないので、テスト自動化が必要になるということです。

どうすればテストを書いていくことができますか？

テストを書くことを文化として根付かせることができれば、テストも自然と書かれていきますが、文化を醸成することは年単位の事業になり並大抵のことではできないことは誰しも感じると思います。

同氏は、状況は現場によって当然異なるし、確立されたテスト自動化の導入方法もなく、テスト自動化も銀の弾丸ではないのでそれ自体を目的にしてはならないという前提のもとで、イマココから始めることを推奨されていました。

変化には長期的なマラソンが必要ということで、まずは現状を把握(AsIs)して、これはやめたい(NotToBe)リストをつくることをお勧めされていました。ToBeよりNotToBeの目標の方が、スコープが締まって手前に設定できることが多く、そうすることで無理のない形で変化を加速させられるということです。

どうすればテスト自動化を相手に説得できますか？

そもそもテスト自動化をしていくことを、マネージャー層を説得し開発メンバーに積極的に行ってもらえなければなりません。
ここで同氏はテスト自動化のコンサルタントをするときによく使う方法をご紹介されていました。

日本人を動かす劇薬「みんな飛び込んでいますよ」
説明責任の向きを反転させる

一つ目は、日本人を動かす劇薬である「みんな飛び込んでいますよ」について説明されていました。最初は難しそうに思えて導入に失敗しそうで、なかなか踏み込めないテスト自動化も、周りのみんなはすでにやっているということを伝えることが大切とのことです。

つまり日本人は圧倒的な事例主義なので、事例を集めてパッケージングしてもっていくことで組織が動かせるのだそうです。成功事例がすでにたくさんあるなら安心もできるし焦燥感もあるのでやりたくなるということですね。

二つ目の説明責任の向きを反転させるについては、最近、河野太郎行政改革・規制改革相が行政上の手続きにおいてハンコの使用を廃止するように求め、できない場合はその理由を示すように伝えたことを具体例として挙げられていました。

ハンコの使用を廃止する理由を説明するのではなく、ハンコの使用を廃止できない理由を説明させる方向に転換したのです。テスト自動化に際しても同じで、なぜテスト自動化をやらないのかというように説明責任の向きを転換するということです。

何をすればテスト自動化の価値が説明できますか？

説得方法がわかったうえで、理論武装し説明する説得材料が必要であるということで、同氏はさまざまな説得材料をご紹介されました。一つ目は問題発見の時期をシフトレフトし品質をつくりこむという話でも説明されていたように、不具合の早期発見は欠陥の修正コストも削減できますが、つまり遅れれば遅れるほどコストが膨大になりますし、保守性の低いものは一つ一つの変更に余計な手間がかかってしまいます。

次に、各企業でのTDD(Test-Driven Development/テスト駆動開発)導入効果を具体例として挙げて、TDD導入によって実装時間が約20％増えるが、品質が70～80％程度向上するということを示していました。

またとある企業では定量的評価だけでなく被験者を対象とした定性的評価も行っており、90％近くの被験者がTDDによって要求が洗練され、デバッグ工数も削減され、品質の向上を感じており、50％の被験者は開発工数が減っていると感じたそうです。これは実装時間が約20％増える話と矛盾するように思えますが、問題が起きた時の手戻りが減ることやデバッグ工数が減るのでそう感じるのだということです。

このようにテスト自動化によって早期に品質をつくりこめることは、20％程度実装工数自体は増えるものの品質が70％以上向上し、なおかつ保守性が高くデバッグも行いやすいので実装や修正時の工数を高精度に見積もることができマネージャ層にとってもありがたい状態になります。これらの事実は説得時やエレベーターピッチにも使えるということです。

そして品質への投資効果が表れるのも、そこまで長期的な目線は必要なく、1ヶ月以内という短期間に現れるのも説得材料になるとのことです。

テスト自動化で本当に品質があがるのですか？

テスト7原則の一つ「テストは欠陥があることしか示せない」にもあるように、テスト自体は自動化しても品質を直接的にあげることはないと説明されていました。例えばダイエットの手法の一つにレコーディングダイエットというものがあります、これは体重計に乗ること自体は体重の減量には当然つながっていないのですが、毎日体重を測定し現状を把握することで常に食事や運動に意識が向き、結果的に体重がコントロールできるという手法です。

品質についても同じで、テストを自動化し頻繁に行うことで品質の可視性が上がります。この品質が常にわかるということがとても重要で、その可視化された状態を起点にして品質を上げることができるリファクタリングや再設計といったネクストアクションに繋がるので、テスト自動化をすると結果的に品質が上がっていくということです。