前回のレポートでは、プリセールス含め営業やコンサルタントを行うときに使えるテスト自動化に関する戦略の内容をレポートさせていただきました。
レポートの後編では具体的にどうやってテスト自動化を行っていくかのノウハウを、和田氏の基調講演の後半部分(戦術編)とご登壇された企業様の事例紹介を通してレポートさせていただきたいと思います。
どうすればテスト自動化ができますか？
和田氏の基調講演の前編ではテスト自動化を行うことを推進していくための戦略が紹介されましたが、後編ではテスト自動化を実際に行うための戦術が紹介されました。
最初にこれからテスト自動化を行うことが決まった現場にテストコードがなくレガシーコードが蔓延している場合、次のようなジレンマがあると同氏はレガシーコード改善ガイドを引用して言及されていました。
「コードを変更するためにはテストを整備する必要がある。多くの場合、テストを整備するためには、コードを変更する必要がある」
これはテストを書けるコードにするためには元のコード自体をリファクタリングしなければならないことが多いのですが、リファクタリングをテストコードがない状態で行うと品質の担保ができずコード自体が動かなくなってしまう可能性があるので、デッドロックの状態になっていることを表現しています。
またレガシーソフトウェア改善ガイドという本を引用されリエンジニアリングを行う際、次の3つの選択肢があることを示されました。
- リファクタリング
→ローリスクだがデータ構造までは動かせないローリターン - リアーキテクティング
→システムをサブシステム単位にわけて刷新するミドルリスクミドルリターン - ビッグリライト
→最新のものにすべて取り換えるハイリスクハイリターン
同氏は伊勢神宮の内宮と外宮を少しずつ新築にしていったことを例に挙げ、リスクとリターンが中間であるリアーキテクティングを推奨されていました。
その前提の上で、テスト自動化導入に際し具体的にどうやってテストを自動化していくかという具体的な戦術が大きく分けて2つ紹介されました。
どこからテストを書いていきますか？
まずひとつ目の戦術としてどこからテストを書いていくかですが、答えは明白ですでに不具合の多いところはバグの温床になっていることが多いので、そこからテストを書いて修正していくとROIが自然と高くなるということです。
そしてテスト自動化のトリアージは次の5ステップでできるとのことです。
- テストケースを一覧にまとめる
- リスクを大まかに見積もる
- 手動テストのコストを大まかに見積もる
- 自動化のコストを大まかに見積もる
- 最後に優先順位をつけて並べ替える
優先順位をつけて並べ替えると上のような表ができあがるので、障害時のリスクと手動テストのコストが高く、自動化コストが低いところからまずはじめるという流れになります。
そして自動化のコストを大まかに見積もるには次のような自動テストにおけるテスタビリティを参考にするとよいと示されていました。
- 実行円滑性：自動実行が容易でかつ高速なこと
- 観測容易性：テスト結果の取得・期待値比較を自動化しやすいこと
- 制御容易性：事前状態を制御し、テスト対象を自動操作しやすいこと
- 分解可能性：テスト対象の切り出し、テスト環境への部分置換が容易なこと
どうやってテストを書いていきますか？
どこからテストを書くのかを決めたら、２つ目の戦術としてどうテストを書いていくかということになりますが、最初にテストを書いていく時にこだわらなくてもよいところとして次の項目を挙げられていました。
逆にこだわるべきところとしては次の項目を挙げられていました。
そしてテストサイズという考え方を紹介し、自分たちでテストサイズSMLを定義してテストピラミッドを調整しながらテストを書いていくことも推奨されていました。
同氏は、なによりもまずサンプルやデモレベルからやってみてテスト自動化がどういったものであるのかを体験できるようにしていくことが大事であることを強調され、テスト自動化は「できるからやるのではない、やるからできるようになる」ものであることを話されていました。SHIFTのクレドの一つである「できないとは言わない、できるといった後にどうやるかを考える」に少し似ている気もします。
組織にテストを書く文化を根付かせる戦術まとめ
基調講演の後半では組織にテストを書く文化を根付かせる戦術を同氏はお話されました。戦術編をまとめると次のような内容となります。
- テスト自動化の方法は？
ミドルリスクミドルリターンのリアーキテクティングを推奨 - どこからテスト自動化を行うのか？
5ステップでテスト自動化の優先順位をつけて高いところから自動化する - どうやってテスト自動化を行うのか？
こだわらなくてもいいところはこだわらずにまずはサンプルやデモから行う
基調講演では組織にテストを書く文化を根付かせる戦略と戦術が紹介されました。もちろん文化なので一朝一夕に浸透するものではありませんが、テストがまったく書かれていない環境に変化をもたらすためのエッセンスがこの基調講演には盛り込まれていると思いました。
継続的なテスト自動化はできていますか？
事例紹介のひとつ目として、オムロン株式会社 山内佑二氏が「継続的なテスト自動化のための取り組み事例」と題してセッションを行われました。
テストを自動化したのはいいものの、テストが動かなくなることやフレイキーなテストが多いとテスト結果自体が信用にならないことがあり、納期通りにテストを完了できなくなることを問題として挙げられていました。
同氏は実際に画像センサのシステムテストを自動化しており、ハードウェアのテストになるので自動テストのシステム構成がWebなどのアプリケーションと比較してとても複雑で、実際に画像センサのテスト自動化を行った際の課題を4つ挙げられていました。
- 新しいテストをどう追加すべきかわからない
- テスト環境組み換えの手間
- テスト環境の設定ミスによる後戻り
- テスト結果の確認に手間がかかる
4つの課題を次のような施策を行うことで継続的なテスト自動化を可能にしたとのことです。
- テスト設計での保守性の改善
- 実行効率を上げる計画
- 手順ミス、トラブル回避
- テスト結果の信頼性の改善
これらの施策に関して具体的に次のような取り組みを行っているとのことです。
- テストスクリプトを分割し理解やすくする
- テストスクリプトの共通部分を部品化して再利用
- テストスクリプトでは他の処理とできるだけ依存しないようにする
- テスト環境ごとにテストセットを作成する
- テスト実行時間を考慮して、時間のかかるものは夜間に実行する
- 機材をある程度ひとまとまりにして固定することで、複雑な接続を減らす
- 接続状況などテスト環境自体が正しいことをスクリプトでチェックする
- テストの途中結果を残すことでトレーサビリティを確保する
- 実施した環境がいつでも再現できるように構成管理を行う
これらの取り組みで自動テストのメンテナンスコストの削減と実行効率を上げることが実現できており、他にも教育に力をいれており自動化にかかわる人を増やすことで継続的なテスト自動化を推進しているそうです。
取り組みの一覧を見ると多くはソフトウェアのテスト自動化のときにも行うべきものがとても多く、ハードウェアのテストもソフトウェアのテストもテスト自動化のノウハウに関しては共通部分が非常に多いことがわかります。
安心で安全な開発は提供できていますか？
事例紹介の2つ目として、ウイングアーク１ｓｔ株式会社 伊藤 潤平氏が「APIテストを自動化してリグレッションテストにしたら、安心で安全な開発ができて気持ちが楽になった」と題してセッションを行われました。同氏はまず実際にウォーターフォール開発からアジャイル開発手法の一つであるスクラムを導入したときに発生した問題点を4つ挙げられました。
- 開発リリース物の品質が悪い
- クオリティゲートを通過できない
- 品質保証工程を開始できない
- スケジュール遅延のプロダクトリスク発生
またこれらの問題が顕在化したときに開発チームにヒアリングを行い次のような状況が発覚したそうです。
- 開発者によってはコンポーネントテストを実行していない
- 自分の実行環境のみのテストで、バックエンドとフロントエンドの結合テストが不充分
- 非機能は品質保証のメンバーがテストしてくれるだろうというマインド
- クオリティゲートや品質に関するルールがない
これらの問題の対策として、開発工程内で品質を高めてスムーズな品質保証工程を実現するために、品質保証部門から開発部門にメンバーをアサインして、SET(Software Engineer in Test)のロールを追加したとのことです。そしてSETのロールを追加した上で行ったカイゼンを2つ挙げられていました。
ひとつ目はスクラムにテストのルールを作成したということで、具体的にはコンポーネントテストは開発者が実施、結合テストはSETが実施、機能テスト、システムテスト、受け入れテストはQAが実施するようにとテストレベルとそれを行うロールを定義づけしたことと、スクラムのDoD(Definition of Done)にテストのルール(e.g. リグレッションテストが実施されていること,サポート対象のブラウザでテストされていること、テストのエビデンスが残っていること…etc)を追加したことを挙げられていました。
2つ目はWebAPIテストの自動化を導入したことで、SETが行うテストはUIテストとWebAPIテストの二つで、WebAPIテストでは開発者がコンポーネントテストでカバーしていることを前提に、WebAPIのバリデーション処理やバックエンドの機能を検証するテストセットとして、自動化によって自動的にリグレッションテストを実行しているとのことです。
WebAPIテストではWebAPIにリクエストしたときのHTTPのステータスコードやエラーコード、メッセージをそれぞれテストしていて、約50のWebAPIに対して、437の観点で4682のテストケースが実行されているそうです。
これらのカイゼンによって得られた効果を4つほど挙げられていました。
- WebAPIテストで重大な不具合を早期に発見できた
- WebAPIの設計段階で開発者同士の認識違いを発見できた
- QA視点でのテストが行うことができ、WebAPIから準正常系のリクエストを送った時に想定外の動作をすることが気付けた
- WebAPIのリグレッションテストでデグレードが早期に発見できた
これらの効果によって開発工程で検出される不具合が増えて、品質を早期から作りこむことができるので、品質保証工程でのクオリティゲートを一回で合格できるようになったとのことです。
同氏はさらにチームが成熟した後、開発プロセスをより最適化したことも付け加えられていました。具体的には開発とSETがチームとなり、実装、Unitテスト、APIテスト、機能テスト、システムテストまでを実施するようになったということです。またクオリティゲートとフェーズを複数にわけることで段階的に品質を積み上げることを可能にしたそうです。
例えばフェーズ1では機能テストや互換性テスト、フェーズ2では機能テストやユースケーステスト、フェーズ3では性能テストやプラットフォームテストといった具合に細かくクオリティゲートを設けてすべてをクリアしたときに品質目標が達成されるということです。
最後に同氏は現状のWebAPIテストの課題を3つほど挙げられていました。
- テストケース増加によって、テスト実行に時間がかかる
- 実装者がテスト構築をするので管理が大変
- フレイキーテストが増えており、テストセットをリファクタリングする必要がある
WebAPIテストに課題はあるものの、品質を早期から作りこむことができ、開発者にとってもチーム全体にとっても安心で安全な開発ができるようになったということが分かりました。
SHIFTでもWebAPIテストの案件は増加傾向にあり実績も増やしているところですが、ただWebAPIの結合テストを行うだけでなく、いかに品質を早期から作りこみ心理的安全性のある開発現場を提供できるかということはお客様からも期待されているところかと思いました。
まとめ
和田氏の基調講演は、テスト自動化について理解したうえで組織に提案して受け入れてもらうことと、誰かがテスト自動化を主体的に行い背中を見せていかなければテストを書く文化は根付かないということがわかる講演でした。これからテスト自動化を提案しようとしている方や、実際にテスト自動化を行っている現場にいる方にもヒントとなる内容が多くちりばめられていたのではないかと思います。
山内氏の事例紹介では、継続的にテスト自動化を行っていくためのノウハウは、ハードウェアでもソフトウェアでも共通点が多いことがわかりました。SHIFTでもこれまでに蓄積したテストのノウハウを用いて、ハードウェアや組み込みソフトウェアのQAやテストの案件も更にこなせるようになると思います。
伊藤氏の事例紹介は、WebAPIテストの自動化の話をメインに、スクラムで開発を行うときのチーム体制も含めで安心で安全な開発をどのようにして実現していくかというよい参考になると思いました。
最後にSHIFTのJaSSTプレミアムスポンサー協賛企業としての招待枠でJaSSTに参加させていただいたことと本レポートを書かせていただいたこと、そして貴重なお時間を使い本レポートをお読みくださったみなさまに感謝いたします。お読みくださったみなさまに何か新しい気づきや発見などがあれば幸いです。
当日の資料はJaSST公式サイトからダウンロード可能です。
