NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'12 Tohoku

基調講演＋開発ライブ
「テスト、設計、自動化と。」
関 将俊 氏/深谷 美和 氏

前半は関氏による講演で、淡々とした口調で会場に様々な問いかけをしながら、ご自身の考えと試みを語られた。
設計とテストは別のものなのだろうか？という話から始まった。設計とは何か？テストとは何か？理想と現状の差を埋めることを目的としたとき、差を探す行為がテストで、差を埋める行為が設計ではないだろうか。
テストや設計の自動化を想像できるだろうか？そもそも自動とは何か？を考えると、自動実行と計算機による支援が挙げられる。
テスト自動化の例としてTDDが挙げられるが、TDDは設計技法であり、ゴールをテストケースで表現するもののテストケースを作成することも設計の一部である。作成コストについては、少しずつ書いていくので面倒ではなくわりと安い。実行コストはこれまでたどってきた各ステップのゴールを何度でも実行できる点でとても安い。しかしバグを見つけるには限度がある。
テストはCheckingとTestingに分類され、テストの自動実行は一般的にCheckingの行為になる。実行コストは安いがケアレスミスしか判明しないので損した気になる。
そこでTestingやその他の計算機支援はできないか？と考えてみる。未知の問題の発見を手伝ってもらうことができないだろうか？そこで、不具合データベースをもとに架空の不具合を生成するツールを考えてみた。人がテストを行うときには、脳内で不具合を想定しながらテストをしている。そこで形態素分析とマルコフ連鎖を用いて学習結果から「ありそうな不具合」をピックアップさせ、それが実際発見される可能性を考えたり再現するか試行してみた。また、手動で実行するテストに対して問題をみつけたかどうかを学習させて「今実行するのがお得なテスト」を提供するテストスイートのリコメンドも試してみた。問題が見つからなければ復習間隔は次第に伸びていき、問題がみつかれば繰り返しが増える、このことで良いテストケースを薦められるようになる。
最後に後半の開発ライブに繋がる話題として、TDDにおけるDestroy(破壊)の話があった。TDDのサイクルはRed→Green→Refactoringであるが、このサイクルの中にたまに「バグを見つける帽子をかぶり」Destroyを混ぜてみるとよい。より良く、より強いコードにするために疑って壊してみる。

後半は深谷氏の進行で開発ライブが行われた。関氏がRubyでコードを書いたあとで、参加者がバグがでそうなテストケースを提案するという、Destroyの行為を体験できるセッションとなった。
まずシンプルな処理から始め、種のような小さなシステムを育てるように少しずつ仕様を増やしていった。お題はMyersの三角形を利用したWebUIを持つ三角形判定アプリ。
参加者はテストしたい入力値の組み合わせを考え、なぜその値を入れたいと思ったかを述べるというルールで行われた。参加者は様々な考えを出しあい、賑やかに進んでいった。中でも興味深かったのは整数という仕様に対して「なぜ整数という制限があるのか？利用者はルートのような整数以外の値を入れたいと思うのではないか？」という意見が出たことだった。
更に、ただ仕様の追加に伴いコードを追加するだけではなく、よりシンプルなコードにすることも考える必要性も示された。三角形の種類は同じ値がいくつあるかを計算するuniq.sizeというメソッドを使えば一回の処理ですむ。三角形判定も入力値をソートして一番長い値が他の二辺の和より小さければ三角形であるという判定を行わせるほうがシンプルですむ。ただしこのようにシンプルにするとコードの理解性は低下する。コードの理解を共有する必要性も示された。

講演や開発ライブを通して関氏が普段から好奇心旺盛に設計を楽しんでいる様子が伺えた。自動化というとテスト実行の自動化を想定することが多く、他に計算機に任せることはできないだろうか？という考えが希薄になる傾向はあると思う。「もっとよいものがあると思う。みんなで考えるとよいのでは？」というメッセージがあったが、確かにみんなで考えて試してみて情報共有していくことでもっと幅広い試みができてよいものができていくと思う。

オープニングディスカッション
「今より一歩先へ」

食後の眠くなりやすい時間帯ということもあり、登壇者だけでなく引き続き会場を巻き込んでのオープニングディスカッションが行われた。
自動化に期待するところはリグレッションテストの他にあるのか？に対しては、入力値を少しずつ変えてテストをする必要があるが「やっていて面白くない」「バグが出そうもない」と思ってしまう作業を自動化することで、苦労せずにバグが見つかる事がある、という意見があった。また、そもそも手動と自動とでは手段が違うだけ、という意見もあった。手動だからテストが漏れて良いわけではない、という意見に対し、確かに自動化のときには漏れを気にするが手動では漏れを気にしない傾向がある気がする、という意見も出ていた。
組込みの自動化に対して踏み出せない悩みということで参加者から意見を募ったところ、タイミングのずれが生じやすく調整に時間がかかる、結果の判定は目視のほうが早い、という意見があった。これに対し、タイミング以外のものを先にテストする、タイミングとは何か？を考える、機械がOKでも人の感覚によりダメという判断になるケースもある。自動化で何を獲得したいのか？を明確にする。目的が定まっていないのに自動化するのはよくない。という意見があった。
その他にも、上層部の理解というのはやらないための言い訳に過ぎず、やってしまえば良いと思う、その気になればできる環境ではないか？という意見もあった。
また、開発の速度に追いつかないときは自動化をやめるほうがよいケースもある、という話もあった。

