前回と前々回で、freeeのQAの目指す姿について、QAチームのみんなと話がながら私が考えたことを書いてきました。
そして、前回の最後でいきなりジャンプはできないと書きました。いきなりジャンプして、品質が低下してしまったら本末転倒だからです。本末転倒とは、以下の図のような状態です。
これでは、サービスを使ってくれる人たちに価値をあたえられないだけでなく、品質でも選んでもらえるプロダクトを作るというかっこいい世界からは遠のいてしまいます。 品質は意識して引き上げていないと簡単に劣化してしまいますので、品質を適切なレベルに引き上げて、かつ簡単には品質が低下しないようにしていくことがfreeeのプロダクトが品質でも選んでもらえるプロダクトであるために必要だと思います。 理想の状況に持っていくためには、いろいろなアクションが必要だと思っており、これから書く内容こそがいままでの3回の記事の中で、あえ共（あえて共有する、というfreeeの価値基準の1つ）して意見が欲しかったところです。（ここまでが「遠かったー」って思う人もいると思います、すんません。）
どんなアクションが必要だと思ってるか
ここから、前回と前々回で書いたようなことを実現していくためには、どんなことをしていかなければいけないと思っているかを書いていきます。思いつくままに書いてるので、全部が本当に必要かも検討不十分ですし、優先順位もまだ考えていません。「ええっ！こんなにたくさんやるの？」って思わないでください。まだ、アイデアレベルであり、この中から現実的にできることから実践していきます。
チーム自身QA（自分たちでQAする）
チームでQAをするためのテストができるようになっていくことが必要だと思います。これらができると、そのテストのために大量に人が必要ではなくなると思っています。
- 開発者全員がチーム自身でQAをやると言うマインドの醸成
- 最初の取り組みとして、QAのメンバーが開発の一員として開発の初期から参加し、スクラムのイベントに参加したり、一緒に活動をする。開発初期からQAについて考えることを常態にする。
- E2Eテストの効率化(手動でやるユーザー目線のテスト)
- テストの道具を整備し、使いたいときにすぐ使えるように道具の在庫管理する。（道具とは、計算仕様のコンペアツール、ちょっとした自動化スクリプト、繰り返し使えるテストデータなど。）
- 探索的テストのできる人材を増やすためにトレーニングなどをする。
- プロダクト横断のQAのルール決める。統合点を簡潔にしていき（これは設計マターですが）、テストも少なくて済むようにする。
- ユニットテストやサービステストを改善し、E2Eテストの前でバグ撲滅する。
- ユニットテストにてテスト技法を普通に使う人が増えるようにトレーニングなどをする。同値分割や境界値分析のような基本的なテスト技法もあるが、原因結果グラフや状態遷移テスト、All-Pairといったテスト技法も普通に使う。
- 意味のないユニットテスト（ユニットテストアンチパターン）を集めて共有し、同じ過ちをくりかえさないようにする。
- テスト結果のデータベース（テスト管理ツール）への蓄積とテスト結果分析
- 手動と自動テスト結果の蓄積をして品質リスク軽減のトラッキングし、どこまで品質リスクが軽減しているかが瞬時にわかるようにする。
- チームによる品質判断のための基準（exit criteria / definition of done）
- テストプランで合意した品質リスクが軽減されているかがまさに判断のための基準となる。
- 合意した品質リスクに対するテスト実行カバレッジのリアルタイムモニタリングのためにテストや欠陥の管理ツールで瞬時に判断可能にする。
- 内部品質（コードカバレッジなど）と外部品質（流出した欠陥）とカスタマーサポートの問い合わせを継続的に計測して相関関係をとる。
- 開発チームとカスタマーサポートの間で欠陥についての情報交換をする。
ビジネスしていく上で会計freeeのようなツールが重要なのと同じように、開発には欠陥やテストケース（テスト結果）の蓄積が重要だと思っています。手動テスト用のテストケースだけでなく、自動テスト用のテストケースも該当します。特にテスト自動化のスクリプトが増えるほどテストケース数も膨大に増えていくので、テスト結果や欠陥データの蓄積とそれらのデータ分析をするのが必要になると思います。そのデータから自分たちで品質に対する判断をできるようにしていくのがよいと思います。
予防QA
QAとしてのテストを開始する前に品質を確保し、QAとしてのテストを短縮する活動を指します。前々回では予防テストと言ってたのに、ここであえて予防QAと呼ぶのは、テスト以外の活動も含めるからです。
- QAがテストする必要がある箇所をちゃんと検討して合意
- 単体テストをどこまでやるかをテストプランで合意する。テストプランは、チーム自身QAの一環でもあるが、最初のタイミングでテストしなきゃヤバイところをちゃんと考えて、QAとしてのテストに入るまでにエンジニアがどれだけテストするのかを明確にできるのが予防QAにつながる。
- 再発防止
- 欠陥分析とフィードバックで同じ問題を繰り返さないようにする。類似の問題が潜んでないかをテストしたり、リグレッションテストのテストケースに反映したりする。
- 早期に品質確保
- リスク洗い出し会を開発初期に行い、テスト観点でのレビューとフィードバックすると、開発前に仕様の曖昧なところが見つかる。
- どのような方式で実装するか、設計をどうするかを確認することで、品質的な課題の有無を関係者が理解できる。
リグレッションテスト自動化（インパクトリスクを軽減）
QAのテストで時間がかかるテスト実行を機械に任せます。特に単純でつまらないけど、だれかが大量にやらなきゃいけないこと、例えば、会計freeeで言えば試算表や月次推移表の金額が勘定科目ごとに期首、借方、貸方、期末の金額が正しく集計されていることを1つ1つ確認するようなことは、人間の手動テストではすごく時間がかかります。金額が間違っていたら大問題なのでテストは必要ですが、時間もかかりコスト増になる上に、確認量が膨大すぎてテスト担当者が確認を間違える可能性があります。それに、確認量が膨大すぎて「いや、これ無理だろ！」って話になり、やらなくなってしまってはまずいです。なぜなら、ここで見つかる欠陥はインパクト（ユーザーへの影響）が高いからです。例えば数万を超える集計パターンをテストして欠陥が１件見つかるようなものでも、ユーザーが使ってて金額が間違ってしまったら大問題だからです。こういうものをインパクトリスクが高いと呼びます。
- リグレッション自動化対象選定（インパクトリスクの高いもの）
- ごく普通の使い方ではあるが、万が一問題あったらシャレにならないテストを洗い出す。（普通の操作はリグレッションテストに向いてる。）
- チーム自身が自動化を進めていく
- フレームワーク化とデータドリブン/キーワードドリブンを推進し、QAやSETを介在せすに運用する。（例えばプロダクトマネージャーがテストケース追加して、エンジニアが実行支援とスクリプトメンテを行う。）
- 継続的に開発と非同期に自動テストができる環境／テストデータ準備
- リグレッションテストでバグが見つかった時の速攻修正と本番適用
- 自動テストの結果をテスト管理ツールへ蓄積し、どのテストがいつ最後に実行されたか、過去にバグが出たことがあるかといったことがわかるようにする。
QAの大政奉還
まずは、アウトプット→思考（これもfreeeの価値基準の1つ）を体現して、いろいろ書き出しました。
freeeのQAの役割は、品質面でも他より抜き出てfreeeを使いたいと思ってもらえるようになるってことだと考えていますが、実は、それだけではないと思うようになりました。QAがやるべきことは、freeeの開発チーム全体の品質に関する能力を最強にするなのではないかと思います。自分たちが作るプロダクトは自分たちが一番よくわかっているので、わかっている自分たち、つまり開発者自身でお客様への価値を考えるのは自然なことだと思います。QAをチーム自身に大政奉還するのは自然の流れです。
「freeeのエンジニアはテストが本当に上手だ！」って言われるようになれば最高です。それに向かって進めていけると思いますし、できることから実現に向けて進めていければと思います。（前回も書きましたが、QAに相当するテストをする専任メンバーが開発チームにいるケースはプロダクトによってあっても問題ありません。）
この3回で書いたことのどれかは今後のQAチームのOKRに反映して活動をすすめています。今はQAとして、リリース前にテストを行うことも精一杯頑張っていますが、理想のQAとして書いたことは組織でチャレンジしていくことになります。このような世界を作るのがQAという組織の仕事です。ただし、ここに書いたアクションはだけでは足りないこともあるかもしれません。適時見直して、本当に目指す世界を実現していくためにQAはこれからも精進していきます！
おしまい。（ここまでの全３回を読んでくれたみなさん、ありがとう！）
