見出し画像

プロダクトチームと協調して改善する、テストプロセス

こんにちは、アルプでQAエンジニアをやっていますnametakeです。

最近QAチームが発足し、プロダクトチームと協調してテストプロセスを改善しています。

QAチーム発足以前でも、プロダクトチームでユニットテスト、E2Eテスト、リグレッションテストや手動テストなどは行われていました。ただ、それでも一定不具合は発生していて、プロセスのどこを改善すべきなのかという悩みがありました。

この記事では、QAチームが現状のテストプロセスを整理し、リリースフローや自動テストを改善した話をします。

現状のテストプロセスを把握する

現状のテスト状況を把握するため、JSTQBのシラバスに記述されているテストレベル・テストタイプを参考に、社内の活動を以下のように整理してみました。

JSTQBを参考に現状を整理したテスト分類図

整理してみると、以下の課題があることがわかりました。

  1. スケジュールが後ろ倒しになることで、システムテストの時間が十分確保できていない

  2. 統合テストの自動化の仕組みが整っておらず、機能開発時点で統合テストが作りづらい

上記の課題に対応するために、1.に関してはリリースフローを改善し、2.に関してはQAチームで自動化の仕組みを整えました

十分なテスト期間を確保するために、リリースプロセスを改善

アルプでは一週間に一度リリースをしており、dev環境 → staging環境 → production環境の順番に押し出されるような形でリリースをしています。

受け入れテストやシステムテストは、staging環境にデプロイされてから実施していました。

開発規模が大きくなるにつれて、staging環境で不具合が見つかることが多くなり、差し戻しが発生したり、修正に対して十分なシステムテストと受け入れテストが行われていないという問題がありました。

以前のリリースフロー

そこで「機能テストは、プロダクトチームがstaging環境にデプロイする前に確実に終わらせる」という状況を作るため、以下の取組みを実施しました。

  • プロダクトチームに向けて現状の課題とリリースフローの変更を周知

  • プロダクトチームで使用するテストドキュメントのテンプレート整備

  • 機能テストをdev環境で終わらせるための必要な環境や仕組みの整備

取り組みは、すぐに効果を発揮し、プロダクトチームでテストについての議論が活発化し、仕様漏れや不具合の検知が進みました。

現状整理に使ったテスト分類図は、今まで個々に閉じ気味だったテストの知見がチームのものとなり、大きな効果を発揮したと思います。

自動化の仕組みをQAチームで整備

コードで管理できる自動テストの整備

アルプでは自動テストとして、ユニットテスト、Postmanの統合テスト、Autifyのシステムテストを導入しています。

上記テストを実施しているのですが、コードにならないテストというのはメンバーにとって高コストになっていました。PostmanやAutifyが追加されづらく、メンテナンス性も低いという問題が発生していました。

他にも、PDFや外部のサービスとの連携部分といったユニットテストだけでは確認するのが難しい箇所に不具合が偏在しており、これらを確認するための手段を増やす必要もありました。

QAチームでは、上記課題を解決するために、画面からの自動テストの手段としてPlaywright、APIの自動テストの手段としてGatlingを導入しました。

これの導入は、プロダクトチームが開発をしながら片手間で着手するのが重たかったため、QAチームで改善に着手しました。

まだ環境を整えたばかりですが、プロダクトチームでPlaywrightやGatlingを使用したテストを追加する流れが徐々にでき始めています。今後もプロダクトチームと協調しながら自動テストのメンテナンスを進めていきます。

既存の自動テストの整備

コードで管理できる自動化の手段として、PlaywrightやGatlingを増やしましたが、全部乗り換えるのではなく、引き続き既存のPostmanやAutifyを運用しやすくするための整備をしています。

Postmanは、Collection同士の依存関係が発生していて、新しいテストが追加しづらい状況でした。そのため、それらを解消するためにCollectionの一斉整理を行いました。

Autifyは、テストの目的が曖昧になっていたテストも存在していたため、Autifyのシナリオを作成する時にはテストドキュメント作成し、シナリオの概要に紐つける運用を徹底しました。

また、Autifyの比較的大きなシナリオのテストが開発が進むことにより陳腐化していたので、なるべく小さく対象を絞ることでメンテナンスしやすい形にしました。

今後の自動化の取り組み

アルプでの自動化の取り組みについて話しましたが、まだ現状の課題に合わせて対応しただけです。引き続き開発の実情に合わせてチューニングしていく必要があります。

また、自動化の仕組みを作ったとしても、質の高いテストをするにはテスト技術の知識が不可欠です。本来はプロダクトチームにテスト技術をインプットしながら行っていく必要があるのですが、まだ十分とは言えません。

今後はQAチームが、どんどんプロダクトチームに入りつつテスト技術をインプットしようと思います。他にも、不足しているテストを拡充していく施策も行っていきます。

今回の記事を見てアルプに興味がでた方は、ぜひお気軽にお声がけください。



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