「テストコードを書く？書かない？」ソフトウェアテストのいろんな疑問をテストのプロに聞いてみた
ソフトウェアテストはソフトの品質を高めるためには、欠かせない工程です。では、テスト・品質保証のプロたちは、どんなことに気をつけて、ソフトウェアテストを実践しているのでしょうか。仕様やスケジュール、テストの設計まで、テストにまつわる疑問を、ソフトウェアの品質保証・テストに特化した企業、SHIFT社のお二人にぶつけてみました。
ソフトウェアへのバグの混入を防ぎ、ソフトウェアの品質を高めるためにはテストの工程が不可欠であり、「どうすれば良いテストを実施できるか」というノウハウもまた非常に重要です。では、テストを突き詰めて追求する、スペシャリストのノウハウとは。
今回はソフトウェアの品質保証・テストに特化した企業であり、テストを前提としたアジャイル体制構築のコンサルティングにも専門性を持つ、株式会社SHIFTの佐藤博之（さとう・ひろゆき）さんと谷岡俊祐（たにおか・しゅんすけ）さんに、テストを成功に導くために守るべき鉄則を教えてもらいました。
- 佐藤博之さん（写真右）
- ビジトラ事業本部 品質・技術統轄部 技術推進部 アジャイルファンクション。SIerで基幹システムの刷新プロジェクトに携わった後、SHIFTに入社し、アジャイル案件を中心にアジャイルテスターとして参画。現在はスクラムマスターとして基幹システム刷新プロジェクトに参画するほか、アジャイル案件を中心に行うグループのマネジメントに従事している。
- 谷岡俊祐さん（写真左）
- ビジトラ事業本部 品質・技術統轄部 技術推進部 アジャイルファンクション所属。SIerにて自治体向けシステム開発を上流からテスト、保守運用までを幅広く経験。SHIFT入社後、ECサイトのGUIテスト自動化や、CI環境構築、分散メッセージシステム構築などの自動化基盤構築を担当する。現在はアジャイル開発におけるQAチーム体制構築および継続的なリリースに対し、安定したシステムの提供を行なっている。
テストは要件定義の時点で始まっている。テスト実施前の課題にはこう対処する
——アジャイル開発の普及は、テストにどのような影響をもたらしましたか？
谷岡 すでに多くの企業で採り入れられていますが、アジャイル開発の大きな特徴は、イテレーションと呼ばれる期間を区切って仕様策定や開発、テスト、リリースを段階的に行うことにあります。
仕様策定からリリースまでを一方向的に行うウォーターフォール開発が抱える、「開発の終盤に致命的な問題が見つかり、大きな手戻りが発生する」というリスクが低減します。動くプロダクトを早い段階で作りあげることに、アジャイル開発の特徴があるからです。開発工程の終盤にあたるテストの担当者からすると、最低限の動作がテスト実施時には保障されているという安心感があります。
また、アジャイル開発では、イテレーションの期間に応じて機能の取捨選択をすることがあります。スケジュールに余裕のない場合、実装する機能を取捨選択することで開発やテストの工数に余裕を作れるようになります。
サービスの開発手法は、かつてはウォーターフォール一辺倒だったものの、近年ではアジャイルが用いられるケースが増えている。その潮流は、テストにどのような変化をもたらしたのか。その変化を踏まえたうえで、どうすればテストを成功に導けるのか。
佐藤 ウォーターフォール開発では設計や開発、テストなどの工程ごとに担当者が分かれているケースも多いでしょう。こうしたケースでは、前工程が抱えていた課題が後続の工程に引き継がれず、テスト実施の段階で問題が露見する、というリスクが考えられます。
アジャイルではチームメンバー全員がすぐ近くにいて毎日コミュニケーションをとりますから、プロジェクトで起きている異変がすぐに共有されます。その情報をもとにして「この機能のテストは厚めに実施しよう」「この仕様で本当に大丈夫かメンバーに確認を取ろう」というように、テストの実施内容をコントロールしやすくなります。
——いくつかの利点が生じているのですね。逆に、ウォーターフォールと比較してアジャイルが抱えている欠点はありますか？
谷岡 アジャイルにおいては「仕様が明確に定められていない」というケースが発生することも。ですから、テストの段取りを定める際も「明確な仕様がない」という前提を考慮する必要があります。
ウォーターフォール開発では、前工程が終わればドキュメントなどの形で仕様が明確に定義されますが、仕様がぼんやりした状態では開発にも悪影響がありますし、テストケースも適切に立てられなくなってしまいます。
——それを防ぐために、テスト担当者は何をすべきでしょうか？
谷岡 私が普段よくやっているのは「決まっていない仕様を決めてあげること」です。テストケース作成に携わるメンバーが、積極的に周りのメンバーを巻き込んでプロジェクトをファシリテーションし、仕様確定のために動きます。決まっていない状態の仕様を、いったん仮決めできるように努めます。
この段階で最終的な仕様をガチガチに固める必要はなく、こまめにメンテナンスをして、間違っていたら直すという前提で構いません。仕様が定義されることで、テストケースを立てやすくなりますから。
佐藤 仕様が不明確なままテストケースを書き始めることは、開発でいえば設計が固まらないままプログラムのソースコードを書き始めることに近い。テストも開発と同じように、作業の前段階での方針決定がとても大事になります。
——とはいえ、慣れていない方にとって「仕様を決めにいく」という行為は難易度が高いかもしれません。エンジニアが「仕様が不明瞭だ」と判断するためのコツはありますか？
佐藤 まず「ユーザーがどう使うか」をイメージすることをオススメします。システム上にあるボタンを例にします。
↓
プルダウンメニューが展開される
↓
プルダウンメニューからユーザーは任意の項目を選択する
↓
項目選択後、画面遷移が発生する
↓
「そういえば、遷移先って定義されてたっけ？」と気づく
非常にシンプルですが、ユーザーの動きを想像することで、プロダクトの振る舞いが明確になり、その振る舞いを実現するための仕様も見えてきます。
私がメンバーと認識合わせをする際も、処理フローを説明してもらうことで、サービスについての理解を深めてもらうことも多いです。完全に理解していなければ、人に説明はできないので。
——処理フローを他のメンバーに共有する際に、どんな手段を用いれば情報が伝わりやすくなるでしょうか？
谷岡 私は100均で買えるような小さなホワイトボードを常に持ち歩いています。テストにおける処理フローの確認だけではなく、さまざまな情報を可視化して共有するのに便利なんです。絵を描くことで自分の頭のなかも整理されますし、他のメンバーにも情報が伝わりやすくなります。
——試しに、普段どんな絵を描いているかサンプルを示してもらってもいいですか？
谷岡 例えば画面仕様を説明するときは、こういう感じに画面を描いて……。どういうボタンを押すことでどう画面が遷移するのか。最終的にユーザーが入力した情報がどんなフローを経てデータベースに格納されるのか、などをこういう図で示しています。パソコンを立ち上げて説明するよりも、さらっと絵を描いた方が早いし伝わりやすいケースも多いです。描いた絵は写真を撮ってSlackに貼っておくと、さらに共有しやすくなります。
佐藤 自分が頭のなかで想像しているものと他の人が頭のなかで想像しているものは違うことが多いです。そのズレた認識を合わせるうえでも図を描くことは有効です。
テストも設計が大事！テストを良い方向に導く判断軸を知ろう
——近年では、「テストコードを書くこと」がとても重視される印象があります。どんな基準で、テストコードを書く・書かないを区別すべきでしょうか？
谷岡 私は「必ずしもテストコードを書くことが正解とは限らない」と考えています。例えば、開発最初期で仕様がまだ固まっていないようなシステムの場合、テストコードを書いても次の週には仕様が変わっていることもあるでしょう。
そうすると、テストコードのせいでかえってメンテナンス工数が大きくなってしまい、本当に力を入れたかったテストに時間を割けなくなる可能性が出てしまいます。この場合は、まずは手動でテストを実施して大きなバグを潰していく方が効果的でしょう。その後システムが安定してから、改めてテストコードを実装していく手法も検討できます。
佐藤 「テストコードを書いたほうがいい」というケースはさまざまですが、「テストの内容を人が忘れないように、テストコードによって再現性を担保しておく」という視座があることをお伝えしておきたいです。例えば、たまにしか実行されない処理のテストをテストコードによって記録しておくと、仮にメンバーが入れ替わってもテストを実施し続けられます。忘れてしまいやすいテストの手順を自動化しておくんです。
テストコードを書く際、「何を目的としてテストコードを書くのか」という方向性を明確に定めておくことがかなり重要です。「とりあえずテストコードを書きました」という状態だと、メンテナンスされなくなり負の遺産になってしまう可能性があります。
——そもそも技術的負債を防ぐために作ったはずのテストコードなのに、それ自身が負債になってしまうのですね。
谷岡 中長期的な目線を持たなければ、テストコードを書いたイニシャルコストは回収できないケースが多いです。
佐藤 テストの自動化をすることは1つのシステムをつくることと同じなので、「何を自動テストによって保証して、何をテストしないのか」を決めておかなければダメなんです。
——テストのスケジュール見積もりは、慣れていない人にとって難しい作業のひとつです。どうすれば見積もりの精度をあげられるでしょうか？
佐藤 テストケースがすでにできている場合は、試しに1ケース分をテストしてみて「1ケースのテストにかかった時間×全体のケース数」を計算することが効果的になります。仮に1ケースあたり3分かかって全体で100ケースあるならば、だいたい300分くらいかかることが概算でわかります。もちろん多少のズレは生じますが、こうして算出した時間は見積もりの大きな指針になります。
——テストケースがまだできていない場合はどうすればいいでしょうか？
佐藤 私たちが普段よくやっている方法としては、どのくらい時間がかかりそうかを複数人でプランニングポーカーのように提示し合うことが多いです。プランニングポーカーならぬテストケースポーカーというか（笑）。ポーカーによって複数の視座が集約され、見積もりの精度を高められます。
——有効そうですね。他に、見積もりの精度を上げるために効果的な手段はありますか？
谷岡 見積もりの精度を上げるには経験を積むのが一番ですが、経験を“効果的に”積むための方法はあります。「立てた予定に対して実績はどうだったか」の振り返りをすることです。
「1ケースあたり3分でできると思っていたけれど、実は5分だった」なのかもしれないですし、その逆に「1分でした」なのかもしれません。予定と実績を照らし合わせたうえで、「なぜその乖離が出たのか」を考えていくことが、見積もりの精度を向上させるための訓練になります。
——一定のスケジュール内でテストを終わらせるには、テストをどう立てるかと同じくらい「ケースをどう効果的に減らすか」も重要な観点です。どのように減らされていますか？
谷岡 私はそれぞれの機能ごとにテストの優先順位づけをします。実施するものとそうでないものの取捨選択をするわけです。無限に時間があればすべてのテストをやりたいですが、現実には限られた時間のなかで効率的にテストを実施していかなければならないですから。
——例えば金融系のアプリだと、送金や金額計算などの機能はしっかりテストケースを立てるけれど、ユーザーのお金に影響のない機能はテストケースを少なめにするような感じですね。
谷岡 テストケースを立てるにあたり大事なことは、「その機能のテストをしなかったとしたら、サービスにはどれくらいの影響度があるか」という相関性を考えることです。それを考えられていれば、「コアの機能についてはテストケースを減らさず、そうでない機能については品質に大きく影響しない範囲でテストケースを減らす」といったことができようになります。
——良いテストケースを作成するために、エンジニアが身につけるべき手法はありますか？
谷岡 一般的なテストケース作成の手法として同値分割や境界値分析などを知っておくのはもちろん大事なのですが、それ以前の話として「Issueが発生した背景やプロジェクトの状況」などの情報をメンバーに正確に知ってもらうことが非常に大事です。
そうした情報がうまく共有できていないと、どれだけテストケース作成の手法だけを覚えていたとしても品質は下がってしまう。逆にいえば、その軸が理解できていればどんなケースを立てても大きく外れることはありません。
——どうすれば、そうした情報をメンバーが正しく理解できるようになるでしょうか？
谷岡 私の場合は、Issueが発生した背景やプロジェクトの状況などの情報をとにかく朝会（デイリースクラム）で共有しています。過去に何があって、今日はこういうことがある予定で、今後はこういうことが起こりうるということを。
それだけでも、テストにおいて何を重視してケースを立てるべきか、メンバーが把握しやすくなります。テスト実施時にも「過去にこういうことがあったから、ここを入念にチェックしよう」という感じに意識が変わるはずです。
佐藤 私は開発・QAのメンバーをみんな集めて「この機能をテストする予定なんだけど」と情報共有したうえで、全員で方針についてディスカッションすることも多いです。これは適切なテストケース作成のためにも有効ですし、チームビルディングにも役立ちます。ディスカッションに例え半日使ったとしても、その後のアウトプットの質が全く変わってくるので、無駄にはなりません。
テスト実施の際に出てくる課題と、その解決策
——テストでバグが見つかった際には、プロジェクト管理ツールを用いてバグチケットを起票することが一般的です。チケットにはどんな内容を書いておくべきですか？
谷岡 バグの持つ“背景”ですね。なぜそのバグが入り込んだのか、なぜ検出できたのかなどを書いてもらえると本当に助かります。その情報がないと、バグの再現や修正に支障が出ることが多々あるんです。
佐藤 それから、私はバグ報告に再現動画を使うことも多いです。例えばiPadは画面を録画できるので、バグチケットのなかに「こういうことが起きました。詳しくは動画を視聴してください」という感じに書いておきます。この方法は再現手順もわかりやすいですし、パフォーマンス遅延などを伝えるときは文章よりも効果的になります。
テストは究極にクリエイティブな仕事
——最後に、お二人が「品質保証・テストを専門にしてきてよかった」と思うことについて教えてください。
谷岡 私たちは普段、お客さまの現場に参画してテストを担当しているのですが、スプリントの振り返りをするときに「プロジェクトに入ってもらえて本当によかった」「テストを担当してもらえてから品質が上がった」といった声を頂けると、この仕事をやっていてよかったと感じられます。
また、テストを成功させるにはいろいろな部署と関わりながら広い視野を持って仕事をする必要があるので、そういう意味でもやりがいがあります。お客さまと一緒にシステムを愛して、そのシステムと並走しながら仕事をしていく感覚を得られるというか。システムの信頼に直結する“品質”を支えられるということは、この仕事の素晴らしいところだと思っています。
佐藤 私は、コードを書くことと同じように、テストもクリエイティブな仕事だと思っています。品質と工数のバランスを取るために「こうすれば品質を落とさずにより少ない工数でテストできる」とか「○○を直したら△△にも影響するから、こういう方針で行こう」など、さまざまなことを総合的に考え続けておく必要があるからです。
「テストは単純な作業を担当する下流工程」と考えるのか「ソフトウェアの品質を支える総合力が求められる仕事」と考えるのかで、テストのやりがいは全く変わってきます。私は後者だと思っていますし、テストは本当にクリエイティブな仕事だと感じています。
——テストはクリエイティブ、とは印象的なフレーズですね。
谷岡 テストはソフトウェア開発のあらゆる工程に影響しますからね。それに、テスト担当者は各機能の動作を詳しく理解しているので、開発・QAチーム以外の他部署の方々から相談してもらえることも多いんです。だから「単なる作業だ」と思ってテストをするのでなく、より高い視座を持ってテストに取り組んでほしいです。
佐藤 ちょっと目線を上げるだけで、見えてくるものが全然違ってきますからね。「なぜこのテストを実施するのか」「どうすればテストを成功に導けるのか」を徹底的に考え続けることで、テストの成功率も、プロジェクトの成果も違ってくると思います。
——テストの持つ奥深さが伝わってきました。今回はどうもありがとうございました！
取材・執筆：中薗昴
