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

基調講演
「Test Yourself－テストを書くと何がどう変わるか」
和田 卓人（タワーズ・クエスト）

和田氏は、プログラマー、経営者、コンサルタント、OSS開発者と様々な顔を持つが、軸はプログラマーである。大学時代ソフトウェア工学を専攻しており、良い分析・設計をしてからプログラミングすると良いシステムができると教えられてきたが、実社会で適応しようとすると難しいことであると気付いた。どの段階になれば良い分析・設計になったかという確信が持てず、設計から抜け出すフェーズにならない。納期があるからとコードを書き始めると、考えが足りなくてダメだったことや、もっとシンプルな設計になると気づくこともあった。そこでコードを書きはじめてから設計を考えたらよいのではないかと考えた。
そこでテスト駆動開発(以下TDD)という開発手法を選択した。TDDではサイクルが重要である。TDDのサイクルは目標を考え、その目標を示すテストを書き、そのテストを実行して失敗させる（Redという）、そこで簡単なコードでいいので目的を達成するコードを書き、テストコードを成功させる（Greenという）。Greenになれば、機能を満たしているコードがかけているということなる。次にテストが通る（Greenになる）状態でリファクタリングを行う（Refactorという）。このループを繰り返すことで、開発を進めていく手法がTDDである。
TDDでは適切な量の設計、フィードバックを考えることが大事であり、もっとも大事なフェーズはリファクタリングであると和田氏は考えている。

FizzBuzz問題での公開デモ

ポイントは以下の通り

• 問題文をtodoリストに小さく分解する
• 1つのtodoリストの大きさが同じになるように分解する
• テストクラスの命名には「Test～」「～Test」の2流派が主である
  • 実装（Product）コードとテストコードが1対1になる場合は「～Test」
  • 実装コードとテストコードが１対多になる場合は「Test～」
• クラス名、メソッド名には日本語を使用する（可読性を意識した結果）
• テストコードはゴールから書き、プロダクトコードはそれを通過するだけ（1を返す）の実装を書く
• テストはメソッドを増やす書き方を行う（Assertを増やす書き方の方がコード行を少なく書けるが、分離性がないため）
• 慣れてきたらテストコードとプロダクトコードを書く手順は不安の度合いに応じて変化させてよい
• 仕様とのレイヤーをあわせるためテストコードを入れ子にする

TDDを行う上で大事なポイント

• 最も大事なのはリファクタリング
• RedやGreenではカイゼンができない
• TDDはスキルであり、練習すればできるようになる

TDDのT（テスト）はCheckingだと思っている。TDDはプログラミングのやり方なのでテストではない。やはり第三者の視点は必要で、テストエンジニアは開発者と違う視点を持っているので開発者がテストを書いていたとしてもテストエンジニアは必要である。
体重計に乗るだけでは体重がわかるだけで痩せないのと同じで、システムもテストをするだけでは品質はあがらない。実装や開発にフィードバックを行い、システムを直さなければならない。
TDDの良い所はカイゼンを我慢しなくても良くなったこと。動くコードに触れないようにコピペして作業しているとどんどんコードの質は悪くなってくる。TDDをやっていると即座にフィードバックを得ることができ、フィードバックにより書いたコードに自信が持て、これから書くコードに自信が持つことができる。自分が考えている動作に対しては少なくとも正しいことがわかり、それが自信になる。
プログラマーにはテストの知見がなく、どのくらいの組み合わせテストをすればいいか、どんなテストを行えばよいかわからず不安を抱えており、テスターと一緒にペアプログラミングをやりたいと思っている。テスターとプログラマーが分離しているのは不毛であり、お互いにフィードバックして欲しいという言葉でまとめた。

事例発表
「作る・流すだけじゃない！テスト自動化を運用に乗せる為のもう一工夫」
－ECサイト評価チームが実現したテスト自動化の運用例－
横田 貢（株式会社　SHIFT）

設計全般を担当している横田氏はECサイトの構築パッケージでバックエンドとフロントエンドのテスト全般を行っている。短期間開発サイクルに対応したテスト実施を迫られているが、テスト対象機能は増え続けている。前バージョンの機能も保証しなければならず、バージョンアップ毎に対象機能は増えるのでテストの自動化は必須となる。
テストケースが増え続ける中で、戻りが発生した場合のテストケースの修正工数不足が問題となっているが、その解決としてテストケースを共通化、部品化するようにした。すべてのテストシナリオを施策対象とせず、ECサイトで特に重要な金額計算機能、データ連携機能、商品機能などのシナリオ400本中105本を施策対象とした。SeleniumIDEで作成した1672件のテストケースの中で660程度共通パーツ化することができた。

ライトニングトークス
「モバイルアプリ開発体制の継続的改善」
松尾　和昭（クックパッド株式会社）

クックパッドではスマートフォンでの利用者数が増加している。今までWeb開発の成功体験をもとにモバイル開発を行っていたが同じようにいかず、品質問題が多発した。そこで開発プロセスと開発体制という２つの柱の見直しを行った。

開発プロセスの変化

以前は機能からリリース日を決めていたが、現在はリリース日を決めてから機能を決めるようにした。そこで、開発者とQAによる振り返りを設け、さまざまな視点から開発を進めるようになった。

開発体制の変化

