Synergy!はローンチから17年経ちますが、新しいアーキテクチャも取り入れています。
それにより、開発手法も変化しました。
この変化にQAチームもついていけるように、試行錯誤しながら歩んだ過程をご紹介します。
稲垣 直子（イナガキ ナオコ）品質に関わる仕事を10年以上しているせいか、プライベートでもバグを検知します。
愛犬、愛猫に癒される日々を送っています。
シフトレフトテストとは
開発者は「巨人の肩に乗れ」と言われることがあると思いますが、QAエンジニアも同様、先人から学んでいます。
ソフトウェアテストをする者には有名な ISTQB（International Software Testing Qualifications Board）という認定資格があります。
ISTQBの日本における組織がJSTQB（Japan Software Testing Qualifications Board）です。
JSTQB のシラバスには、下記の記載があります。
テストの 7 原則
1. テストは欠陥があることは示せるが、欠陥がないことは示せない
2. 全数テストは不可能
3. 早期テストで時間とコストを節約
4. 欠陥の偏在
5. 殺虫剤のパラドックスにご用心
6. テストは状況次第
7. 「バグゼロ」の落とし穴
今回は、私達QAチームが実施してきたことに絡め「3.早期テストで時間とコストを節約」について取り上げます。
「3.早期テストで時間とコストを節約」
早い段階で欠陥を見つけるために、静的テスト活動と動的テスト活動の両方をソフトウェア開発ライフサイクルのなるべく早い時期に開始すべきである。
早期テストは、シフトレフトとも呼ばれる。ソフトウェア開発ライフサイクルの早い時期にテストを行うことにより、コストを低減または削減できる。
私の所属しているチームは、以前は「テストチーム」と呼ばれ、総合テストで不具合を検知することが仕事の大半を占めていました。
ビックバンリリースを行っていた頃は、総合テスト実施期間が1ヶ月以上ということも度々ありました。
総合テストが最後の砦という意識がすごく大きかったように思います。
現在のチームは「QA（Quality Assurance）チーム」と名乗っています。 もちろん、総合テストも行っていますが、他にも品質向上につながる活動を行っています。 現在は、総合テストよりも前の活動「シフトレフトテスト」を強化しています。
シナジーマーケティングのシフトレフトテスト
シフトレフトテストでは、主に下記を行っています。
静的テスト
- 要求・ユースケース確認
- ワイヤーフレームレビュー
- リファイメント
- ユーザビリティテスト内容確認
- プランニング
- テスト観点洗い出し
- 画面・機能仕様書レビュー
動的テスト
- テスト環境での探索型テスト
QAエンジニアは、俯瞰視することが重要だと思っているため、全体のフローに入っています。
しかし、すべてに全力で関わることは効率的ではありません。
プロダクト全体が円滑に進むよう、QAエンジニアは、手戻りの大きさやリスクの大きさを鑑みて、注力ポイントを決めています。
シフトレフトテストに取り組んでいる理由
前述の通り、以前はビックバンリリースを行っていました。
しかし、モノリスからマイクロサービスアーキテクチャに変わり、開発手法も変化してきました。
マイクロサービスには開発サイクルが早くなるというメリットがあります。
しかし、総合テスト期間が長ければリリースまでに期間を要してしまい、そのメリットを享受することはできません。
開発手法は変わっても、テスト工程は変わらない。。。 まさに、総合テストがネックになっている状態でした。 これを解消するために、シフトレフトテストをはじめました。
QAフレームをつくり、シフトレフトテストの再現性を高める
実は、以前からシフトレフトテストに近いことを行っていました。 しかし「情報収集が大変」「属人化が激しい」などの課題がありました。
QAフレームは、再現性と持続可能性があるQAフローと体制を整備し、プロダクトの品質向上を目的に作りました。
QAフレームを作るにあたって、まず現状把握のために、下記を行いました。
- タスクの洗い出し
- 課題の洗い出し
「1.タスク」については「そのタスクは本当に必要なのか？」「足りていないタスクはないか？」をチーム内で話し合いました。 現状に即していない定例タスクは削除し、これからは実施すべきタスクを追加しました。
「2.課題」に上がった内容は、曖昧さが原因のものが多くありました。 これらを整理するために「QAチームが担う役目は何なのか？」「QAチームは、何に注力するのか？」を改めて考えました。
自然とやっていることをなぜやり始めたのか考えたり、頭の中で考えていることの中で一番伝えたいことは何かを考えたり、とにかく言語化することがとっても大変でした。
普段から一緒に仕事をしている人達には伝わっているだろうと思っていた事が、実は伝わっていなかったのだと驚いたこともありました。
QAフレームを作っていく中で、相手がどう思うかといった客観的な視点を常に意識し「WHAT」ではなく「WHY」を伝えることが重要なのだと感じました。
QAフレームを運用する
QA フレーム作成の過程で、シフトレフトテストがワークしていなかった原因が二つあることがわかりました。
- QAエンジニアの想いをプロダクトチームに伝えていなかった
- QAチーム内でも、何をどこまでやるべきかという基準がなかった
そこで、以下のアクションを実施しました。
QAエンジニアの想いをプロダクトチームに伝えていなかった
QAフレームをプロダクトチームに共有し、QAチームの想いやミッションを伝えたところ、下記のように言ってもらえました。
「実は〇〇の資料をつくっているので、今後は共有しますね！」
「〇〇のミーティングにも参加してもらった方が良いね！」
「情報収集が大変」と思っていましたが「誰に聞けば良いかわかる」「資料を共有してもらえる」「内容を説明してもらえる」という状態に変わりました。
QAチーム内でも、何をどこまでやるべきかという基準がなかった
担当者任せになっていたタスクは、下記を決めました。
- どのタイミングで
- 何を
- どこまでやるか
チェックポイントを設け、チェックリストや記録を残すことで可視化をすることにしました。
「属人化が激しい」と思っていましたが、仕組み化することで属人化の解消ができました。
さいごに
シフトレフトテスト成功の鍵は『コミュニケーション』だと思います。 違う立場にいる人と同じ目的に向かって進むには「WHAT」ではなく「WHY」を伝え、まずは目的や背景を共有することが重要だと思います。 そして、相手の立場を理解する事によって、より柔軟なコミュニケーションができるのだと感じました。
今回の課題に取り組むにあたり、たくさんの方に快くご協力いただきました。 良いプロダクトを作ろう！という思いはみんな同じなのだと改めて感じました。
QAフレームの運用はまだ始まったばかりですが、これに留まらず、そのときのプロダクトに合った品質向上活動を行っていきたいと思います。
