Webサービス開発におけるQAのスタンスのパターン
ソフトウェアテスト Advent Calendar 2018 - Qiita の11日目の記事です。
はじめに
先日行われた Web Service QA Meeting 2018-Decにおいて、パネルディスカッションで触れらていた「QAのスタンス」の話が興味深かったので、QAのスタンスのパターンについて書かせていただこうと思います。
Webサービスの開発現場におけるQAの関わり方
今回の勉強会で紹介されたスタイルに加え、今までお話しさせていただいた他社のお話も踏まえ、スタイルを５つに分類しました。
不在型
そもそもQAがいないチームで、開発エンジニアや企画職で協力してテストをこなしていくスタイルです。 今まで複数の方にこのお話を伺いましたが、ほぼみなさん「チームにQAが欲しい」「立ち上げたい」ニーズをお持ちでした。 もちろん、テスト関係のイベントや勉強会などで話しているからかもしれませんが、 テストや品質の理解がないことよりも、求める人材に巡り会えていないことが直近の課題のようでした。
ラボ型
QAのリソースを社内外に確保しており、テスト活動の多くをQAチームが担うスタイルです。 端的に言えば、開発チームとは別にテストラボ（テストチーム）が存在しており、テスト設計や実施などをテストラボで受けているイメージです。 会社の規模によっては大きいところでは、数百人体制で運用している会社もあるようです。
ナビゲーター型
ナビゲーター型の特徴は開発チームと一員となり、チームで一体となってQA活動を進めます。 ナビゲーターの名前の由来は、先日の勉強会では『事故ったら一緒に痛みを味わう』というところからで、 同じ乗り物の中でドライバー（開発エンジニアなど）の横でサポートしているイメージのようです。 チーム内の全て、もしくは一部のテストを担い一体となってリリースまでの活動を高速にこなしている印象です。
技術レベルや文化に依存するとは思いますが、ナビゲーター型には近すぎることによる弊害もあるようです。 例えば、品質の分析時に先入観を持ちすぎてしまったり、当事者意識を持ちすぎることによって、実際にはプロジェクトの進行スピードを遅らせる（ブレーキが掛けるような行為）がしづらいというような課題感をお持ちの方がいらっしゃいました。
コーチ型
プロジェクトの外から見守り、プロダクトやプロジェクトの健全性を分析し、必要な指導を行うのがコーチ型の特徴です。 コーチ型のメリットは客観的に分析する点のようです。 ナビゲーター型が一体になっているのに対して、コーチ側のアプローチはやや限定的、もしくは間接的になるようです。 具体的には、成果物のレビューやメトリクスの分析、技術的指導やサポートと言った活動が主となっています。 ナビゲーターが近すぎて見えづらいという欠点に対して、コーチ型は細かい状況を察知しづらい印象です。 また、ナビゲーター型がプロジェクトの成功にフォーカスしていることに対して、コーチ型は対象の人にフォーカスしている印象です。
さらに近くにいてコミュニケーションしなければ分からない問題などがあった場合に、気付きづらいといった欠点があるかもしれません。 また、プロジェクトメンバーとの信頼関係をどのように築くかなどといった点にも工夫が必要そうです。
ハイブリッド型
コーチ型、ナビゲーター型、ラボ型を柔軟に切り替えるスタイルです。 私が所属するチームはこのスタイルです。 普段はコーチ型で全体を俯瞰しつつ、プロジェクトリスクや規模、複雑さなどを元にQAとしてサポートするプロジェクトを決定し、 プロジェクトに加わり、ナビゲーター型で活動します。
また、例外的にラボ型としてシステムテストなどを請け負います。 具体的には、社外に発注したシステムの受け入れテストを実施できるチームがいない時や、協力関係にある他社と協力してサービスを作る場合などが挙げられます。 ラボ型で活動する期間はリソースが一時的に不足するので、第三者検証会社などにお願いして、外部リソースによってテスト実施リソースをまかなう場合があります。
最後に
開発におけるQAスタンスは答えがないテーマだと思います。
本エントリーが何かの参考になれば幸いです。
おまけ：Web Service QA Meetingについて
Web Service QA Meetingは不定期開催の勉強会イベントです。 私も運営として関わらせていただいており、毎回運営メンバーで議論を重ね、本当に聴きたいと思えるテーマ、講演者の候補を考え、来場者に楽しんでもらえるようなフォーマットを検討しています。 そのため、イベントのフォーマットは、講演、ワークショップ、パネルなど色々な形式で、毎回テーマも変化していきます。 ライブ色が強く、SNSでログなどを読んでもあまり伝わらない内容が多いので、ご興味が少しでもあれば、試しに一度参加していただき、ご自身で体感していただければと思います。 （ただし、万人ウケするように考えて作っていませんので、一人一人に面白いかどうかは保証できませんが、品質やテストに興味がある方であれば、そこも含め、ご自身で体験して判断していただくのが良いと思います）
ちなみに、次回は２０１９年6月を予定しています。 少し先ですが、情報を取り逃がさないようにご興味お持ちいただけたら connpassのグループに参加していただければと思います。 ちなみに、今回のイベントは５、６時間で枠が埋まってしまったので、気づいたら迷わずに早めに抑えてしまうのがオススメです。
私がテスト計画を書く理由
これはソフトウェアテスト Advent Calendar 2017 - Qiita の17日目の記事です。
はじめに
この記事では、特にQAやテストのエンジニアの方にむけて、テスト計画を作成する理由や目的を書いていこうと思います。 もし、テスト計画を新たに導入したり、テスト計画書の内容を見直したいと考える際に参考になれば幸いです。
私の仕事
私は普段、ウェブサービスを運営する会社でQAのマネージャをやっています。 以下は、最近社外のソフトウェアテストシンポジウムで登壇させていただいた時の発表資料です。うちのチームの仕事のスタイルなどを理解していただくのにあわせてご参照頂ければと思います。
www.slideshare.netテスト計画とは
ものの本によると https://www.amazon.co.jp/gp/aw/d/4817161108/ref=dbs_a_w_dp_4817161108
検査計画書は、いうまでもなく検査実施のためのもっとも重要な仕様書である．
とあります。
しかし、普段社外の人たちとコミュニケーションするなかで、実際にテスト計画をプロジェクトで有効に活用されている話をあまり聞きません。 もしかしたら、プロジェクトがただ上手くいっているからなのしれませんが、私が所属する組織では、難易度が高い（規模が大きい、システムが複雑、活動の制約が厳しい）と思われるプロジェクトでは、テスト計画なしでプロジェクトの成功は難しいと私は感じています。 ですので、もし今テストプロジェクトが上手くいっていないと感じるのであれば、テスト計画を有効活用することがプロジェクト成功の助けになるかもしれません。
テスト計画が解決してくれること
テスト計画が解決してくれることは沢山あります。 私が普段重要だと思っていることを書き出していきます。
テストする範囲（テストアイテムやテストスコープ）の意識をあわせることができる
まず、テストする範囲を特定します。当たり前なことですが、これはとても重要なことです。 今回の開発システム（サービス、製品）のなかでテストの対象となる機能を書き出すことでその認識を合わせていきます。
ここで不足しがちなのは、テストしない機能を明らかにしておくことです。
自分が影響範囲外だと思っている"直接改修しない"既存のモジュールや外部システムとのテストを、 一部の担当者はテストすべき（もしくは当然テストするだろう）と考えることがあり、そういった認識の齟齬から後で問題が起こることがあります。 計画フェーズで確認しておかないと、あとから発覚したときに調整が難しくなることがあります。 *1
テストのアプローチを検討できる（テストタイプ、テストカテゴリ、テスト条件、テスト観点、適用するテスト技法 等の検討）
対象となる機能が決まったら、何をどうテストするかも具体的に書き出して検討することができます。 人によってテスト設計や分析を始めるタイミングは違うと思いますが、計画中に設計すべきことはしてしまうのが良いと私は考えています。
もしかしたら、テストタイプ毎にテストカテゴリのみを決めておくだけでも悪くないかもしれませんが、 クリティカルなプロジェクトであればスケジュールとの戦いになりますので、現実的なスケジュールを作成するために、 より詳細なテストをイメージできるように計画段階でテストの内容を明らかにしておくべきです。
特にテストプロジェクトに割り当てられたリソースやスケジュールを後から変更しづらいようなプロジェクトの場合は、 予定されたテストを実行しきれないにもかかわらず、限られたリソースの中でベストを尽くすしかないような状況になってしまうと不幸なので、 要求された品質にたどり着くために必要なテストを、きっちり全員が腹落ちするようにテストのアプローチをまとめましょう。
テストの順序を明確にし、テストの回数をイメージするきっかけをもてる（テストレベル・テストサイクルの検討）
テストの順序や回数を明確にしておく必要があります。 各テストレベルの目的や概要を書き出し、テストアプローチで検討したテストはどこで実施することが妥当なのか考える機会になります。
ポイントは重要な問題をいかに早く気付けるように組み立てるかです。 例えば、「もしかしたら、新しいOSSのプラグインはバグだらけで使わない方が良いかもしれないので、システムテストに入る前の早い段階でOSSに関係するテストの一部を実施しよう」と考えてみたり、 「業務レベルの要求が抜けていたら不安だから、受入れテストの前工程でその問題を発見するためにどうしたら良いか」など検討したりすることです。
また、機能テストのテストベースとなる機能仕様書が十分な精度で準備されていないままプロジェクトが進行しているのであれば、「テストサイクルが1回では不安なので、3回くらい考えておいて、追加のテストケース設計も見積もっておこう」などと考えることができます。
QAの立場から、検討されたテストの内容（テストのアプローチ）を眺めながらが不安に感じることは時々現実になるので、プロジェクトリスクも含め、全体の流れをイメージするために順序や回数を検討する必要があります。
プロダクトリスクを合意することができる
私の場合、QAエンジニアとして、計画時に提案するテスト内容はプログラマや開発側のディレクターのイメージを少し（時々大きく...）超えた量です。
テストはプロダクトリスクの軽減活動の一部であると言えると思いますが、 なぜ、これだけのテストが必要か、プロジェクトのステークホルダー全体で腹落ちするためにプロダクトリスクについても合意が必要です。
テストが必要であることを納得してもらえる説明ができなければ（もしくは、テストを実施しなかったときに発生するリスクを運用チームや事業オーナーが許容できるのであれば）極論ですがテストのアプローチを見直してしまっても良いと思います（極論ですよ）
テスト環境を検討する機会を得る
テスト環境の検討も意外と重要です。同じチームで繰り返し開発を行っている場合は、おそらく前回と同じでしょうから気にしなくて問題ないと思いますが、 色んな開発プロジェクトで仕事をするようなQAエンジニアは、過去にテスト環境の問題（受け渡し時期や、制限（一部の機能が使えない）、スペックが低い（レスポンスが遅い））などが原因でテストが上手く実施できなかった経験があるのではないでしょうか。
私は普段の業務で、テスト環境の問題が発生してしまった際、冗談半分に「（地球のそれを彷彿させるように）深刻な環境問題が発生した」と発言してプロジェクトメンバーと笑いますが、マネージメントの観点からすると環境問題により、時として深刻な遅れがでることがあります。
原因は色々ありますが、例えば、事前にテスト環境（もしくはリリース前の本番環境）を使って、どのタイミングでどんなテストを実施するかを明確にしていない、もしくは開発側と環境の引き渡し時期を合意していないためです。
また、テストアプローチやテストカテゴリ間の愛称により、一緒にテストが実施できないことありますが、そういった前提条件をキチンとテスト環境の要件に加味できていないことも原因にあたります。 例えば、パフォーマンステストの結果の精度を求めるのであれば、専用のテスト環境を準備してもらう必要があるでしょうし、業務シナリオを通して日々のシステム全体の売り上げ集計を正確に再現するようなテストでは、他のテストと同じ環境ではテスト結果に自信が持ちづらくなります。
「環境問題」が発生しない未来を創るためにも、計画時にキチンと検討を済ませておくことが大切だと考えています。
見積り、担当者、スケジュールの妥当性を判断できる
どんな機能に対して、どんなテストを、どんな流れで実施するかをしっかりと検討できていれば、各テストの工数やタスクごとに担当者を適切に配置することができます。
まとめ
いかがだったでしょうか。 計画段階で話しておかないと、大きな方針や予算、リソースなどをあとから調整できなくなることがあると思うので、QAをはじめとするプロジェクトのステークホルダが不幸にならないためにも必要十分な検討が大切です。 あなたがテスト計画から解決できることのヒントになれば幸いです。