ディスカッションを通して、自動化の挑戦は気軽にしたほうがよく、それでも自動化する目的を明確にしたうえで、失敗しすぎないためにどこを自動化させると効果的かを見極める必要があるということを感じた。

ライトニングトークス
-「大規模なデータを扱う場合のテストの悩みごと」
  半谷 充生 氏
-「できることから始めてみた。　～レビュー改善実施記録～」
  稲田 優子 氏
-「テストの使い方」
  きょん 氏
-「万歩計アプリの検証について」
  高橋 理 氏

ディスカッションの後は4名の方によるライトニングトークスが行われた。現場のちょっとした取り組みや悩み事、日常生活の中に検証を取り入れた例やテストの目的に対する考えなど、気楽ながらも学ぶところのあるセッションであった。東北では2年連続でライトニングトークスセッションを設けており、身近な小さな取り組みや考えを発表する場として有意義なものだと思う。

チュートリアル
「今さら聞けないJenkins入門」
今井 勝信 氏

継続的インテグレーション(CI)ツールであるJenkinsは普段の業務の中でも耳にするようになるほど身近なものになってきていると思う。それでも実際に利用する機会が無く、「名前だけ聞いたことがある」程度の認識でとどまっている方もまだまだ多い(筆者もその一人である)。そんな方々に向けて、Jenkinsがどのような役割を持つツールなのかという紹介が行われた。
例えば統合開発環境であるEclipseは万能で、テストをしながら開発もできるし、ビルドもボタン一つでできるようになっている。しかし、特定のPCでビルドできても他のPCでビルドが通らない、テストが面倒で実はさぼっていた、という問題が起こる。人の作業をなくすことでルールを守れないという状況をなくす。まずビルドツールでビルド手順をスクリプト化してから、Jenkinsによりソースコードの場所を設定し、ビルドのトリガを決め、ビルドツールによりビルドを実行させる。実行結果はレポートとして出力することができる。更に、コード検査やテスト実行とカバレッジ測定をビルドツールでできるようにしたりと、工夫次第でいろいろ拡張できる。このような解説がデモンストレーションを交えて行われた。

CIツールに限ることではないが、ツールで何を便利にできるか？を考えたうえで、ツールをどう活用すればよいか？ということを検討することは必要かつ楽しいことだと思う。今井氏も「アイディア次第で楽しいことができる」と語っていた。Jenkinsを使うことで何ができるだろう？と考えてみることから始めるのもよいかもしれない、そこからうまい活用法が見えてくるかもしれない、と思った。

事例発表
「Automator2 : Management Days」
浦山 さつき 氏

自動化させたテストの保守業務に対し、システムの追加や変更に対応しながら保守工数を抑える工夫について語られた。
統合テストを対象にすると開発フェーズに近すぎてテストの修正が追いつかなくなるため、テストの修正時間に余裕があるシステムテストを対象にした。また、新規の機能テストを対象とすると当然保守工数が増えてしまうため、保守工数の抑えられる回帰テストを自動化の対象とした。
自動化の実装時の工夫として、操作対象(どこに、どうする)をスクリプトにして、設定値(何を)と操作の順番をパラメータとして持たせ、変更箇所によりどこを直せばよいかを明確にした。
保守作業の流れについては、まず既存のテスト内容に対する影響を調査したうえで、影響箇所と規模を見積もる。この際に既存パラメータの変更箇所を調査するのにパラメータ調査ツールを用いた。スクリプト修正においては一括変換ツールを用いてパラメータの置換を行った。その後、環境作成ツール、試験管理ツール、結果取得ツールを用いてテストの修正に問題が無いことを確認したうえで、テストを実行した。ツールを活用することで変更による間違いが起きにくくなり、人の作業時間が短くなる。
このように、自動化のスコープを定め、自動テストを構造化し、ツールを活用することで、保守性を高めることができる。
更に、新しく追加されたサービスについては、バグが無く安定したタイミングで自動化させる、殺虫剤のパラドックスを避けるためにパターンの見直しをかける、という工夫も紹介された。

自動化に挑戦した事例発表に対し、保守の事例は比較的少ないと感じている。また、キャプチャ&リプレイツールを利用した自動化の事例はUIベースのテストを行っているテスト担当者にとって身近で参考になりやすいと思う。このような具体的な事例が今後もっと増えていくとテスト自動化の普及に繋がると思う。

招待講演
「クックパッドのテスト自動化」
高井 直人 氏

