【非エンジニア・QA向け】なんちゃってQAのススメ

4533 ワード
チーム開発 テスト QA テストケース QAエンジニア テスト テキストリンク

本記事はGoodpatch Advent Calendar 2016 の20日目の記事です！

Goodpatchで唯一QAの肩書をいただいているenpipiと申します。
普段は社内SEとして活動しておりますが、Prottの大幅な改修時などスポットでQAとして参加しています。

専任のQAがいれば良いのですが、ディレクターや手が空いている人がQA的なことをしているチームも多いのではないでしょうか。

本記事では、非エンジニア・QAに向けた簡単なQAのコツについて紹介します。

スタンスの話

QAは、平たく言えばサービスの品質に責任をもつ仕事です。
しかし、片手間でQAをやる場合や専任じゃない人に同じ責任を求めるのは酷です。
バグを絶対に出さないと意気込むよりも、エンジニアがやらなくても良い仕事を引き受けて、開発に集中してもらう環境を作るくらいで考えている方がモチベーションを保てると思います。

テストケースを作る時の話

テスケースは簡単でも作ったほうが良いです。
記憶は全然頼りになりません。ログを残しておいたほうが後々同じテストを無駄に繰り返すことがなくなります。

以下のように、誰が実施しても同じ手順を踏めれるようになるべく丁寧に書けると使いまわすことができます。
もちろん、自分が理解できるだけで良ければ丁寧にやらなくても大丈夫です。

重要なのはテストを実施した結果、問題ないと判断するのはどこが最適かを意識することです。
例えば、お問い合わせ画面から問い合わせができることを確認するなら、「送信完了画面が表示される」ではダメで、「問い合わせ内容がメールで届いているか」を確認する必要があります。

バグを見つけた時の話

  1. バグの再現ができないと、どこを修正して良いかわからない
  2. バグが出た時のメンタルダメージでかい。不安。
  3. 何から修正するか迷う

と言ったようにバグがエンジニアに与える負担は大きいです。

バグを報告してもらえるのは嬉しいのですが、情報が少ないと相手にヒアリングしなければならず開発に集中できません。

非QAの人は以下のような工夫をしてなるべくエンジニアにかかるコストを下げてあげましょう。

1. バグを再現させて共有する

再現手順がわからないと、手がかりほぼ無しでソースとにらめっこすることになります。
逆に再現方法がわかれば容易に原因を突き止めることができます。

偶然発生したものは普通にやっても再現しないことが多く、その前の手順やアカウントの状態が関連していることが殆どです。少しでも手がかりになりそうな情報を記憶があるうちに残しましょう。

画面キャプチャを必ず撮る

どの画面で何が起きてるか、瞬時に把握できるように画面キャプチャを必ず用意しましょう。
個人的にGyazoはオススメです。URLで管理できるのでSpreadsheetで管理しやすいです。

スマートフォンのWebサイトやアプリの場合は、弊社フィードバックツール『Balto』を推します。本当に便利です。
もしくは、QuicktimePlayerやVysorを使ってPC上にデバイスをミラーリングできると捗ります。

再現手順を書く

**問題の詳細**
招待を連続で承認すると、2番目のプロジェクトを承認できずに落ちる

**再現手順**
1. ユーザーAをプロジェクトに3件招待する
2. ユーザーAでiOSアプリにログインする
3. 1件目を承認する
4. 2件目を承認する(なぜか3件目が一覧から消える)
5. 2件目を承認する
6. 落ちる

**備考**
リストの下からやると再現しない

再現方法を突き止めたら文章にして残しましょう。都度、エンジニアに報告すると集中力が切れてしまうので、スプレッドシートなどにまとめて好きなタイミングで確認できるようにしています。

2. 部分的にでも網羅的なテストを実施する

トレーニングジムのレジに下記のような自動割引機能をつける
* クーポン持参：10%OFF
* ジュニア割引（15歳以下）：20%OFF
* 平日割引：30%OFF
* シニア割引（65歳以上）：50%OFF
* 割引サービスが重なった場合は、割引率が高い方が優先される

以上のようなシステムがあった場合何パターン確認しなければいけないでしょうか。
こういった様々な条件が重なる場合はデシジョンテーブルを作りましょう。


3. バグに優先順位を付けて管理する

Githubでバグをissue化してProjectでカンバン管理するなど、優先順位付けと修正確認をしてあげるとかなりエンジニアが楽になります。

例えば、私の場合以下のような優先順位をラベルで作成しています。
どのバグから修正したら良いか、基準ができるので効率的にバグを潰せるようになります。

  • A : 絶対リリースまでに修正する
  • B : できればリリースまでに修正する
  • C : 次回リリース以降に修正する

また、修正確認時では「他の場所でも発生しないか」を念頭に置くと修正漏れを防ぐことができます。

むすび

QA作業は本当に地道な作業です。過去にバグをドラゴンと呼ぶ運用が話題にあがったように、楽しくやったほうがお互いモチベーションを保てます。ちなみに私はドラゴンを見つけても退治できる術がないので、バグを財宝と呼んでテンションを高めています。

ぜひ、楽しくQA業務をやっていただき、エンジニアの力を最大限プロダクトを良くすることに使えるようにしましょう！