以前はサービス部門→モバイルファースト室→QAへと開発フローを流していたが、現在はサービス部門とモバイルファースト室各々がQAと連携することにより、不具合の作りこみを事前に予防できるようになった。

チュートリアル
「テスト設計チュートリアル-」
安達 賢二、吉澤 智美（ASTER（ソフトウェアテスト技術振興協会））

テスト要求分析ではどんなテストが必要かを分析する。要求仕様書などのインプットになる情報（JSTQBではテストベース）は、できる限り入手する。要求系、社内の標準とか規格をヒアリングしながら明らかにしていく。テストベースとなり得るものが入手できないときは、ステークホルダーになりきって要求を明らかにする。
テスト要求分析で形をはっきり拾い上げないと、アーキテクチャはできない。自分とステークホルダーが納得するまで、積極的に当事者意識を持ち実感を伴うテスト要求を考える。シーケンシャルに考えると見直しを怠ってしまうため、サイクルで考える。
テスト要求を明らかにしていく際に、本当にそれで全部なのか見えていない所を明らかにしていく。テストケースから要求を整理するのは量が多く不可能なので、モデル化を行う。
トップダウン型はトップからどんどん詳細化を行い、ボトムアップ型はどんどん抽象度をあげていく。トップダウン型とボトムアップ型を循環させてモデリングしていく。ドメイン知識も入り混じっているので、簡単な問題ではない。
モデリングテクニックとして、全部でない場合は「その他」を置いてみることでモデリングができる。でき上がったものがMECE（漏れなくだぶりがない）になっていること。階層構造を作り、繋げることでMECE性を高めていく。わからないところは「その他」と置き、確実にMECEであると確認できたところで確定する。
全てテストする必要がないもの、場合によっては代表的なもの１つでよいと判断する場合がある。その場合代表１つだけにする（剪定）。このとき、適当に決めるのではなく、何をテストして、何をテストしていないかをはっきりすることが大事である。
大量なデータを処理速度と応答時間とでモデル化しようとして、そのまま書いてしまうと線が大量に出すぎたりして、ごちゃごちゃしてわからなくなる。そこで抽象度を上げることで線がごちゃごちゃしづらくなる（これを観点統合という）。観点分割としては、負荷は他にも大量データの流し込み、高頻度や厳しいタイミングで発生するなど色々ある。
このようなものはいたずらにただ並べるだけでなく、どういったものがあるか、必要・不必要という判断をする。
コンテナモデリングは全体を俯瞰して把握できるやり方がよい。分割したり、統合したり、ストーリー立てて考えるのがコンテナモデリングであり、箱（コンテナ）と箱の関係が疎になるようにする。テストコンテナをどんどん使いやすくすることが大事。

テスト要求分析のまとめ

1. 要求の源泉の準備をする。ヒアリング、どんな人が使うのか、ソースコードの構造とか
2. 要求の獲得と分割を行う。分類、テストケースにつながるもの
3. モデルの構築と納得

テスト詳細設計

ここまで要求分析などを論理的に考えつくしているはずなので、テスト詳細設計では頭を使わなくてもいいはずであるが、たとえばゆもつよメソッドではテスト詳細設計にも重きを置いている。
テストケースは他の人が見て、何がやりたいかわかる場合とわからない場合というのがよくあり、それはテスト観点が明確でないためにわからないことが多い。その場合、後々使い勝手のよいテストケースになっていない。テスト詳細設計は機械的に行っていくのが基本だが、意見がわかれる話である。
一から全てやろうとするのは難しいので、できそうな所から始めたらいいと吉澤氏は言う。腕の良いエンジニアは難しくモデリングしない。

まとめ

安達氏は参加者自身がやりやすく効果があるものの一つとして足掛かりになれば嬉しい、身に着けなければならないことはたくさんあるし、そのためにテスト設計コンテストなどを使って、みんなで競って切磋琢磨すれば世の中に貢献できるのでは？と言い、吉澤氏はテスト設計コンテストに参加することで審査員からの評価がもらえる、決勝チームの全資料が届く、各審査項目にしたがってのコメントが届くなどの特典もあるのでお勧めすると述べた。

クロージングセッション
上田 和樹（JaSST Hokkaido 実行委員会)

クロージングセッションは実行委員長である上田氏が行った。事前アンケートから北海道での現状を説明した。JaSST北海道を開催した当時は「ソフトウェアテスト」という名前も知らない人がいた。「北海道という地域としての特色、課題がある中で、北海道の技術者として、『これから我々がどうしていくか』を考えたい。今日のシンポジウムで参加者自身が楽しめたり、わくわくできたりしたのであれば嬉しい。JaSST北海道は来年で10年になるが、私たちは開催することしかできない、北海道のみなさんで地域を盛り上げていきましょう」と締めくくった。

まとめ

今年のJaSST北海道は新実行委員長のもと「現場が喜ぶソフトウェアテスト」をテーマに行われたが、現場の様々な視点からの発表があった。また、それぞれの現場で開発者とテストエンジニアが相互に協力することが大事という一貫したメッセージが伝わり、参加者それぞれが何か持ち帰ることができたシンポジウムになったのではないかと思う。
来年で10周年ということで、さらに次のステージへ進むシンポジウムになることが期待できると感じた。