Photoruction工事中!

Photoructionの開発ブログです!

Photoructionリリースするまでのテストについて(今ある課題と今後の取り組み)

こんにちは!株式会社フォトラクションでQAグループのリーダーをしている塩谷です。 Photoruction Advent Calendar 2021の8日目の記事です。

 

本日はPhotoructionを開発していく中でどのように品質を担保しているのか広めたいと思い、リリースするまでのテスト業務について記事にしてみました。

目次


1.はじめに
2.リリースまでのプロセス
3.開発環境でのテスト
4.リリース環境でのテスト
5.課題と今後

はじめに


私の経歴とフォトラクションのQAグループについてご説明いたします。

 

私は、大学卒業後に某SIer企業に入社いたしました。そこでは仕様策定や評価業務など様々なプロジェクトに従事し、プロダクト開発における上流工程〜下流工程の経験とスキルを積みました。

フォトラクションに入社する直前にはプロジェクト管理者として評価プロジェクトの管理を行っており、その経験が今に繋がっていると感じています。

 

2020年5月に縁があってフォトラクションに入社することになり、その際にCEOの中島からはQAグループを作って欲しいというミッションが与えられました。

当時のフォトラクションにはQAグループが存在しておらず、開発における評価業務はエンジニアがテスターにテストを依頼するという形をとっていました。

ゼロからQAグループを作ることになったので手探り状態でしたが、身の回りの細かいことからコツコツと進めていくことで今のQAグループが出来上がってきたと思います。

リリースまでのプロセス


Photoructionが開発されてからリリースされるまでのプロセスについてご説明いたします。

現在おおよそ1ヶ月に1回新規機能のリリースを行なっており、その際は下図のような開発フローを採用しております。

リリースまでには大きく分けると開発フェーズとリリースフェーズの2つのフェーズが存在しています。

  1. 開発フェーズ
    各開発のフィーチャーブランチで実装を行い、開発環境を作成してテストするフェーズになります。実装〜テスト・各種レビューまで行い開発フェーズが終了します。
  2. リリースフェーズ
    リリースブランチを作成して各フィーチャーをマージしたリリース環境でテストするフェーズになります。 バグが発生したらその都度改修を行い、バグの改修が完了したらリリースフェーズが終了します。

f:id:photoruction_tech_blog:20211202151623p:plain



開発環境でのテスト


開発環境のテストでは、単体テスト結合テストに位置付けられるテストを実施します。

各開発案件にアサインされているQAエンジニアがテストケースを準備し、テスターにテスト実施を依頼します。

テストケースの内容は企画書・仕様書から機能的な確認項目を作成し、QAグループ内のレビュー、PM・エンジニアとのレビューを経て完成します。

それぞれの開発に対して環境を準備してテストすることで開発毎に品質を確保した上でリリース環境にマージしリリースフェーズに臨みます。

各開発についてリリースターゲットはあらかじめ計画していますが、開発環境でのテストをパスできない場合は、リリースターゲットの変更など対策を行います。

リリース環境でのテスト


リリース環境のテストでは、各開発のテストケース再走行とリリース前テストを実施します。

テストケースを再走行する目的は、マージ後の予期せぬデグレの検出となります。

Photoructionは機能的にも実装的にも複雑化しており、各開発をマージした後に予期せぬバグが発生することがあります。

そのため、マージ後の環境でテストケースを再走行することでバグ流出を防ぐように取り組んでいます。

テストケースの実施とバグの改修が完了したら、リリース前の最終テストを実施します。

リリース前テストは開発内容によらず固定のテストケースを実施しており、

内容は全機能の基本的な動作の確認になります。

以前はリリース前テストは実施していませんでしたが、リリース物に対して総チェックを行うべきとの考えからリリース前テストを実施することにしました。

導入した当初は開発に関わるものそうでないものなど様々なバグを検出していましたが、徐々にバグ検出数が減少し、品質が向上してきていると考えています。

全てのテストをパスしたらリリースされます。

課題と今後


フォトラクションのQAグループでは、様々な課題を抱えておりますが、

当然ながら最も重要な課題は市場へのバグ流出を防ぐことだと考えています。

「リリース環境でのテスト」の項でもご説明した通り、リリース環境では各開発の2サイクル目のテストを実施しております。

マージによるデグレリスクを低減させることができれば、同じテストを2サイクル実施するのではなく、別の観点でのテストを実施することで今まで防げなかったバグの流出を防げる可能性が出てきます。

デグレの低減についてはQAグループだけの取り組みでは、改善させることが難しいので開発部門と連携をしながら改善に取り組んでいます。

また、リリース前テストなど定型的なテストについては、自動テストの導入に取り組んでおり、自動テストでまかなえるテスト工数の分だけ別のテストを導入することができます。

自動テストは誰でも実行できるようにすることで、例えばエンジニアが任意のタイミングで実行し早期にデグレなどのバグを検出できる効果も期待できます。

他にも発生したバグ分析やバグの発生数を減らす施策の検討などQAグループとして課題は多く残っている状況ですが、QAグループがリリースされる前に最後までPhotoructionを触っているので”最後の砦”とという自覚を持ち、地道にコツコツと品質を上げていけるようにこれからも努力を続けていきたいと思います。

 

 

今回の記事を通してフォトラクションも品質を向上できるように考えているということが少しでも伝われば幸いです。

ありがとうございました。

 

株式会社フォトラクションでは一緒に働く仲間を募集しています