スタートアップの1人目QAとして、QA組織の立ち上げ1ヶ月でやったこと
株式会社TAIANのソフトウェアエンジニアのふびらいです。
弊社は婚礼事業者向けのSaaSを提供するスタートアップです。Vertical SaaSは業務ドメインに深く入り込む都合上、どうしても仕様が複雑になりがちです。プロダクトが大きくなるにつれ、QA無しでの品質の担保に限界が見えてきました。そのような背景から会社としてQA組織の立ち上げが急務となり、日々のエンジニアリング業務の傍らQA組織の立ち上げを推進しました。
この記事ではQA組織立ち上げ1ヶ月くらいでやったことを備忘録的に共有します。この記事がスタートアップやSaaS企業におけるQA組織立ち上げの参考になれば幸いです。
この記事の対象読者
- 1人目QAの立ち回りが気になる
- スタートアップやSaaS企業でのQA組織の立ち上げに興味がある
立ち上げ前の状況と課題
QA組織立ち上げ前の開発プロセスは以下の通りでした。
リリースフロー: スクラム開発による2週間に1回の定期的なリリースサイクル
ユニットテスト: 会社やプロダクトのフェーズを考えると十分に書かれている状況・コードレベルでの品質担保への意識はある
リリース前テスト・リグレッションテスト: 業務委託のテスター、エンジニアによる探索的テスト
そして、以下の課題を抱えていました。
-
テストの属人化
一部の複雑な機能において、テストの実施が特定の個人に依存している状況に陥っていました。このため、テストがリリースのボトルネックとなることが散見されていました。 -
テストの再現性不足
E2Eテストは探索的テストで担保していたので、テストの再現性に不安がありました。また、テスト実施者によって観点の抜け漏れが発生するリスクがありました。
1ヶ月でやったこと
立ち上げから1ヶ月で次のことに取り組みました。
- リグレッションテストの資産化
- スクラム開発にQAプロセスを導入
- 中・長期視点でのロードマップを作成
リグレッションテストの資産化
テストの属人化防止と再現性担保のため、Googleスプレッドシートにリグレッションテストのテスト項目表とステージング環境にテスト用の環境を作成しました。
スタートアップという性質上、テストの作成においても速度が求められます。しかし多少時間が掛かっても詳細にテストを記載し、テストデータを用意することにしました。
以下が今運用しているテスト項目表のイメージになります。(誰が操作しても同じ結果が得られるように、テスト項目表にリンクを入れるなど多少の工夫をしています。)
ここまで作り込むことで以下のメリットがありました。
- 誰でもテストを実施できるので、テスト担当者を柔軟にアサインできる
- テスト表が仕様書として機能する
今は主にCS(カスタマーサクセス/カスタマーサポート)のメンバーにリグレッションテストをお願いしています。
CSのメンバーがリグレッションテストを通じて仕様を理解し、キャッチアップすることができるという副次的な効果も得られ、良い結果を生んでいます。
スクラム開発にQAプロセスを導入
弊社では2週間スプリントでスクラムを回しています。スクラムでのQAの立ち回りは次の通りです。
Day1〜Day8はスプリントに積まれたバックログの仕様を把握し、テスト項目表やテスト環境の用意を行ったり、テスト担当者の調整をしたりします。僕はソフトウェアエンジニアとして機能実装にも携わっているということもあり、仕様の把握は比較的容易でした。
Day8が終わるまでにコードをフリーズし、ステージング環境にデプロイしテストを開始します。
弊社のスクラム事情についてはこの記事が詳しいです。至って普通なスクラム開発×QAのプロセスだと思います。スクラム開発にQAが入ることで以下のメリットがありました。
- QAが仕様を把握する過程で、仕様の抜け漏れを発見し、早期に軌道修正を行うことができた
- テスト観点を事前に洗い出すことで、品質が高い状態でテストを開始できるようになった
実際はスクラムにQAを組み込む上で色々なルールを追加しているので、それは別記事で言及したいと思います。
中・長期視点でのロードマップを作成
足元のQA活動を実施するだけでは、QA組織が立ち上がったとは言えません。したがって、中・長期的なアジェンダにも目を向けるため、「部門立ち上げチェックリスト」を運用し、週次で振り返りを行いました。
以下は部門立ち上げチェックリストの一例です。20弱の項目があり、それに対しての達成度合いを追いかけています。
「次に取り組むべきことは何なのか」や「中・長期的にどのタイミングでどれくらいのメンバーが必要なのか」が俯瞰的に見えるため、次の打ち手を考えやすいです。
見えてきた課題と今後の展望
QA組織の立ち上げをする過程でたくさんの課題が見えてきました。以下はその一部です。
- ユニットテストで担保されるべき品質がE2Eテストで担保されている。またはその逆。
- 社内におけるQAとは何かの解像度が低い(QA=リリース前のテストをする人という認識がある)
1つ目の課題に対しては、機能単位でユニットテスト〜E2Eテストまでの全体のテスト設計の見直しを実施しています。2つ目の課題は今取り組んでいる途中なので、今後その内容を共有できればと思います。
また、テスト項目表を元に順次テストを自動化していく予定です。僕だけでは自動化する手が足りないので、一緒に自動化してくれる人を募集しています。
We are hiring!
TAIANでは、このような開発・技術・思想に向き合い、未来をつくる仲間を一人でも多く探しています。少しでも興味を持っていただいた方は弊社の紹介ページをご覧ください。
Discussion