QAリーダが最低限やるべきものについて
開発本部CTO室QAのALICEです！
こちらの内容は私個人の意見ですので、同意できない部分や、おかしい？と思う部分があるかと思います。
その場合ぜひツッコミください！
私はこのような交流が大好きです！！
TEとQAの違い
基本的に同じ業界の方でもQAとTEを同じだと思う方がたくさんいらっしゃいます。
QAってテストする人。というイメージ。
確かにQAはテストをします。ただテストだけをする人をTE（Test Engneer)と呼びます。
TEさんは特別なスキルや技術が足りなくてもできます。
ただしQA（Quality Assurance）は少し違います。
技術やスキル、コミュニケーション能力、スケジュリング、リスク管理などなどできないといけない専門知識がたくさん必要です！もちろんQAもテストをします。なので完全に違うとは言い切れませんが、簡単にいうと
QAという大きな枠の中にTEが含まれている感じです！
QA開始前
QAのクオリティは事前準備で決まる
QAは事前準備で8割決まると言われています。どれだけリスクを想像できるか、回避策を立てられるか、TEがテストを行いやすいようにTCを書けるか、例外ケースをいくつあげておくことができるか。行うべきことは山のようにあります。
準備が万全であればテストに入った後は計画通り物事が進みます。
逆に事前準備が半端な状態で挑むと、パーティーの司会に事前準備なしで挑んだ時のようにその場その場で取り繕うQAになります。もちろん漏れも多いでしょう。
QA開始後の流れ
早めに全体機能のチェックを行う
早めにカバレッジを上げることによって、早い段階で動かない機能を報告し、開発の修正時間を確保する。
方法としてはQA開始時に簡単なチェックリスト、Sanity testで使ったcaseを行うとよい。
Ad-hocテストも一工夫する
一例だが、Ad-hocの時は誰かがバグ報告をすると皆がそのバグの個所に集中してしまう場合がある。
手順が面倒くさい場所はAd-hoc時に手を付けない人が多い。TCに落としておくか、具体的な指示を行い、必ず目を通すように心がける。（容量オーバー、電波が悪い場所、etc…）
BTSのチェックを忘れないこと
BTSのアサイン忘れがないか、質問が返ってきているのに放置されているものはないか、BTSの書き方がよくわからなくなっているようなものはないかチェックする。（意外とある）
未着手のBTSがあったなら催促や対処ができること。
QA開始後の流れ
チャットに気を付ける
最近は返事をしない、できない人も増えている。これは集団による責任の分散（みんながいるから誰かが答えるだろう）また、答えていいものかわからない、といった理由が挙げられる。質問時は「＞○○さん」と名指しをすると答えてくれるかと思われる。
QAでの注意点
企画段階から参加し、情報収集を心掛ける
早い段階でサービスに参加できたのなら、MTGなどで情報収集を心掛けること。仕様が二転三転する場所、テストで気を付けた方が良い場所が見えてくる。
早め早めの行動を心掛ける
やらなければならないことは早め早めに片づける。そうしないと、後で全部自分とメンバーにしわ寄せが来る。QAは最終工程なので短い期間で求められた結果を出す必要がある。後手に回るとリカバリーができない場合もある。
他部署のメンバーを怖がらない
QAは開発メンバーや企画と、スケジュールについて、企画内容について、バグについて…etc様々話し合う必要がある。最初のうちはドキドキして聞きたいことが聞けない、があるかもしれないが、しっかりと話をしなければ最後になって「ここどうなってるんですか？」となったり、聞こうと思っていたが聞かずに雰囲気で仕様だと思っていたものが重大なバグだったりすることがある。
交渉力を身につける
前職で大ベテランのQAの方にQAをやっていた方に「QAで一番重要なスキルは？」と聞いたところ「交渉力」と言われたことがある。QAは基本短いスケジュールを要求される。またQA後半にもかかわらず大規模改修を実施しようとするサービスもある。そんなときQAがリスクを説いて相手を説得し、お客様に提供するサービスの品質を確保しなければならない。
テストコントロールを行うこと
TCの進捗をしっかりと確認すること。進捗が遅い場合は早めに対策を立ててサインオフまでにテスト範囲を必ず全網羅すること。もし人が足りないのならリソースを依頼したり、確認端末が多すぎるのならば削る場所を考えたりしなければならない。
Blocker級のバグが出た場合テスト進行が困難になるため最優先で直すよう依頼を行う(BTS登録を待つより連絡した方が早い）。またバグ状況を見て今後のテストスケジュールに影響が出る場合もステータスレポートなどで警告すること。
本当にあなたはテストできないほど忙しいのか？
QAの中にはテストコントロールと他部署コントロールで忙しくテストが一切できないという方がいる。そういう場合もあるが、本当にサービスを一切見られないほど忙しいのか？ テストをしないと微妙な動きを把握できない場合があるので、QAも動けるならばテストに参加した方が良い。
テスト技術を勉強し導入する（この記事で一番大事）
基本のやり方も良いが、テスト技術を学んだ方が効率化する場合もある。例えばTCを作成する場合にはPair-wise法を知らないと、全数組み合わせを試す羽目に陥る。急な変更でテストをしなければならない時、探索的テストを知らないと突然Check listを作り出す人もいる。QAであるのならば、どうすれば楽をしてテスト範囲全体をカバーできるか考えた方が良い。残業も減る。
チェックリストの作成
チェックリスト作成方法
・MindMapに落とし込む(自分にあっている手法で観点を出しておく）
・機能レベルで枝分けし、各動作の要求事項で細分化する
・TCではないので、基本的に要求事項の動作確認までで良い
チェックリスト作成ポイント
手順、期待結果が簡潔かつ分かりやすく記載されていること
・何ができたらOKなのか明確に記載する
・各機能の要求事項レベルでテスト項目を作成する
・Betaで確認してバグがでているところがあったらそこを加えてもよい
管理とは
QAポジションに着くと、様々な場面でリーダーとしての「管理」に直面することとなります。
自分のプロジェクト全体の把握・管理
プロジェクトのTEメンバーの管理
テストの進捗管理
振られた業務の管理 etc
掘り下げて、管理とは、
対象とゴールを定め、
そのゴールに到達するために『PDCAサイクル(Plan→Do→Check→Act)』を回すことである
対象の設定
ゴールの設定（目標・目的・狙い）
ゴール到達（目標・目的・狙い達成）
P→D→C→Aを回す（マネジメントサイクルの確立）
QAであれば、プロジェクトを毎回予定通りに終わらせるためにPDCAを回すことである。
（＝テストコントロールと言い換えることもできる）
PDCAサイクルとは
PDCAサイクルとは、品質管理などの管理業務を円滑に進めるための手法です。
以下を継続的に行い完全していくことでより良い管理ができるという考え方です。
Plan : 計画を立てる
Do : 計画を実行する
Check : 実行結果を評価する
Action : 評価を受け改善を行う
例えばテスト業務であれば、以下の例が考えられる。
テストの段取りを考える。
段取りを実行する。
実行した結果どうだったかを振り返る。
問題点を改善し、次の段取りに活かす
QAであれば、以下が例として挙げられる。
目標：リリース前営業日までにQA Sign-offを行う。
QA Planでリスク管理（QA中級レベルでの講義）を含めて、スケジュールを作成
開発進捗の把握
開発進捗に合わせQA Plan見直し
テスト開始後は、テスト進捗の把握
テスト進捗に合わせPlan / 手法の見直し
プロジェクトの失敗は、メンバー間の「認識の齟齬（そご：違い）」がきっかけとなることが多い。
メンバーそれぞれのコミュニケーションを強化し、
•共有漏れがないこと
•認識の齟齬がないこと
•メンバー全員が状況を認識していること
が大切となる
進捗把握
進捗把握の手段
QAはプロジェクト全体の進捗、テスト開始後はテスト進捗双方を把握しなければならない。
プロジェクト定例MTG (他部署の進捗確認）
・TCの進捗確認
・進捗報告会議（朝MTGなど)
・進捗報告メール or チャット
・自分から聞く
・観察（表情、しぐさ、言動）
進捗把握のポイント
進捗率を報告する基準を明らかにする
あいまいな発言にはツッコミを入れる
不安・懸念事項を聞く
遅延が発覚したら、必ずリカバリー案を考え出す
前回のMTGで指示した対策の実施状況と効果を確認する
まとめ
管理をする上で大切な事
メンバーとのコミュニケーションによる認識合わせ
正確なスケジュールの作成 （Planの精度 : QA Plan / 工数）
正確な進捗状況の把握 （Checkの質）
遅延発覚時の迅速な対応 （Check > Actionの速さ : テストコントロール）
スケジュールの作成を行い、
現状とスケジュールの差異を把握、
遅延発覚時には迅速な対応を行う。
これらサイクルを素早く回すことが「上手な管理」である。
いろんな手法を学んだ後でも、それをそのままルールに合わせて使うのではなく、ちゃんとその手法を理解して、自分のものにしてから、臨機応変に使っていく。
フォロー
・テスターさんの管理
・テスト中、テスト外ともに管理が必要
・テスト期間外の作業の指示
・手が空いたときも仕事が割り振りできる
・テスターの教育
QA前
・仕様書・PRDレビュー
・他部署とのコミュニケーション
・QA planが作成できる
・場合によってはKick off MTGを設定する
QA準備
・テスト準備期間にテストデータの用意ができる
・小規模の案件でのチェックリスト作成
・テストケースの作成
・テストケースの振り分け（割り振り）
QA中
・随時進捗確認
・進捗によって、臨機応変にQAの内容を変更できる
・テストケースを削る、Ad hocをやる、セッションベース探索的テストをやる
リリース対応
・Sign off後にコードの変更がないか確認 (コードフリーズ)
・リリース直後のリグレッション
・機能によっては機能の確認のみでOK
・ボリュームによってはやらない場合もある
リリース後
・振り返りができる
・Bug傾向分析ができる
・次回に生かせるような資料が作成できる
・データの整理ができる