2019-06-25

「テストコードを書く？書かない？」ソフトウェアテストのいろんな疑問をテストのプロに聞いてみた

ソフトウェアテストはソフトの品質を高めるためには、欠かせない工程です。では、テスト・品質保証のプロたちは、どんなことに気をつけて、ソフトウェアテストを実践しているのでしょうか。仕様やスケジュール、テストの設計まで、テストにまつわる疑問を、ソフトウェアの品質保証・テストに特化した企業、SHIFT社のお二人にぶつけてみました。

「テストコードを書く？書かない？」ソフトウェアテストのいろんな疑問をテストのプロに聞いてみた

ソフトウェアへのバグの混入を防ぎ、ソフトウェアの品質を高めるためにはテストの工程が不可欠であり、「どうすれば良いテストを実施できるか」というノウハウもまた非常に重要です。では、テストを突き詰めて追求する、スペシャリストのノウハウとは。

今回はソフトウェアの品質保証・テストに特化した企業であり、テストを前提としたアジャイル体制構築のコンサルティングにも専門性を持つ、株式会社SHIFTの佐藤博之（さとう・ひろゆき）さんと谷岡俊祐（たにおか・しゅんすけ）さんに、テストを成功に導くために守るべき鉄則を教えてもらいました。

佐藤博之さん（写真右）: ビジトラ事業本部品質・技術統轄部技術推進部アジャイルファンクション。SIerで基幹システムの刷新プロジェクトに携わった後、SHIFTに入社し、アジャイル案件を中心にアジャイルテスターとして参画。現在はスクラムマスターとして基幹システム刷新プロジェクトに参画するほか、アジャイル案件を中心に行うグループのマネジメントに従事している。

谷岡俊祐さん（写真左）: ビジトラ事業本部品質・技術統轄部技術推進部アジャイルファンクション所属。SIerにて自治体向けシステム開発を上流からテスト、保守運用までを幅広く経験。SHIFT入社後、ECサイトのGUIテスト自動化や、CI環境構築、分散メッセージシステム構築などの自動化基盤構築を担当する。現在はアジャイル開発におけるQAチーム体制構築および継続的なリリースに対し、安定したシステムの提供を行なっている。

テストは要件定義の時点で始まっている。テスト実施前の課題にはこう対処する

——アジャイル開発の普及は、テストにどのような影響をもたらしましたか？

谷岡　すでに多くの企業で採り入れられていますが、アジャイル開発の大きな特徴は、イテレーションと呼ばれる期間を区切って仕様策定や開発、テスト、リリースを段階的に行うことにあります。

仕様策定からリリースまでを一方向的に行うウォーターフォール開発が抱える、「開発の終盤に致命的な問題が見つかり、大きな手戻りが発生する」というリスクが低減します。動くプロダクトを早い段階で作りあげることに、アジャイル開発の特徴があるからです。開発工程の終盤にあたるテストの担当者からすると、最低限の動作がテスト実施時には保障されているという安心感があります。

また、アジャイル開発では、イテレーションの期間に応じて機能の取捨選択をすることがあります。スケジュールに余裕のない場合、実装する機能を取捨選択することで開発やテストの工数に余裕を作れるようになります。

サービスの開発手法は、かつてはウォーターフォール一辺倒だったものの、近年ではアジャイルが用いられるケースが増えている。その潮流は、テストにどのような変化をもたらしたのか。その変化を踏まえたうえで、どうすればテストを成功に導けるのか。

佐藤　ウォーターフォール開発では設計や開発、テストなどの工程ごとに担当者が分かれているケースも多いでしょう。こうしたケースでは、前工程が抱えていた課題が後続の工程に引き継がれず、テスト実施の段階で問題が露見する、というリスクが考えられます。

アジャイルではチームメンバー全員がすぐ近くにいて毎日コミュニケーションをとりますから、プロジェクトで起きている異変がすぐに共有されます。その情報をもとにして「この機能のテストは厚めに実施しよう」「この仕様で本当に大丈夫かメンバーに確認を取ろう」というように、テストの実施内容をコントロールしやすくなります。

——いくつかの利点が生じているのですね。逆に、ウォーターフォールと比較してアジャイルが抱えている欠点はありますか？

谷岡　アジャイルにおいては「仕様が明確に定められていない」というケースが発生することも。ですから、テストの段取りを定める際も「明確な仕様がない」という前提を考慮する必要があります。

ウォーターフォール開発では、前工程が終わればドキュメントなどの形で仕様が明確に定義されますが、仕様がぼんやりした状態では開発にも悪影響がありますし、テストケースも適切に立てられなくなってしまいます。

——それを防ぐために、テスト担当者は何をすべきでしょうか？

谷岡　私が普段よくやっているのは「決まっていない仕様を決めてあげること」です。テストケース作成に携わるメンバーが、積極的に周りのメンバーを巻き込んでプロジェクトをファシリテーションし、仕様確定のために動きます。決まっていない状態の仕様を、いったん仮決めできるように努めます。

この段階で最終的な仕様をガチガチに固める必要はなく、こまめにメンテナンスをして、間違っていたら直すという前提で構いません。仕様が定義されることで、テストケースを立てやすくなりますから。

佐藤　仕様が不明確なままテストケースを書き始めることは、開発でいえば設計が固まらないままプログラムのソースコードを書き始めることに近い。テストも開発と同じように、作業の前段階での方針決定がとても大事になります。

——とはいえ、慣れていない方にとって「仕様を決めにいく」という行為は難易度が高いかもしれません。エンジニアが「仕様が不明瞭だ」と判断するためのコツはありますか？

佐藤　まず「ユーザーがどう使うか」をイメージすることをオススメします。システム上にあるボタンを例にします。

ユーザーがあるボタンを押す
↓
プルダウンメニューが展開される
↓
プルダウンメニューからユーザーは任意の項目を選択する
↓
項目選択後、画面遷移が発生する
↓
「そういえば、遷移先って定義されてたっけ？」と気づく

非常にシンプルですが、ユーザーの動きを想像することで、プロダクトの振る舞いが明確になり、その振る舞いを実現するための仕様も見えてきます。

私がメンバーと認識合わせをする際も、処理フローを説明してもらうことで、サービスについての理解を深めてもらうことも多いです。完全に理解していなければ、人に説明はできないので。

——処理フローを他のメンバーに共有する際に、どんな手段を用いれば情報が伝わりやすくなるでしょうか？

谷岡　私は100均で買えるような小さなホワイトボードを常に持ち歩いています。テストにおける処理フローの確認だけではなく、さまざまな情報を可視化して共有するのに便利なんです。絵を描くことで自分の頭のなかも整理されますし、他のメンバーにも情報が伝わりやすくなります。

——試しに、普段どんな絵を描いているかサンプルを示してもらってもいいですか？

谷岡　例えば画面仕様を説明するときは、こういう感じに画面を描いて……。どういうボタンを押すことでどう画面が遷移するのか。最終的にユーザーが入力した情報がどんなフローを経てデータベースに格納されるのか、などをこういう図で示しています。パソコンを立ち上げて説明するよりも、さらっと絵を描いた方が早いし伝わりやすいケースも多いです。描いた絵は写真を撮ってSlackに貼っておくと、さらに共有しやすくなります。

佐藤　自分が頭のなかで想像しているものと他の人が頭のなかで想像しているものは違うことが多いです。そのズレた認識を合わせるうえでも図を描くことは有効です。