【開催レポート】長崎QDG2015  その5:テスト自動化の現場から

 レポート第5回目です。

長崎QDG2015_150812_155321.jpg 株式会社ウェブレッジ 浦山さつきさんによる「テスト自動化の現場から」の様子をレポートします。(本記事掲載の写真やスライド画像 は浦山さんの許可を得て掲載しています)

 浦山さんは第三者検証会社であるウェブレッジに所属し,エンタープライズ・金融系システムのテストを対象にテスト設計や自動化,マ ネジメントや教育に取組んでいらっしゃいます。また,テスト自動化研究会やテスト設計コンテスト出場チームであるしなてすに所属,システムテスト自動化標準ガイドを共訳されるなど多方面で活躍されています。このセッションではテストを自動化したシステムの紹介と自動化あるあるについて解説いただきました。

テスト自動化の現場から~テスト自動化の保守の話~ from Satsuki Urayama


 自動化したシステムの紹介は「店舗情報ポータルサイトの品質管理業務」と「顧客管理システムのテスト」2つでした。

自動化の現場から_2.PNG自動化の現場から_1.PNG 「店舗情報ポータルサイトの品質管理業務」は,約60万軒の店舗情報を扱うWebサービスについての事例です。品質管理部は会亜h粒に対 してリリース判定やコンテンツの機能障害検地,リンク切れチェックや記法・非機能の確認といった業務をサービスとして対応していましたが,ユーザーが増えるに従い人手で行うのが困難になってきました。そこで,それらを自動テストという手段を使って改善したという事例でした。

 「顧客管理システムのテスト」は,数千万人の顧客情報を取り扱うクライアントシステムについての事例です。システムテストチームにテスト自動化チーム(10名)を設け,システムテストをスコープに回帰テストの自動化と自動テストの運用を実施したとのこと。2005年の 新規開発から2011年まで,運用し続けたそうです。

 大規模なシステムでは,きちんとテストチームを作り運用すること,自動化の促進や自動化されたテストの継続的な実施が大切なことだ と受け取りましたが,継続し続けられるのも自動化して俗人性が低くなっているからこそと思います。


 次にその二つの事例の経験から自動化あるあるが解説されました。

自動化の現場から_3.PNG自動化の現場から_4.PNG自動化の現場から_5.PNG 「あるある1 自動テストの認知度が低い」では,二つの事象が解説されました。「事象 急に動かなくなる自動テスト」は,ソフト修 正の情報が自動化チームに伝わらずに自動化したテストが大量に失敗するというもので,これの対策は「伝達体制の強化と回避策の規定」 とし,(自動化チームが)把握できていない箇所で問題が起きたときの回避策を用意しておくことが大切と解説されました。「事象 チケ ットの後回し」は,報告した不具合が改修されている雰囲気がないが同時期に報告した他のチームの不具合は回収されているというもので ,これの対策は担当者だけではなく上層部からの連携や認知されている部署への協力を仰ぐことが必要と解説されました。

 「あるある2 構造化されていないスクリプト」。「事象 修正が追いつかない」は似たようなスクリプトが多すぎるというもので,対 策として「スクリプトの構造化」が有効とし,スクリプトとパラメタタ部分を分けて管理すると良いと解説されました。

 「あるある3 サーバのパンク」。「事象 画面キャプチャでログサーバーがパンク」について,対策として「キャプチャ取得や保存タイミングの整理」が必要とし,エビデンスやログの解析に不要な画面キャプチャの削除や過去ログの保存ルールを決定するのが良いと解説されました。

 「あるある4 ほったらかしのテストケース」。「事象 テストしていないところからのバグ発見」は,テストの保守を怠った結果,テストケース以外の個所からデグレードを発見したというもので,対策として「テストの草刈り」が必要とし,テスト自身の保守(テストケ ースの追加と削除)が大切であるとしました。

 「あるある5 担当者の撤退」。「事象 主担当者が抜けたら自動テストが回らない」は,数年来の担当者がプロジェクトを抜けたが, 他者への一時的な引き継字によって自動化が途絶えてしまったというものです。これの対策は「担当者同士での引き継ぎをしよう」という ものですが,後継者と十分な引き継ぎ期間が必要であったり学習コストを下げる工夫が必要と注意がありました。


 浦山さんからは,最後に「自動化も保守が必要です。」という話があり,『テスト自動化標準ガイド』から7章の「保守性の高いテストを構築する」が参考になるという紹介がありました。

自動化の現場から_6.PNG テストの自動化は派生開発においても重要な関連技術の一つです。派生開発における一つの改造や機能追加がもともと動いていたシステムに影響を与えることを即座に検出することができなければ,派生開発はうまくいかないことでしょう。ひとつ前のセッションで「テストケースも派生開発の対象」という話がありましたが,自動化されたテストもまた派生開発が必要で,このセッションにおけるテストの保守とつながります。これから自動化に取り組む人は,このセッションで紹介された「自動化あるある」を参考にすることが,有効な自動化を実現するための最初の一歩となるであろうと思いました。


 派生開発に限らず,新規開発においてもテストの自動化はとても重要です。ただし,自動化技術の導入はそう簡単な物ではありません。基礎となる記述がないままに自動化に取り組むとコストが見合わなかったり失敗してしまったりということも起こりえます。そこで,ウエブレッジさんなどの自動化エキスパートが所属する企業に協力していただき,自組織の自動化スキルや仕掛けの高度化を図っていくことも大切なのではないかと思いました。最初のドライブさえうまくいえば,その後はそれで得た技術で時組織改善が計っていけると思います。

Comments

No comments yet. Why don’t you start the discussion?

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です