Zenn
e-dash Tech BlogPublicationへの投稿
🙈

e-dash QAってどんな感じ？2024の振り返り

10mo8
2024/12/16に公開
ソフトウェアテスト
QA
set
品質保証
idea

はじめに

こちらはe-dash advent calendar 2024の16日目の記事です。
こんにちは！e-dashでQAエンジニアをしている10mo8です。
この記事では、e-dash QAグループを0から作り上げた2024年を振り返り、今日までの取り組みをご紹介したいと思います。

e-dash QAって？

e-dashのQAグループは、2024年5月に1人目、10月に2人目がジョインし、現在は2名体制で横断的に複数の機能開発チームの一員として、Dev、Designer、PMと連携しながら、品質向上に取り組んでいます。

QAグループのコンピテンシーは？

e-dashのQAメンバーは、「オールインワンな品質エンジニア」 を目指しています。メンバー間のスキル交換を頻繁に行い、お互いの強みを最大限に活かす体制を築いています。
特に、テストエンジニア（TE） と 自動化エンジニア（SET） の役割をあまり区別せず、品質向上に必要なスキルやアプローチを全員が使いこなせる状態を目指しています。

取り組み

ここからは、2024年の取り組みの中で特に意識してきたことを紹介します。

  1. テストガイドラインの作成
  2. テスト自動化への取り組み

1.テストガイドラインの作成

2024年当初は、ソフトウェア開発ライフサイクル（以下、SDLC）のテストで「QAグループはUIシナリオテスト[1]を担当」「開発者はそれ以外のテストを担当」と、ざっくりとした認識しか持てていませんでした。そこでテストガイドラインを作成をし、役割やテストの種類などを明文化することでQAだけでなくチームメンバーと共通認識をもたせる取り組みとして、テストカテゴリ[2]の可視化から始めました。


DevとQAのテスト分担


テストスコープ

こちらの「DevとQAのテスト分担」のイメージ図は、各テストカテゴリを担当と品質区分で分類したものです。APIシナリオテストが DevとQAの共通部分になっています。ここでは、QAが「シナリオ抽出」「テストパターン作成」を担当し、開発が「テストデータ作成」「テスト実装」「テスト実行」と責務を分担しているためです。これも、テストカテゴリを可視化する過程でAPIシナリオテストのテスト設計と実装・実行の効率化を考えてこのような責務分担としています。
テストスコープのイメージ図は、各テストカテゴリーのテストスコープを表したものです。

テストカテゴリの整理を行った結果、以下のようなポイントを明確にすることができました。

  1. 内部品質と外部品質（利用時の品質）の分類とテスト同士の関連性の理解
    • テストカテゴリを整理することで、内部品質を対象とするテストと、外部品質を評価するテストを明確に区分できた
    • また、それぞれのテストがどのように相互作用し、品質保証全体に貢献するのかを具体的に理解することができ、これにより、各テストが品質向上において果たす役割をチーム全体で共有できた
  2. テストの目的が明確化し、共通言語として定義
    • 各テストカテゴリの目的を整理したことで、テスト活動のゴールや期待される成果がより明確になった
    • テストカテゴリの名称をチーム内で共通言語として定義することにより、開発者、QA、プロダクトマネージャー間でのコミュニケーションがスムーズになる

現時点での活動成果はここまでですが、今後は、「各テストカテゴリのテスト品質可視化」として主に、クライテリアの策定を進める予定です。
テストガイドラインを持つことで、テストの抜け漏れやテスト観点の重複を無くし、テストの一貫性を保つことができると考えています。

2.テスト自動化

QAが主体で行なっているテストは、エンドツーエンド(以下、E2Eテスト)で実施される「UIシナリオテスト」と「リグレッションテスト」です。
E2Eテストは、テストスコープが広がり、テストした機能が正しく動作する自身が持てるようになるメリットがあります。e-dashでもE2Eテストはバグの発見に寄与していますが、テスト実行に時間がかかるので、フィードバックサイクルが長くなり、テストに失敗した場合、どの機能が壊れているかを判断することが難しくなります。
コストが高く、速度・決定性が低いためにデプロイメント頻度とリードタイムを大幅に低下させることになるので、テスト自動化に取り組むことにしました。
ここでは、自動テストの導入方針を記載させて頂き、具体の取り組みについては別の記事に記載したいと思っています。