彼らが持つミッションをコストをかけずに実現するために、いかに無駄を取り除くか、そのために何をどのように自動化させるか、使えそうなツールや技術をどのように工夫して取り入れるか、事例紹介を交えながらそれらのヒントが語られた。
「毎日の料理を楽しみに」というミッションはどうやったらできるのか？「要件定義をする→要件に則した機能を設計する→ソフトウェアを実装してテストをする」というやりかたでは失敗する。妥当性確認が受託側の範囲から外れてしまう。成功するためには「ソフトウェアを使ってもらう→楽しみになったかどうかを調べる→どうやったらもっと楽しみになるソフトウェアを作れるかを考える」というやりかたを取り入れる。ソフトウェアが要求を満たしているかどうかは使ってみないとわからない。まず先に作り、使ってもらうことで「こういうのが欲しかったんだよ！！」と言ってもらえるものではないのか？
アイディアをもとに構築し製品を提供したら使ってもらって計測をする。計測データから学び次のアイディアにつなげる。このループに要する時間を最小化することが求められる。そのためにはソフトウェアの作り方の改善が必要である。作り方の改善でありがちなのが開発プロセス標準を定義してプロジェクトごとにテーラリングするというやりかたであるが、これでは現実の開発プロセスから乖離し、失敗してしまうことがある。成功させるために、リリース可能な状態にしてソフトウェアを開発する。その後変更を加えてからリリース可能な状態になるまでの無駄をなくす。このプロセスをループさせる。
ソフトウェアの生産性を向上させるための効果的な手法は「部品化(つくらないようにする)」「自動化(しないようにする)」「可視化(わかるようにする)」の3つであり、リリースに向かって必要な業務フローを定義し、そこで自動化できる箇所、部品化できる箇所、可視化できることを見つけていく。自動化は無駄をなくす行為であり、ソフトウェアをよく作るための手法である。そして無駄取りに投資効果というものはそぐわない。
クックパッドでは、BDDのためのテスティングフレームワークRSpecによる単体テストとWebアプリケーションのテストフレームワークCapybaraによるシナリオベースのテストを行っている。ソースコードフローはGitリポジトリに入れてチーム単位でコードレビューを掲示板のノリで楽しく行う。また、CIの時間がかかり過ぎないように分散テスト実行システムRRR Specを開発した。プロセス停止からの自動復帰、テスト実行順序の最適化、長いテストの投機的実行などの機能を持つ、オープンソースで公開されている。(詳細はhttp://techlife.cookpad.com/entry/2014/03/24/rrrspec/参照)
テストの品質にはお金をかけていない。機能の価値はリリースして初めて判るので過剰な先行投資はできない。従ってテスト設計に時間を費やさず、開発工程の後にはテスト工程は無い。その代わり本番環境でのダメージ・コントロールが重要になる。プロトタイプ開発用のプラグインChanko(詳細はhttp://techlife.cookpad.com/entry/2013/04/10/chanko200/参照)によりエラーが出たときに差し替える前の状態に自動的に戻すという仕組みを入れている。

講演全体を通して、「ユーザーの要求はリリースして初めてわかるため、構築・計測・学習のループの時間を最小化する。リリースまでのプロセスを定義しそこから無駄を取り除く」というメッセージが繰り返し伝わるのを感じた。
また、単に開発工程の後にテスト工程を設けていないわけではなく、テスト工程をなくすためにはどうしたらよいかを考えている。これはテストで品質を確保する姿勢があっては実現できないことであり、結果として自然にソフトウェアのつくりかたを改善するという活動に至ったのだろうと思った。単にテスト工程を考えるだけではなく、開発工程全体の中で何が求められているかを考えその中でテストをどう位置づけるか考えるという活動が、特にアジリティが求められるプロジェクトでは必須になるのではないかと思うし、そういう点でこの講演はとても参考になった。製品によってはリリースしてしまったらそれきりというものもあり、ユーザーのフィードバックを得にくいものもあると思うが、そこで思考停止するのではなく、ユーザーとの距離を近づけ、フィードバックを先に得られるための工夫を考える時期にきているのかもしれない。

情報交換会
「ゆる〜いパネルディスカッション」

ホワイトボードに貼られた参加者からの質問が書かれた付箋をもとに、パネリストから回答をいただき、会場からも自由に意見を述べられるという、オープニングディスカッションと同様の形式で意見交換が行われた。
仕様が不明なシステムに対してよいテストをつくるには？という質問に対しては、ユースケースを洗い出す、わからないなりに想定していく、こういう仕様が正しいのでは？と開発者とディスカッションする、という回答があった。
テストしやすい(あるいはテスト自動化しやすい)仕様については、形式手法の採用、レガシーコード改善ガイドを読んでみる、何でもできるようにする仕様はテストしにくいので制限をかけるようにする、という回答があった。
テストを作るタイミングについてのルールや経験則については、設計の段階で同時に考えると言う意見が多く、コードを書いてから後でテストを考える人もいるが、エキスパートであればテストファーストを今後使うであろう、という回答があった。
工数見積については、見積もりは外れるもので、大ハズレしたときに気づけるか、どう対策をとるかチームで話し合う、ということのほうが大事、と言う回答があった。