見出し画像

「ぼくが考える最強のQA」ー QAチーム立ち上げ奮闘記｜DAIJOBU

DAIJOBU株式会社

1.はじめに

はじめまして、DAIJOBUのQAエンジニアのラコンマンです！

実は私、DAIJOBUのQAエンジニア第一号だったりします。 DAIJOBUに参画して初めての案件、さあ、気合い入れてQAするぞ！ と勇みながら社内ドキュメントを確認すると、そこには荒野が広がるばかり。

ーーというのは言い過ぎですが、自由度100%な状態ですので、経験を元に、「ぼくが考える最強のQA」のためのドキュメントを一から作成することになりました。


2.営業開始〜案件クローズまでの流れを確認する

納品に必要な「テスト計画書」「テストケース」「テスト報告書」を早速作成したくなりますが、ここで一呼吸。

DAIJOBUは新進気鋭の会社ですから、「QA業務」にフォーカスしすぎず、まずは縦の連携を意識しました。具体的には、案件開始、つまり、営業が案件を取ってきてからクローズするまで、各部署のタスクを一連のフローにまとめ、可視化します。各フローの順番・各々の役割を確認し、全体でその流れを共有しました。

チームの立ち上げのためにはQA業務にフォーカスしすぎず、『大きな視線でものごとを考える』必要があります。いざ文字に起こすと当然のように思えてしますが、DAIJOBUをより良くしていくためにとても大切なマインドであったと実感しています。

今回の件を例に挙げると、テスト計画書を作成して、テストケースを設計・実施し、テスト報告書を納品する、というのは基本的なQA業務ですが、その前には営業によるヒアリングがあり、納品後には請求書を発行します。なんとなく頭ではわかっていたことですが、改めて目で見て意識することで、一体感のようなものが生まれました。一連のフローを頭の片隅に入れておくことで、客先とのやり取りもしやすくなった気がします。

営業時のヒアリングってめちゃくちゃ大事だったんだなと実感する毎日です。
（本記事では割愛しますが、弊社ではキックオフの際に「事前ヒアリングシート」を作成・使用することで初動のスピードアップを図っています！）

各部署のタスクとフローの一部

3.心構え：初心者テスター参画を想定して資料を作成する

さて、ここから怒涛のドキュメント作成が始まります。
資料作成全体の心構えとして「初心者テスター参画を想定した資料作り」を意識するようにしました。

弊社ではテスター経験者のみを雇用しているため、実際に「初心者テスター」が参画することはありません。ですが、第三者検証会社に依頼をするのが初めての顧客や、色々な背景・経歴を持つQAエンジニアが参画するので、誰が見ても何を指しているのかわかるように、「よりわかりやすい言葉」を選定し、補足を入れるようにしました。

具体的には、不具合管理表のすべての項目・テストケースのステータスの意味や不具合の紐付け方など、自分では「当たり前にわかる」ようなことでも説明や補足を入れています。 私自身、QA経験は約10年ほどあり、第三者検証会社・事業会社と経験がありますが、いつのまにか言葉が職場ナイズされおり、微妙に意味を捉え間違えていることがしばしば……。（QA用語に限らず）

4.納品するために必要なものを作成する

