大変・面倒・不安なアプリテストを幸せにする方法
はじめに
本書の読者
アプリのテストに関わる方を対象としています。特にテストマネジメントをしている方、テストリーダを目指したい方、要するにテストで痛い目にあっている方を対象としています。
・QA担当者
・テストリーダ
・情シス（情報システム部）
・ソフトハウスのリーダ
・PM
・SE
・PG
テスト系エンジニアって稼げるの？
これ重要ですよね 笑
3年前に転職活動しているときに、ポートフォリオやスキルシートに「品質」と記載したら、モテました。
もちろん、裏付け（私の場合は数千万規模のウェブアプリ開発でリリース後バグなしリリースと前職で品質保証部を立ち上げしたこと）が重要です。
ただ、いろいろなプロジェクトを見ていると、テストマネジメントに課題があることが多いので、テストマネジメントをできるのもポイントになります。
個人的にはユニットテスト・UIテストなど「テスト自動化」をリードできるとより価値があるエンジニアと思います。
両方できたら最強ですが、分業も進んでいるので、ゼネラリストならマネジメント、スペシャリストならテスト自動化もできるのを目指しましょう。
そもそもお前は誰だ？
※ 興味のない方は飛ばしてください
私は亀井亮介と申します！
山形大学工学部情報工学化を留年しつつ卒業後にIT業界に入りました。
大学時代はPerlを使っていました。
ブラックな環境でUNIXサーバに囲まれながらテストする日々からエンジニアとしてのキャリアがスタートさせ、ブラックから抜け出した後はJavaのプログラマ（バージョン1.4！）をしたり、要件定義・設計のサポートをしたり…
その後、家庭の事情で、引越しすることになり、引越し先でIT企業がなく、2年ほど製造業にいました。
その後、沖縄に移住しウェブプログラマ（PHP）に復帰し、5年ほど務めた後フリーランスのエンジニアになりました。
フリーランスになってからはプレイングPMとして要件定義・設計・実装・テストまでマネジメント＋実作業したり、炎上案件の火消しをしたりしました。
積立投資の先駆けとなったインヴァスト証券のマネーハッチの開発に携わり、PM兼プログラマーとしてリリース後数ヶ月バグなしを実現しました！
（当時プロダクトオーナーから名前出していいよと合意したので記載しています。もし、状況変わったら取り下げます。）
その後、キャリアアップを目的にIT組織マネジメントしたいと思い、開発会社に入りました。
そこでこの3年ほど、資本金9,000万円、従業員80名ほどの開発会社で、常時15件前後ほどプロジェクトが回っている状態の品質保証部を立ち上げと品質向上試作立案と遂行をおこなっていました。
その経験を活かしこの記事を書いています。
プライベートでは3人の子供の父であり、曲作りやガンプラ作り、プロレス・総合格闘技・キックボクシング観戦（ネット課金が…笑）を楽しみながら過ごしてます！
テストって大変・面倒・不安
アプリのテストにどのようなイメージを持っていますか？
・大変
・面倒
・リリース後不安
こんなところでしょうか？あまりいいイメージを持っている方は少ないと思います。
リリース後にバグが出ないか不安になるし、追加・改修時に何度も同じようなテストをするので退屈です。
また、アプリ発注側の立場だと、「『バグはありません』と担当者がいっているのにリリース後にバグが多発する」ということも多々あります。
なぜこのようにテストは大変で、面倒なテストをしなければならないのでしょうか？
リリース後にバグを出さないためのテスト
サービスリリース後にバグがあると機会損失したり、風評被害が発生する可能性があります。
例えばみなさんが使っているサービスにバグがあったらどう思いますか？
・動画サイトでお金を払っているのに動画が見れない
・マッチングアプリで違う人にメッセージが送られた
「金返せ！」となり解約するだろうし、「あのサービスダメだ」と話をするだろうし…
このような機会損失や風評被害など不利益を防ぐためにテストをします。
また、問題が起こるたびに同じような問題を繰り返さないためにテストの質・量ともに増えてしまいます。
ヌケやモレがなく、効率よくテストをすることが求められます。
本書の目的
極端な話をすれば「ユニットテスト（APIも含む）」を書いて、プログラムをきれいに保ち、UIテスト自動化をすればアプリの品質はだいぶ上がるので、根本的には上記を遂行すれば良いのですが、なかなか上記のような状況ではないことが多々あると思います。
本書は困っている方のために「テストの進め方」と「実践的なテストマネジメント」にフォーカスを当てます。
「1章 困った！アプリあるある」ではアプリ開発におけるテストの問題や課題を整理し、どのような状態が良いかを示します（あるべき姿とかTo-beともいいます）。
「2章 テストで幸せになるためのプロセス」ではテストの進め方・プロセスを説明します。
「3章 モテるテストリーダーになるために」では実践的なテストマネジメントのやり方・分析手法や分析観点を説明します。
テストがうまくいけばみなさんのストレスが減ります。胃薬になれれば幸いです！
1章 困った！アプリ開発あるある
1-1. バグがないアプリはない！
「よし！これだけ網羅してテストをして、バグがなければ完璧だぞ！」
「コストはかかるし納期が…」
「品質に勝るものはないのだ！」
リリース後
「バグが出ました！」
「ひぃ」
バグがないアプリはありません。必ず何かしらのバグが出ます。バグがでないアプリを目指すのは費用対効果が薄く、納期も圧迫され、プロジェクトメンバー全員が疲弊します。
解決：バグは早く見つけて早く直す
バグがあっても早く見つけて早く直せばよいのです。そのためにはなるべく早い段階でバグを見つけて、直せば良いです。
一番は開発・製造中にユニットテストを書くことです。いつでもテストをしてくれるのでデグレートを防ぐことができます。
しかし、古いアプリで元々ユニットテストがない場合やそのプロジェクトの文化的にユニットテストがない場合もあるでしょう。
その場合は、単体テストからしっかりテストをすることです。
ユニットテストについては「2-4. テスト自動化」で説明し、テストの進め方に関しては「2-2. テスト設計」「2-3. テスト仕様書」で説明します。
1-2. アプリは時間が経つと劣化する！永遠に変わらないアプリはない！
「よし！アプリがリリースしたぞ！」
「バグもなくて順調です！」
数年後
「また、バグが発見されました！」
「なんだと…今月何回目だ？原因は？」
「あのぅ…そのぅ…昨日リリースした画面が原因で、別の画面で動かなくなりました」
「テストはしていないのか？」
「はい…全く関係ないと思い込んでいたらしく」
一度リリースしたアプリでも利用者のニーズや外部環境の変化で追加開発や改修が発生します。
この時の変化に対応できなければ、リリース直後は良かったシステムも劣化します。
解決：変化に迅速に対応するにはマネジメントが重要
常に変化するアプリにどのように対応したら良いのでしょうか？
いつでも追加・改修ができるようにリファクタリングをして品質を保ちます。
プログラムに1行でも変更があれば、テストをやり直す必要があります。
もちろん、追加・改修するときにもテストをやり直します。
繰り返しテストをできる状態でないと変化に対応できません。
このときにもユニットテスト・APIテスト・UIテストが自動化されていればそれに越したことはありません。
しかし、テスト自動化されていない場合は、手動でテストをしなければなりません。
コスト・リソース（人）は有限なので、効率よく、生産性が高いテスト環境を構築する必要があります。
「3章 モテるテストリーダになるために」にで記載します。
1-3. テストは無限にできる！
テスト仕様書を書いていてこのような経験はありませんか？
「このパターンがあるということは…他の画面でもテストしないとな」
「あれ？このセレクトボックスで挙動が変わるってことは、全パターンやる必要ある？」
また、リリース後にバグが出ると
「再発防止策として全画面に展開すること」
（また、テストケースが増えた）
上記のようにテストケースはキリがなくなりますが…
「このテストケース数だと納期に間に合わない」
「費用がいくらあっても足りない」
「人もいない」
テストは無限にできますが、納期・費用（コスト）・人（リソース）は有限です。
不安になればなるほど、テストケースは増えます。
テストをする際に費用対効果や納期・リソースを考慮する必要があります。
解決：費用対効果の高いテストするのは計画と手法が重要
不安になればなるほどテストケースは増えて、納期を遵守できない、費用がかかり赤字になる、人手が足りない、疲弊するので辞めてしまう…
まさに悪循環になります。
このようなことが起こらないためにテスト計画を策定し費用対効果の高いテストを目指します。
テスト計画は「2-1. テスト計画」に詳細を書きます。
また、テスト仕様書を書くときに「同値分割」「境界値分析」などのテスト手法を使い、必要最低限のテストを目指します。
「2-2. テスト設計」「2-3. テスト仕様書」に詳細を書きます。
そもそも、手動でテストするには多大な労力が必要となるので、テストを自動化します。
テスト自動化は「2-4. テスト自動化」に詳細を書きます。
しつこいですが、テスト自動化は一番効果が高いのでおすすめです。
1-4. 後工程になればなるほど改修コストがかかる！リリース後はなおさらコストがかかる！このアプリリリースしていいの？
リリース前
「バグが出ました…」
「改修して、テストして」
次の日
「また、バグが出ました。改修したところとは別です」
「え？まだまだバグがあるのでは？来週リリースできるの？」
このように、リリース直前にバグが連鎖的に見つかります。
改修をした箇所の影響範囲が未考慮だったり、プログラムに依存関係があったりするからです。
開発初期段階でバグがあっても何かついでに修正したり、他の画面・機能がなければ、考慮することが少ないのですが、リリース直前にバグ改修をする場合は、仕様やプログラムの作りにもよりますが、考慮することが多くなります。
このような状態でリリースをするのは危険ですが、顧客や関係者を考慮するとなかなか勇気が持てません。
このような決断をするのは心理的な負担がかかります。
解決：リリース前・リリース後にバグが起こる場合を考慮
残念ながら、バグは起こるものです。
バグを起こさないようにするのは当然ですが、バグが発生した時に迅速に対応することも重要です。
例えばリリース直前にバグが発生した時に、重要度によってリリースをするかしないかを判断するために、定義をします。
この定義がないと、どのように判断すれば良いか悩んでしまいます。
そのためにバグが発生した時にどのような行動を取るのかを定義することが重要です。
筆者もテストマネジメントを通してお客さんと対峙してきましたが、迅速に説明し、バグ改修をすればハレーションを抑制できます。
上記のようにリリース直前に判断に悩む場合を考慮して、テスト計画でリリース判定基準を決めます。
その基準を満たさなければリリースをしないと事前に共有しておけば、ハレーションを最低限に抑えることができます。
2章 アプリテストで幸せになるために抑えておくポイント
困ったテストあるあるを回避し、幸せな状態を築くためには下記のことをします。
テスト計画で「何をいつまで準備するか」「どのタイミングでどのテストをどのようにするか」「リリースできる状態の定義」などを書きます。
テスト設計でテストの網羅性を担保し、テスト仕様書に落とし込みます。
テストを進める上で常時課題が出ます。そのためにテスト進捗やバグ状況を分析して費用対効果の高いテストをします。
2-1. テスト計画
テスト計画で書く内容は下記の通りです。
・テストの方針
・何をテストするのか
・どのタイミングでどのようにテストするのか
・予測
・テスト開始基準・テスト中断基準・テスト再開基準・テスト終了基準
・テスト準備
・外部要因
テストの方針
方針を明確にすると心理的負荷が減ります。
何か判断が必要になった時に悩んでしまい、悩んでいる時間が他の工程に影響を与えます。
その際に方針が明確になっていれば判断する際の悩みが減ります。
例
・テストは極力自動化する。自動化が難しい場合のみ手動テストをする
何をテストするのか
何をテストするのかを明確にします。コストや納期によっては「やらないテスト」を定義したり、ある程度問題が少ないのであれば「テストを省く」こともします。
例
UI/UXテスト：使いやすさをテストするために、探索テストにデザインチームを参画させる
どのタイミングからどのようにテストをするのか
基幹システムのAPIができていないから、結合試験ができない…ということは多々あります。テストができない状況に陥り、テスターがやることがなくなる…そうするとリソースがもったいないです。
例
・単体テストはユニットテストを書いているからやらない
・外部結合テストはAPIのテストを実施する。そのため基幹システムが完成してから実施
予測する
テストにおいて定量化できるのは「テストケース数」と「バグ数」です。この2つを開発規模（FPで算出）から求めます。
例：1FPあたり7テストケース、0.6バグと仮定
・今回の追加開発は342FPなので2,394テストケース数と予測
・今回の追加開発は342FPなので205バグと予測
予測とズレるのは悪いことではありません。予測からのズレを検証することで原因解析の糸口になります。
基準・モノサシがなければ議論もできません。
テスト開始基準・テスト中断基準・テスト再開基準・テスト終了基準
上記の予測を用いて、各基準を設けます。
この基準を超えたら、対策を検討します。前述したとおり、漠然と主観的にバグが多い／少ないと話していても仕方がありません。
例：テスト終了基準
・テスト実施率95%（NTを5%許容する）
・テスト網羅率90%（＝ テストケース実績 ／ テストケース予測）
・バグ発生率±20%（基準より多いのはもちろん、少なすぎもテスト密度のに問題ありとみなす）
テスト準備
対象となるOSやブラウザのバージョン、スマートフォン機種などを明確にします。
対象を増やせばより多くの保証ができますが、対象を増やせば増やすほどコストがかさみます。
外部要因
外部システムがあると、外部システムの状況によりテストができない可能性があります。
よくあるのが、「基幹システムのAPIができていないために外部結合テストができない」です。
これらは自分達でコントロールできませんが、リソース配分などで影響が大きいです。
このような事態に備えて、基幹システムが予定通りにできなかった場合に備えて別のテストをするなどの調整をします。
テスト工程・テスト種別
テスト工程やテスト種別を明確にします。下記は一例です。
・単体テスト
・内部結合テスト
・外部結合テスト
・総合テスト
・脆弱性診断
・性能テスト
・負荷テスト
これらのテスト工程・テスト種別ごとに何をやるのかを明確にします。
・単体テスト → ユニットテスト（phpUnit）
・内部結合テスト → UIテスト（phpUnit）
・外部結合テスト → APIテスト（phpUnit）
・総合テスト → シナリオテストと探索テスト（テスト仕様書を使わないテスト）
・脆弱性診断 → OWASP ZAPを利用
・性能テスト → アクセスログより各画面ごとのアクセス時間を計測
・負荷テスト → Jmeterを利用
テスト計画書サンプル
2-2. テスト設計
テスト観点
テスト観点は会社組織・プロジェクト単位で事前に用意します。
テスト観点は「全体」と「画面単位」と「項目単位」があります。
正常系だけでなく異常系も考慮します。
サンプルは別紙に用意しました。ウェブやアプリなどの違いや業種などにより観点は増減すると思います。
サンプルを参考にご活用頂ければ幸いです。
テスト設計からテスト仕様書
1. 画面設計書をテスト仕様書を作成する観点でレビューする
2. テスト設計書を作成する。画面項目ごとにテスト観点の要/不要を判断する
3. テスト設計書から時系列を考慮しテスト仕様書を作成する
4. テストをしながらテスト仕様書の精度をあげる
テスト設計でテストの網羅性を担保
テスト設計書を書く目的はテストの網羅性を担保することです。
テスト観点を用意し、画面項目ごとにテスト観点と照らし合わせて、テストをするかしないかを決めます。
テスト観点の例：テキスト
テスト設計手順は下記の通りです。項目１つずつテスト観点を突合します。
画面：選手名
テキストのテスト観点は画面パーツ共有を含めて下記の通りです。
テスト観点：画面パーツ共有
テスト観点：テキスト
これを1行ずつ書き出します。ここまでをテスト設計とします。
この表に前提条件と期待値と必要な情報を書き加えるとテスト仕様書になります。
2-3. テスト仕様書
テスト仕様書は1期待値、1テストケースで書き粒度を揃える
テスト仕様書の原理原則は「粒度を揃える」こと「1期待値、1テストケース」にすることです。
「3-2. テスト設計」で記載した表に前提条件と期待値を記載します。
1期待値：1テストケースにする理由・メリットは下記の通りです。
・書くほうも見る方もわかりやすいのでテスターの悩みが減り、問い合わせのコミュニケーションが減る
・テストがサクサク進みテスターのモチベーションが上がる
・他のプロダクト・システムとテスト密度（テストケース数）の相対比較ができる
境界値分析
上記の例ではなかったので補足します。数値入力や日付入力のテストをする際には境界値に注目してテストケースを増やします。
入力範囲が「1以上、100以下」なので、境界値は「0, 1, 2」と「99, 100 ,101」となります。
注意
プログラム上0は特別なのでテストケースに含めましょう。仕様とプログラムがあっていないことが多々あります。
数学的な話ですが、「以上・以下」はその数字を含みます。
「未満・超える」はその数字を含みません。この手のミスはよくあるので前後の数字をテスト対象にします。
テスト仕様書は時系列で書く
テスト仕様書は可能な限り時系列で書きましょう。
時系列で書かないとテストをするときに行ったりきたりして作業効率が悪いです。
メンテナンスコストと可読性
テスト仕様書を書く際に
「名前を入力してください」
「名前は100文字までです」
など、エラーメッセージを具体的に記載するべきという意見もあります。
しかし、エラーメッセージが変わった場合、テスト仕様書も変更する必要があります。
何万テストケースとなると、手動で修正するのは手間だし、置換を使ってもヌケ・モレがあるかもしれませんし、エラーメッセージが変わるたびに対応するのも大変です。
メンテナンスコストを考慮して「エラーメッセージが表示されること」とすることで、上記のような修正コストを下げることが可能です。
もちろん、「方針として」詳細に記載するのであれば問題ありませんが、そのような方針はお勧めしません。
可読性やテスト仕様書の精度とトレードオフになりますが、メンテナンスコストも重要です。
エラーメッセージが複雑であるなど状況を見極め、テスト計画書に方針をまとめましょう。
最後に、テスト仕様書はなるべく時系列にするとテストがしやすくなります。
2-4. テスト自動化
テスト自動化だけで本1冊分のボリュームがあります。ここでは概要と要点のみとします。
テスト自動化…ユニットテストを書く意味
極論ですが、ユニットテストをしっかり書いているだけで、バグはかなり減ります。
筆者がフリーランス時代にとある上場企業の積立投資サイトを構築した際にユニットテストを書いただけでリリース後のバグゼロを実現しています。
数千万〜億単位の開発でも、ユニットテストを書くだけでバグの数が激減します。少なくてもプログラムの記載でのバグが開発時にほぼ修正できるので、仕様バグの対応、仕様変更への対応に注力ができるので、危なげなくリリースができました。
本来、追加・改修・仕様変更などがあるたびにテストをするのが理想です。しかし、時間・コスト・リソースは有限なので、テストが疎かになりがちです。
テストをするほうも同じようなテストをするのは退屈です。
しかし、ユニットテストを一度書けば何度でも同じように実行します。一度書けばコストもかかりません。
ユニットテストがないプロダクトは炎上することが多かったです…
テスト自動化の分類
「ユニットテスト」「結合テスト（APIテスト）」「UIテスト」の3つに分けられます。
・ユニットテスト
メソッド（関数）単位のテスト
単体テスト・内部結合テストの代わりになる
・結合テスト（APIテスト）
API単位のテスト
外部結合テストの代わりになる
・UIテスト
利用者が操作するのと同じようにテスト
総合テスト（シナリオ）テストの代わりになる
ブラックボックステストとホワイトボックステスト
ブラックボックステストとホワイトボックステストという言葉があります。
ブラックボッククスは一般的なテストだと考えて差し支えありません。仕様に基づき、入力値と出力値を確認します。
ホワイトボックスはプログラムの構造からテストを作成します。
主に条件分岐に着目してテストを書くので、膨大な量になります。人力で行うのは現実的ではありません。
しかし、ホワイトボックスでテストをしていれば品質が担保されるのは間違いありません。
ユニットテストはメソッド（関数）単位でテストをするためにこのホワイトボックステストのアプローチが可能です。
ユニットテスト
適切にユニットテストを書くことで「プログラマの心理的負荷軽減」「中長期のテストコスト削減」することができます。
プログラムを追加・改修する時に、プログラマはデグレーションが起きないか不安になります。
リリース後にデグレーションが発覚すると心理的なダメージが大きいです。
ユニットテストを導入していれば、コミット時やマージリクエスト時にデグレーションしていればエラーで教えてくれます。
また、万が一テストが足りない場合、次からエラーが発生した箇所のユニットテストを書けば良いだけとなり、個人の責任ではなくなります。
結果的にプログラマは萎縮せずにコミットやマージリクエストをすることができます。
プログラマが萎縮しない環境を構築することが重要です。
ユニットテストを書く目的・メリット
・中長期視点でコストが下がる
・人為的ミスを減らす
・人の責任ではなく仕組み（ユニットテストがない）の責任にできる
・ユニットテストを書いているプロジェクト・プロダクトは品質がよくストレスが少ない
・プログラムが疎結合となり、可読性向上、ソースレベル品質が上がる
・プログラマが自信を持ってコミット・マージリクエストができる
・単体テストを手動でやる必要がなくなるので負荷が下がる
・回帰テストも手動でやる必要がなくなるので追加・改修時のテスト工数が減る
ユニットテストのやり方・注意点
ユニットテストに馴染みがない方にユニットテスト導入すると拒否反応を示します。主な理由は下記の通りです。
・ただでさえプログラムを書くのが大変なのに、追加してプログラムを書きたくないから
・書く意味がわからない
・書き方がわからない
・以前、ユニットテストでメンテナンスが大変だったなど痛い目にあっている
上記は全てマネジメントが失敗していることが原因です。適切なマネジメントをすればユニットテストの恩恵を受けられます。
特に「書きすぎ」には注意しましょう。書きすぎていたらコメントアウトするなど抑制します。
書けば書くことメンテナンスコストが上がると考えてください。
下記にやり方・注意点を記します。
・カバレッジはあくまで目安であり、固執しない。85%超えていれば問題なく、85%は無理なく実現可能。間違っても100%を目指さない。
・1メソッド：1機能を徹底する（ユニットテストが書けない）
・if elseを必ず1回通すだけとする（C1 分岐網羅）
・通常のプログラムとユニットテストの時間比率は8:2を目安とする
・各言語にxUnitがあるので活用する
・ユニットテストごとにsetUpでデータを作成し、tearDownでテストデータを削除する（setUp, tearDownはphpUnitでのメソッド名）
・アサーションはtrue/falseが理想
・1回ユニットテスト実行あたり、10秒ほどを目安とする
結合テスト（APIテスト）
メソッド・関数単位のテスト自動化がユニットテストだとすると、テスト自動化における結合テストは主にAPIテストと定義します。
APIを実行した結果をテストするのでブラックボックステストとなります。
xUnitなどのテストフレームワークを使えば、URLにアクセスするだけでAPIを実行できるので比較的簡単に実装できます。
Swaggerを使えば、言語やフレームワークによってはテストを出力するのでより便利です。
対象がAPIになるだけで、主なメリット・やり方・注意点はユニットテストと同じです。
結合テスト（APIテスト）のメリット
・バグが出やすい結合部分のテスト自動化ができる
・Swaggerを使えばAPIテストを自動的に書いてくれる
・ユニットテストと比較してわかりやすい、テストコードを書きやすい
・仕様確認ができる
・マイクロサービスでは必須
結合テスト（APIテスト）のやり方・注意点
・各言語にあるxUnitがあるので活用する
・仕様に基づいてURLにアクセスするだけ
・何度もURLにアクセスするとサーバ側でエラーを出すので注意
UIテスト
UIテストはウェブアプリであればSeleniumなどを使ったブラウザでの実行を再現するテスト自動化です。
テスト自動化というと、UIテストを指すことが多いと思います。
利用者観点でテストシナリオ通りにテストできるためわかりやすくイメージしやすいです。
UIテストのメリット
・利用者と同じ視点でテストができる
・テストシナリオ単位でテストができる
・権限切り替えなどにも対応
・プログラミング初心者でもかける
UIテストのやり方・注意点
Seleniumなども進化しているので、いろいろなことができますが、ブラウザを直接叩くので、タイムラグが生じたり、独特の問題が発生します。
難しいことをやりすぎるとメンテナンスコストがかかるので、UIテストで対応することを限定します。
あくまでユニットテストがある前提でUIテストを書くようにしましょう。
・Seleniumなどのフレームワークを利用
・UIテストでやることを限定する。例えば「画面遷移」「画面変化（タブの切り替えなど）」「権限の違い」
・アサーションはtrue/falseが理想
・ユニットテストや結合テストで担保していればやらなくても良い
テスト自動化の進め方
理想：ユニットテスト→結合テスト→UIテスト
現実：UIテスト→結合テスト→ユニットテスト
理想はユニットテストから始めて積み上げるイメージですが、現実的にユニットテストがないプロダクトにユニットテストを入れるのは労力がかかります。
その時はUIテストから書いて、ユニットテストにブレイクダウンせざるを得ないかもしれません。
UIテストで難しいテストはしないようにして、あくまでユニットテストを書く前提を忘れないでください。
3章 モテるテストリーダーになるために
3-1. モテるテストリーダーは様々な障壁を潰してくれる
テストの目的
テストマネジメントを要約するとテストを進めやすくすること全般です。某テスト専門会社もテストマネジメントに力を入れているそうです。
まずテストの目的を整理しましょう。2つあります。
・問題ないことを確認する
・なるべく早くバグを見つけて開発者にフィードバックする
「問題ないことを確認する」はユニットテストとテスト仕様書によるテストで実現できます。
「なるべく早くバグを見つけて開発者にフィードバックする」はユニットテストと探索テストで実現できます。
ユニットテストはテストの目的2つとも対応できます。
テストアプローチ
テスト仕様書によるテストと探索テストのメリット・デメリットを下記にまとめます。
テスト仕様書によるテストが一般的ですが、テスト仕様書を使わないテスト（探索テストと定義します）をする方がより多くバグを発見できます。
テスト仕様書によるテストの場合、テスターが良くも悪くもテスト仕様書に書かれたことしかテストしないのと、心理的に無事済ませたいとバイアスがかかるのでバグを見過ごすことが多いからです。
探索テストはバグを出すことを目的とするので、バグを見つけやすくなります。
テストをする上でどちらも重要なので、うまく使い分けをしましょう。
テストマネジメントの役割
テスト計画を立てます。テスト計画は「2-1. テスト計画」に記載したので参照してください。
テスト計画を立てる時に、テストケース予測とバグ予測をします。
テストマネジメントは予測通りにいくようにするのではなく、予測から外れた時にすぐに対策を検討して課題を解決することが重要です。
予測は問題があるかどうかを測るためのセンサーだと思ってください。
リスク対策
リスクはケースバイケースですが、主なリスクと発見の仕方、対策を記載します。
テスト仕様書作成の進捗が悪い
テスト仕様書の作成に時間がかかる場合、画面設計書などの精度が悪いと考えられます。
テスト仕様書作成するメンバーに「なぜ遅いの？」と聞いても、聞かれた方も辛いので「大丈夫」しかいわなくなります。
テスト仕様書作成担当者も設計書に不備があり、やりにくさを感じていることが多いです。
原因を把握し、費用対効果の高い施策を打つために進捗を可視化します。
客観的に進捗を測りましょう。
エクセルやスプレットシートに次の列を作成します。
・日付
・その日のテストケース残数
・日当たりのテストケース作成数
・累計作成数（重要ではない）
・日当たりの対応時間
・1時間当たりの生産性
○ テスト前準備
残数に予測したテストケース数を記載してください。
作成数はテスト仕様書作成を終わらせたい日から日数を出し、予測テストケース数をこの日数で割ります。
そうすると、1日当たりのテスト仕様書作成件数が算出できます。
○ テスト中
1日ごとにテスト仕様書作成数と対応時間を入力します。
テスト仕様書作成メンバーが複数人いる場合は、日毎に合算してください。
個人単位でテスト進捗を測っても良いのですが、チームで合算すると、自然と助け合いが産まれます。
○ 生産性から進捗を推測
閾値はケースバイケースですが、20テストケース/時間が目安になります。
この数値をよりも下回った場合、何かしらの原因でテスト仕様書作成が止まっている可能性があるのでヒアリングしましょう。
○ テストケース残数から進捗を推測
バーンダウンチャートは傾きから終了日を予測することが可能です。
チャート上、傾きが緩やかになったら阻害要因を調べましょう。
傾きが急であれば、進捗が良いので特に問題はありません。
テストケース数とバグ数からリスクを見つける
テストケース数とバグ数を予測することで、テストのモノサシを作ることができます。
予測したテストケース数とバグ数よりも多い少ないでリスクの傾向がわかります。
テストケース数が少ない／バグが少ない
テストケース数が予測よりも少ない場合があります。
予測よりも80%を下回ったら、次を見直しましょう
・1行当たりに複数の期待値が書かれていないか
・境界値分析を実施しているか
この2点を満たすだけで、テストケース数妥当になります。
バグ数が少ない場合もリスクが潜みます。極端な話ですがテストをしなければバグは出ません。
下記のリスクが考えられます。
・テスト網羅性が少ない（テストが少ない）
・リリース後にバグが出る
ユニットテストを入れて、カバレッジが高いなど好材料があれば問題ありませんが、そのような施策がないのにバグが少ない場合はテストのやり方を見直しましょう。
テストケース数が少ない／バグも多い
テストケース数が少ないのにも関わらずバグが多い場合はそもそもの仕様やプログラミングに問題があります。
勇気を持って納期の調整、予算追加をしましょう。
テストケース数が多い／バグも多い
ある程度のバグが出るのは問題ありませんが、予測を超えた場合にリスクが顕在化しないか確認します。
テストケース数が多い場合、次のようなリスクがあります。
・コスト超過
・納期超過
・コストと納期を間に合わせようとするとメンバーが疲弊する
テストケースは不安になると増える傾向にあります。境界値分析や同値分割を利用して適切なテストケース数を目指してください。
ユニットテストなどテスト自動化した部分をテスト仕様書に記載し、「手動テストをしない」という選択肢もあります。
テストケース数が多い／バグが少ない
ユニットテストなどの施策があり、十分テストした実績があるのであれば良好な状態です。
テスト準備
テストマネジメントはテスト準備に徹してください。
・アカウント発行
・データ準備
テスト進捗が悪い場合、テスト準備ができていないか、バグが多くて手が止まっていることがほとんどです。
テスト準備はデータ作成であることが多いので、開発チームとの連携が必要です。
フレームワークにSeederというデータ登録を容易にできる仕組みがあるので活用しましょう。
Seederをテストチームでハンドリングできると尚良いかもしれません。
3-2. テスト進捗管理はこれだけやっとけばいい
テスト進捗はテスト仕様書作成で作ったようなバーンダウンチャートを作成して管理します。
この1つのチャートだけでテスト進捗状況を確認することができます。
元となる表に下記の列を作成します。
・日付と曜日
・テストケース残数
・消化数
グラフは、縦軸にテストケース残数、横軸に日付をとります。
日々、テストケース消化数を集計し、表の消化数に入力をします。
傾きがテスト進捗を示します。横軸に向かって線を引くと、テスト終了予測日がわかります。
納期を過ぎる場合は早急に原因を究明して対策を練りましょう。
このバーンダウンチャートだけで終了予測をすることができます。納期に間に合わなければ対策をうち、功を奏せば納期通りに近づきます。
テスト実施の生産性を測る
1時間あたりのテスト実施数を算出し、生産性を計測しましょう。
生産性を測る際に気をつけるのは、個人の生産性は無視してください。あくまでチームの生産性を計測してください。
個人の生産性を評価すると、足を引っ張り合います。個人の実績をあげたいがために助け合わずに自分の数字だけ追います。
チームの生産性を評価すると、テストケースを消化する人、バックアップやフォローに回る人など、それぞれの特性に応じた役割分担が自然発生的に生まれます。
1時間当たりの生産性はテスト仕様書の粒度や書き方などで変わります。図の数値は参考としてください。
テスト実施生産性の上げ方
テスターは自分がテストした箇所が本当にOK/NGか悩んでしまいがちです。このような心理負担を減らす努力をしてください。
OK/NGに関してはテストリーダが責任を持つとテスターはやりやすくなります。OK/NGの違いがあっても責めないようにしましょう。
経験上、一番効果があったのはテスト実施の動画キャプチャをとり、動画撮影と判定を分けます。
動画撮影をテスター、判定をテストリーダがします。
動画撮影をするうちに慣れてくるので、徐々にテスターに任せます。
ケースバイケースですが、次も効果があります。
・テスト仕様書の実施順番
・テスター 配置転換
・テスト仕様書の表現
・テスター への質疑応答
3-3. バグ管理・バグ分析
バグ収束曲線の作り方
バグ収束曲線は縦軸に累計バグ数をとり、横軸に日付をとります。
成功例
・テスト開始に累計バグ数の増加が伸びる
開発側にバグがあることを早く通知できており、対策を打ちやすいのでポジティブに捉えます。
・テスト終盤に累計バグ数の増加が減る（グラフが寝る）
テスト終盤はバグが少なくなるはずです。グラフが寝てくれば潜在的なバグが減ってきているといえます。
失敗例と状況
・テスト開始後、累計バグ数が伸びない
テストが進んでいないので原因を調査
・テスト終盤にもかかわらず累計バグ数が伸びる
ソフトウェアに問題があり、潜在的なバグが多い可能性があるので対策を協議する
バグ分析の順番
バグ収束曲線はバグの出方から概要を把握するためのものです。
バグ収束曲線やテスト進捗バーンダウンチャートから問題がありそうと判断したらバグ分析をします。
Redmine・Backlog・JIRA・Git issueなどのチケットから原因を探ります。
チケット起票例
チケット管理はRedmine・Backlog・JIRA・Git issueなど使いやすいツールや使い慣れているツールで構いません。どのツールを使うかよりどのように管理するかの方が重要です。
テスターが「怪しい」と思ったらチケットを起票します。後から、テストマネジメントが仕分けをします。
1バグ：1チケットとしてください。1チケットに複数のバグが記載していると管理が煩雑になりコミュニケーションコストが増えます。
チケット起票の例を下記に記します。文章を多くすると誤解・語釈が多くなるのでなるべく動画エビデンスを残しましょう。
近年はPCのスペックも上がり、アプリも充実しているので、動画エビデンスがとりやすくなりました。積極的に活用しましょう。コミュニケーションコストが下がります。
・タイトル
画面名か機能名 事象の概要を記載します。
・前提
権限や前画面など前提となる条件を記載します。
・期待値と事象
期待値と事象を記載します。テスターの疑問点を忌憚なく書いてもらいましょう。
・テスト仕様書
ファイル名、シート名、行数を記載します。
・エビデンス
動画エビデンスが望ましいですが、あまりに長いと見る方も大変だし、容量も使います。
複雑な事象でなければ静止画像でも良いです。
チケット管理の流れ
下記はチケット管理の流れの例です。開発規模や状況などにより増減すると思います。なるべくシンプルになるようにしましょう。
各状況ごとにステータスを定義して、チケットにステータスを付与します。
これをすることでどこがボトルネックになっているかがわかります。
1. テスターがチケットを起票
起票例は上記「チケット起票例」を参照してください。
2. バグかテスト仕様書・設計書不備などと仕分け
バグであれば、バグと識別（Redmineだと「バグ」トラッカー）
テスト仕様書・設計書不備であればタスクと識別（Redmineだと「タスク」トラッカー）
3. 優先順位と期日
期日はバグフィックスしたい日付を入れます。
優先順位は「重要度」と「緊急度」に分けて考え、優先度は3段階としてください。優先度のカテゴリが増えれば増えるほど、管理が煩雑となり、コミュニケーションコストがかえって増えます。
例：Redmineの場合「高め」「通常」「低め」を使い、「急いで」「今すぐ」は極力使わない
・「重要度」と「緊急度」が高い
例：このバグがあるとテストが進まない。利用者が不利益を被る可能性が高い
優先度を「高め」とします。
・「重要度」が高く、「緊急度」が低い場合
・「重要度」が低く、「緊急度」が高い場合
例：バグだが代替手段がある。
優先度を「通常」とします。緊急度が高ければ「期日」で調整してください。
・「重要度」と「緊急度」が低い
例：誤字・脱字程度。バグが起きても影響が極めて少ない。
優先度を「低め」とします。
4. バグを分類
画面単位、機能単位、類似性、同じソースコードファイルで分類します。
この分類をすることで開発側の修正効率が向上します。
5. 開発側に渡す
担当者を開発チームにするなどして開発にアサインします。
6. 開発側が修正
プログラムを修正し、ユニットテストでオールグリーンになったらマージリクエストを送ります。
7. 動作確認
開発初期（単体テスト）であればユニットテストのみで良いですが、開発後期（結合テストや総合テスト）であれば、チケットを起票したテスターも動作確認をします。
8. チケットクローズ
動作確認したらチケットをクローズします。
9. 定期的に棚卸し
チケットは溜まりがちなので定期的に棚卸しをします。古いチケットはクローズしましょう。
バグ分析の観点
バグ分析は画面や機能単位でABC分析します。バグが多いところは潜在的にバグが多くなる傾向にあります。
逆にバグが少ないところは、バグが出にくい傾向にあります。
バグが多い画面や機能を重点的に強化テストするなど対策を打ちます。
仕様が複雑になる画面はバグも多いです。設計時からレビューし予測しておくとスムーズです。
工程ごとの分析を求める方が多いのですが、あまり意味はありません。
よく「単体レベルのバグなのになぜ」となりますが、結果論でしかありません。
どの工程のバグかわかったところで、効果的な対策を打つための素材にならないからです。
この記事が気に入ったらサポートをしてみませんか？