その2です。たぶん、最後まで永遠にたどり着きません。
TABOKガイド Segment2以降は、12のスキルカテゴリーの詳説に入ります。その前に、こちらのフリップをご覧ください。
TABOKはPDFで243ページあるのですが、そのうち32ページ、実に16%がスキルカテゴリー1「テスト自動化の役割」に充てられています。複雑で難しいことがたくさん書いてあるというより、割と当たり前と思えることを丁寧に解き明かしているのですが、普段ちゃんと英語を読まない身に32ページってけっこう難関です。ここを乗り越えれば、他のsegmentは平均15ページ弱なので、サクサク行ける・・・かもしれません。
カテゴリー1: テスト自動化の役割
カテゴリー1は、3つの章からなります。
- 1-1: SDLCにおける自動化のインパクト
- 1-2: テストツールの習得と統合
- 1-3: 自動化のROI
このカテゴリは、テスト自動化全体の概論なので、大ボリュームなんですねえ。特に、最初のカテゴリで費用対効果について言及していることは重要だと思います。
1-1: SDLCにおける自動化のインパクト
具体的な技術よりまず、テストの自動化が与えるインパクトを、いいものも悪いものも合わせて正しく理解せよ、ということが繰り返し言われます。過度の期待や誤解に基づく自動化の試みは、贅沢な実験に終わりかねない。ですからTABOKガイドとしては、「こういう勘違いをするな」と教えるだけでなく、「こういう勘違いをするやるがいるから気をつけろ」と言いたいように思います。
なお、SDLC（ソフトウェア開発ライフサイクル）の中に、ATLM（Automated Testing Lifecycle Methodology: 自動テストライフサイクルの方法論）がどう埋め込まれているかの図があるんですが、全然説明されていないのが謎です。
1.1.1: テスト自動化の御利益
テスト自動化の主な御利益として、以下を挙げています。
繰り返しのしやすさの向上
テストの繰り返しが、正確に、担当者が付き添わなくてもできてしまう。もっとも大きいメリットですね。逆にいうと、繰り返しをしないのであれば、コスト的にはたぶん元を取れません。
繰り返しが威力を発揮するのは、リグレッションテスト。「Cumulative Coverage」（累積的テストカバレッジ？）という言葉が出てきます。
派生開発においては、新規開発分のテストと、過去の累積である既存部分のリグレッションテストを行うことになるわけですが、それをどの程度網羅的にやっているかというもの。右の図はTABOKガイドのグラフを書き換えたものです。5つのビルドで合計268のテストがありますが、そのうちいくつやったか、という割合です。
手動では難しいテストの実現
たとえば負荷テスト。5,000ユーザを実際に1箇所に集めて、全員がストップウォッチを持って「せーの」で行う負荷テストは泣ける。これこそテストツールに助けてもらうべき領域ですね。
他に、分散トランザクションのテストや、クラウドのような従来とは違う環境でのテストを例として挙げています。
他に、分散トランザクションのテストや、クラウドのような従来とは違う環境でのテストを例として挙げています。
信頼性に対する確信
繰り返しテストは人手でもできなくはないけど、時間の無駄だし、99回通ったテストを、100回目も慎重に実行できる人は聖人。
テストエンジニアに、もっとチャレンジングな仕事を
シンプルな退屈な大量テストは機械にお任せして、解放された人間はもっと複雑で、だからこそ欠陥を出せそうなテストをやろう。探索的テストをやろう。それは機械にはできない。
欠陥の予防
ソフトウェアの欠陥の70%は要件定義の早い段階で入り込むという数字があるそうです。テスト自体の自動化ではありませんが、要件定義にもツールを用いることで、定義された要件をよりテストしやすい形に整理することができます。
開発工程全体を通じた統合
SDLCの各フェーズに対して支援ツールが提供されていますが、これを注意深く統合すれば、ある要件の変更が、設計・コード・テストにどう波及するかをトレースし、全体として同期が取れるようアラームを上げてくれるような仕掛けを作ることができます。（すごすぎると思うけど・・・）
メトリクス収集の改善
メトリクス収集は面倒な仕事ですが、プロジェクトの状況を把握したり、えらい人に伝えるのに、定量データは必要。プロセスがしっかりしていれば、自動化ツールはメトリクス収集をだいぶ楽にしてくれます。
チーム内・チーム間の相互作用
コミュニケーションの断絶は、欠陥の温床。断絶の要因の1つは、人によって使う「言葉」が違うこと。たとえば要件を管理するツールは、ユーザとアナリストの間のギャップを埋めることをサポートします。ツールが人々の橋渡しになります。
1.1.2: 誤解
テスト自動化の成否は、技術的な巧拙より、勘違いや過度な期待をどう正すかにかかっている。よくある誤解はこんな感じ。
自動化ツールは、プロセスをまともにしてくれる！
ツールはプロセスそのものではないし、ツールでプロセス改善ができるわけでもありません。プロセスの中の作業を良くしてくれるものです。
100%自動化して初めて、成功と言えるんだ！
一部のテストは複雑すぎて自動化には適さないし、繰り返さないテストケースなら自動化の必要もありません。
自動化によって、新しいバグがたくさん見つかるぞお！
自動化の御利益は主にリグレッションテストのものなのだから、どちらかといえば「欠陥がないこと」が主眼。新しい欠陥がどんどん出るなら、それはどっかのプロセスが狂ってる。喜んでいる場合じゃない。
自動化すれば、手動テストはいらないネ！
これが、プロマネやテストエンジニアが抱きがちな一番の誤解。人間じゃなきゃできないテストは、以前として残る。
全部を自動テストに置き換えてしまっていいのは、たとえばすごく影響の小さいパッチを充てる際のリグレッションテスト、といったケースのみです。
全部を自動テストに置き換えてしまっていいのは、たとえばすごく影響の小さいパッチを充てる際のリグレッションテスト、といったケースのみです。
記録/再生ツールこそ、効果的な自動化さ！
ユーザの、主にマウス・キーボードによるGUI操作を記録して再生する、記録/再生ツール。これだって役に立つツールではありますが、たとえば画面デザイン変更で、クリックするボタンの座標が変わっただけで全テストスクリプトの書き換えが必要なものだと、メンテナンスコストがかかりすぎて使い物になりません。
1つのツールで全テスト工程をカバーできるよね！？
一貫して1つのツールで、かつ人の介入もほとんどなしに動かすというのは、難しい。プロセスごと、システムの側面ごとに、ツールが必要になるのが普通です。
自動化ツール入れればすぐスケジュール短縮できるのかあ！
コスト削減もスケジュール短縮も、最初のリリースで実現できることはまれです。自動テストがリグレッションテストで最大限活かされることを考えると、当然ですが。
自動化のコストって、ツール代と、スクリプト作成工数だけでしょ！
そもそもツールを使えるようになるために金がかかるし、作ったスクリプトは常に、メンテナンスの繰り返しです。
本日はここまで。長いなあ・・・。