E2Eテストは、Playwrightを使った自動テストと手動テストのハイブリットなテストで品質を向上させる取り組みを進めています。

「手動テスト」と「自動テスト」のハイブリッドな理由

手動テスト、自動テストには、以下のようなPros/Consあると思っています。

手動テスト

  • Pros
    • ドメイン知識をもったテスターによる経験ベースのテストは、投資したリソース（時間、コスト、労力）に対して、得られる価値（品質向上、リスク削減、エラー検出率の向上など）が高いテストが可能で、アジャイルQAには向いている
    • さらに、探索的テストを取り入れることで高いアジリティも得ることができる
  • Cons
    • アプリケーションのUIは、チームの境界線に沿って分割され手動テストの所有権も変わるため、スキルのバラつきやチーム間の情報共有が円滑でない状態は、手動テストの効果が著しく低下する可能性がある

自動テスト

  • Pros
    • 自動テストの導入で反復タスクを取り除くことが可能。テスターを解放し、より創造的でアドホックな活動が可能になる
    • テスターのリソースに依存せずテストの実行が可能になる
    • シフトレフトに寄与する
    • クロスブラウザテストの実施が容易になる
  • Cons
    • 無理のある自動化はフレイキーになり自動化の信頼性を失う。結果、自動化が衰退していく可能性がある
    • テストコードのメンテナンスに労力を奪われ、テスト自動化の目的を見失う可能性がある

Consをそのまま受け入れるには、リスクが高すぎると我々は判断しました。そのため、ハイブリッドなテストを行うことでそれぞれのProsを最大限に活かしつつ、Consを最小化していくことができることを目指しています。
現在は次のような効果があると感じています。

  1. テストカバレッジの最大化
  2. テストの深さと広さを両立
  3. テストの効率化とアジリティの向上
  4. シフトレフトを実現し、品質向上に寄与
  5. リスクの分散とテストの信頼性向上

手動テストと自動テストのプロセス方針

QAグループでは可能な限りTEとSETの境目を無くすことを前提としたテストプロセスの構築を目指しているため、TEとSETのテスト分析設計書の共通化を目指しています。
ISTQB「テスト自動化エンジニア シラバス」から引用した下記の図では「自動テストのSDLC」と「手動テストSDLC」が個別同期的なSDLCとなっていますが、この個別になっているフェーズを一体化させ、デカップリングポイント[3]を設計と開発フェーズの間に置きたいと考えています。


引用:ISTQB「テスト自動化エンジニア シラバス」

手動テストも自動テストもSUT[4]は同じである為、２つの役割（TEとSET）を持った1人のエンジニアがSUTに対するテスト要求分析を行い、分析設計まで行うのは効率的であると考えています。
ここでは、TAS[5]の分析設計に必要な具体的な項目は割愛させていただきますが、私たちは、振る舞い駆動開発（BDD: Behavior-Driven Development）のテストケースやシナリオを記述するための記法方法である、Gherkin記法を取り入れています。
現時点では、Gherkin記法はテストケースやシナリオの書き方を統一するための記述ルールとしてしか使えていませんが、今後は、要件定義からテスト設計、実装までの一貫性を高めるフレームワークとしてBDDを取り入れ、スリーアミーゴス（PM,Dev,QA）の共通理解を深めテスト品質を向上させていきたいと思います。

おわりに

他にも力を入れてきた取り組みとして、「テスト成果物の管理」があります。こちらは advent calendar 19日目でご紹介しますので、読んでいただけると幸いです。

脚注

  1. フロントエンド（UI）を通じて、バックエンド、データベース、外部サービスとのやり取りを含むアプリケーションの全体的な挙動が正しく機能していることを確認する ↩︎

  2. 特定の目的や対象に応じたテストの種類のこと ↩︎

  3. 作業の分岐点。ここでは、TEとSETの成果物作成を共通化できるフェーズを示す ↩︎

  4. System Under Test(テスト対象システム)の略。テスト対象となるシステムのこと ↩︎

  5. Test Automation System(テスト自動化ソリューション)の略。SETの役割は、テスト自動化ソリューションの設計、開発、実装、保守となる ↩︎

e-dash Tech Blog
e-dash Tech BlogPublication

Discussion