【感想】ソフトウェアテスト自動化の教科書 現場の失敗から学ぶ設計プロセス
対象者
テストに関わる技術者はみんな読んで損はないと思う。テストの専門家でなくても開発者も読んだ方が良い。
ツール紹介が一部あります。Windows系です。
所感
タイトルにある通り「プロセス」に重点を置いており、現場の失敗ケースがふんだんに盛り込まれている。成功事例は溢れているが、失敗から学ぶと言う視点はあまりなく、非常に価値があると思う。
ツールについてはほぼ言及しておらず参考程度に記載されているところがいい。道具の導入から入ろうとする現場が非常に多い印象。私自身居合わせたことがあるし、そういった失敗もある。
エンジニアなら業界問わず、一度は自動化しようと思ったことがあるのではないだろうか。
私は組み込みおよびWebの双方で経験があるが、どちらでも自動化しようという流れの経験がある。
失敗したことの方が多い。当時はなぜうまくいったのか、行かなかったのかしっかり分析できていなかったが書籍を通して振り返ることができた。私にとっては非常によい書籍となった。
SREと似てる？
SREとして活動していると、トラブルシューティングが日常的に発生する。
自動化するためには、対象となる事象から解決方法までの一連に対する洞察が深くないと本質的に解決できないことが多々あり、別のトラブルを引き起こすことすらある。そのため十分知見が溜まってからの方がより安全に解決に向けてアクションできる。テストの自動化も似ている。
1. トラブルを解決してく中で対応手順が明確になる。
2. 明確になった対象手順はドキュメント化される。
3. 高頻度、高負荷のものは自動化やプロセス・ワークフローなども含めて改善していき作業工数をゼロにする。
ドキュメント化→運用→自動化（経験談）手作業だと再現難しいケースで自動化
昔、組み込み系の制御システムで数日間稼働していると、低頻度で固まるという現象があり再現できずに難儀していた。
どうやらシステムを開始・停止を繰り返しているとごく稀に発生するらしいと報告があった。
開発チームでは手作業で再現できなかった。そのため、数日でシステムを構築。「exponential backoff with jitter 」を使って開始・停止のタイミングをずらしながら実行する仕組みを作った。数日間テストし続けて再現ができた。
ログを調べていくと原因が見えてきて修正に至り、修正確認も同様の検証を行い無事に解決することができた。
原因はマルチスレッド間通信による不具合だった。
まとめ
テスト自動化の目的は何か。何のためにやるのか。
これに尽きる。
ゴールが不明確な状態でツール導入先行で進めてしまうことで、迷走することになる。
何のためにやるのか
書籍では以下を目的としている
デグレーションのテストとその繰り返し作業の工数削減
何をやらないのか
* 繰り返さないテストの自動化
* 人間がやった方が精度が良いテストの自動化
* 仕様が変わりやすいテストの自動化
* バグだしのテストの自動化
改めて記述すると当たり前のようだが、導入が目的となってしまうと要らぬ箇所まで自動化してしまうことになる。
すこし観点が違うが、マズローのハンマーの法則に通づるところがありそうだ。
If all you have is a hammer, everything looks like a nail.
自動テストのリスクとは
作業の手戻りになりうる要因
期待マネジメント
ステークホルダーと自動化に対する効果の意識合わせが重要。
ここでいうステークホルダーとは、自動化をするに当たって利害関係のある人たち。上司や経営層かもしれないし、プロジェクトマネージャーかもしれない。あとで、「こんなはずじゃなかった」とならないためにもすり合わせが重要だと思う。メリット・デメリットを把握して、自動化に対する期待をコントロールした方が良い。
一般に、「自動化」という言葉のイメージから、自動でテストをおこなうことで劇的にコスト削減し、大きく品質を高めると言う過度な期待をしがちです。
メモ
以上。
この記事が気に入ったらサポートをしてみませんか？