STORES 決済アプリリニューアルとQAチームの取り組み ~システムテスト編~

はじめに

(こちらの内容は2022年3月10日,11日に開催されたJaSST’22 Tokyoで発表させていただいた「STORES 決済アプリリニューアルとQAチームの取り組み」の内容を修正、加筆したものです。)

STORES 決済 QAチームの山﨑です。
STORES 決済アプリリニューアルプロジェクトのQAチームの取り組みについてお話しさせていただきます！
今回はQAチームで行ったシステムテストについてです！フィールドテスト編はこちら！

システムテストで何が起こったのか？

QAチームのリニューアルの検証はシステムテストから始まりました。
システムテストでは「リニューアル後に現行アプリと挙動が変わっていないこと」の確認を目的として検証をしました。
ですが、検証において内部環境・外部環境両方に課題がありテストが円滑に進まない状況が続いていました。
内部環境のマイナス要因にはプロジェクトが長期化したこともあり担当メンバーの入れ替わりが発生してしまっていたことが挙げられます。
ですが、こちらのマイナス要因がきっかけとなり、分析設計者・テスト実行者共に新メンバーが参画してポジションを割り当てられることとなり、各自が成長しながらテスト活動を進めていくことができるようになりました。

また、コロナ禍という社会情勢もプロジェクトに影響を与えました。
テスト期間がコロナ禍と重なっており、リモート勤務になったことで複雑な機材調整が発生して進捗が遅れることがありましたが、このリニューアルプロジェクトをきっかけに機材管理や調整方法を見直しました。
現在もリモートワークは続いていますが、リモートワーク時の機材の調整はこのプロジェクトがきっかけで今ではスムーズに行えるようになりました。

システムテストでは他にも課題を抱えていましたが、その中でも今回は「リソースの不足」「機能仕様書の不足」の2点について掘り下げたいと思います。

システムテストの課題解決

「リソースの不足」を解決するための2つの取り組み

1つ目はテスト設計の効率化を図りました。組み合わせテスト技法を活用したテストケース数の最適化、リスクベースドテストを活用しテストの優先順位・実施順番を決めプロダクトリスクを減らすテストを実現しました。
2つ目はテスト実行の効率化を図りました。リニューアルのプロジェクトが動き出した後も、他プロジェクトに人的なリソースをとられて中々進まない状況が常態化していました。こうした状況下でプロダクトマネージャーや開発チームとやりとりを重ねる必要性が増えたので、可視化された情報を共有する為に日頃からコミュニケーションをとる機会を増やしました。 QAチームの工数が不足している現状などを共有し、テストスケジュールの見直しを行うことで、実施者を流動的に配置することが出来るようになり　全体的なテスト生産性の向上につながりました。

「機能仕様書の不足」を解決するための取り組み

アプリリニューアルでは、アプリの全機能を細かく通すテストをする必要があります。ですが、機能仕様書が不足していることや、過去のテスト実績から流用できる資産も少ないことが問題となり、テストケースを作成するまでのハードルが高いテストでした。これらの問題を解決するために、Specを充実させていこうという動きが生まれました。開発チームとQAチームが一緒になってSpecを作り込むことで、機能ごとのテスト要求の理解度が増し、テストスコープが明確になりました。またSpecで仕様が可視化されることでテスタビリティも向上し、作成するテストの信頼度も上がりました。 Specはアプリリニューアル以降のテスト活動においてもテストスコープ決めや、仕様把握などで活用できる資料となり、現在に繋がるQAチームの資産となりました。

まとめ

システムテストではリソースがさけない、動き出しても仕様不足などテスト活動がうまく進まない…といった困難な状況の中で課題を解決していくことで、プロジェクトを通じてチーム間の繋がりが強固になっていき、情報共有と相互理解が進み、プロジェクトの進行がスムーズになっていくのを肌で感じる毎日でした。今ではそこで培った関係性が後続のプロジェクトの進めやすさに活きていると感じています。