一連のフローが見え、心構えもOK！今度こそ納品に必要なドキュメントの準備に着手します。今回は、ドキュメント作成の際に意識したことをかいつまんで紹介したいと思います。
全体として意識したことは「必要なものを、必要な分だけ」。

  • テスト計画書：細かく記載しすぎず、特徴的なことだけ。

    • あくまで「計画書」とし、テスト内容を客先と合意することが本ドキュメントの主目的であるこを忘れない。（つい細かく記載したくなるが、それは補足資料で提示）

  • テストケース：どのポジションのひとでも把握しやすいものを。

    • テストケースナンバーをシート内でも「1-1,1-2,2-1」と塊で分割し、かつ塊の最初の行に色をつけることでテストケースの変わり目を意識

    • 不具合管理表と紐づけるため専用の場所（不具合管理番号、概要の記載をする場所）を用意

    • 実施結果の確認がしやすいようステータスの色を分ける、他端末検証時の差分がわかるように実施結果を横に並べる

  • 不具合管理表：これだけ見ておけばなんとなく品質がわかるものを。

    • DAIJOBUはweb3特化の第三者検証会社のため、不具合管理表もweb3に特化するべくトランザクションを記載する場所を用意

    • 不具合のステータス（起票から改修確認完了まで）を最小限にする

    • テスト報告（分析）を見据えた、不具合の切り分け項目を設定

  • テスト報告書：あえてコンパクトに。

    • スライドで視覚的に「わかる」ことを意識し、必要なものを必要な分だけ記載する（だらだら書かない！）

    • 分析方法は様々あるが、多くの分析をすればするほど良いというわけではない。客先のニーズにあったテスト報告が大切。分析内容は取捨選択すること

5.QA業務の雛形を作成する

納品に必要な準備が終わったら、次はQA業務に必要なサブ資料を整えます。 使うか使わないかはQAエンジニアの裁量に委ねますが、毎回ゼロから作成するのは骨が折れるので雛形を用意します。
こちらも、いくつか抜粋してご紹介します。

  • 設計関連資料：その名のとおり、設計時に使うドキュメントをまとめたもの

    • QA作業チェックリスト：案件を受注してから納品するまでの全てのフローを細かく一覧化したもの

    • 権限確認チェックリスト：各ドキュメントの権限設定漏れを防ぐ

  • 実施関連資料：主にテスターが確認する資料

    • キックオフ資料：案件に関わる特記事項を記載。各資料のリンクなども貼り、何かあればここを確認すればOKな状態に。

    • 社内質問票：テキストでやり取りすることが多いので、一覧にしてしまった方が回答漏れなどが防げる

    • ふりかえり：メモ程度でOK。気づきを蓄積することが目的のため、ソフトに展開
      →QAチームの垣根を超え、他部署や全社的な改善の訴求&実現することもしばしば。DAIJOBUという会社自体もどんどんダイジョウブになっていっています！

  • テスト観点/不具合蓄積

    • 一般的なweb2のテスト観点（表示崩れがないこと、入力の境界値の確認など）と、web3に特化したテスト観点を、ウォレット、マーケットプレイス、ステーキング、ゲームなど、ドメインごとに集約

    • 観点と合わせて不具合も蓄積することで、観点への追加はもちろん、顧客への提案や、不具合が発生したときの原因の可能性の一つとして、原因究明の一助となる

6.奮闘は続く

１案件目を無事に納品・完遂することができました。
ですが、DAIJOBUのQA事業はまだまだ始まったばかり。実際には１案件目になかったドキュメントについてもいくつか紹介してしまいましたが、現在は１案件目の時に比べると随分資料や制度が整い、ブラッシュアップされているのを体感しております。

例えば、弊社はweb3に特化したQA会社ですから、web3初心者でも安心して検証するために「web3実践資料（QA業務に必要な実践的なweb3の手順やナレッジを貯めたもの）」「web3そのものの知識を深めるための資料、オンボーディング、ワークフロー」を日々拡充しています。

ですが、まだまだ、まだまだ、良くなる！
DAIJOBUの奮闘は続きます。


DAIJOBU株式会社ではQAエンジニアのマネージャークラス〜メンバーまで幅広く募集をしております。

▼カジュアル面談はこちら！！
https://pitta.me/matches/UMidcjrFmWvK

▼詳しい募集要項はこちら！！
https://docs.google.com/spreadsheets/d/1ShH-KamzE8JPT8d1PlVpNarpzw9d3o0vWtKejSzqKks/edit?usp=sharing

▼応募はこちらから！！
https://daijobu.io/

▼お問い合わせはこちらから！
https://daijobu.io/contact

▼DAIJOBUについて（コーポレートサイト）はこちらから！

この記事が気に入ったらサポートをしてみませんか？