QA業務の認知度向上
はじめに
QAグループのokapiです。
私は、QAの主担当として案件に参画させて頂くことが多いため、今回は、KINTOテクノロジーズ株式会社で、QAが案件に参画して、どのように開発チームとコミュニケーションを取って、作業を進めているかを記事として作成します。
本記事の目的
QAと関わったことがないチームと案件を進める場合、
QAは何をやってくれるのか、どのように進めてくれるのかと探り探りで進む事が多いので、
そういった場合でもスムーズに進められるように「QAの認知度」をあげたいと思っております。
QAとは
QAは、「Quality Assurance」の頭文字をとってます。
「Quality Assurance」は、「品質保証」という幅広いとらえ方となりますが、
「ユーザーにとって不利益が生じていないか」「ユーザーが使いやすいか」という観点で、
ユーザーの実際の利用想定に基づくシナリオテストや、画面UIの検証といった、
ユーザー視点でのテストを実施しております。
主なQAと開発チームのテストにおける役割分担に関しては、下記の表に記述します。
項目 | QA | 開発 | 備考 |
---|---|---|---|
システム要件に沿った 仕様の確認 |
ㅤ◎ㅤㅤ | ㅤ〇ㅤㅤ | QAは、システム要件通りに機能と性能が満たされているかを、ユーザー視点を踏まえて確認 |
ユーザーの利用を想定したシナリオに沿った確認 | ㅤ◎ㅤㅤ | ㅤ△ㅤㅤ | QAがメインで確認 |
上記以外 | ㅤ△ㅤ ㅤ | ㅤ◎ㅤㅤ | 依頼があった場合、開発チームの外部結合テストやQAが確認可能な範囲でリソース的に問題なければ確認 |
QA作業の概要
作業フェーズ | 概要 |
---|---|
テスト計画フェーズ ㅤㅤㅤㅤㅤㅤㅤㅤ | プロジェクト全体のスケジュールと仕様が分かる資料(システム要件、画面仕様書等)を連携頂き、QAが以降のフェーズの作業をどのように進めるかを記載したテスト計画を作成 |
テスト分析フェーズ | 仕様が分かる資料(システム要件、画面仕様書等)から、 テスト範囲(テスト対象/対象外)を明確にしたテスト観点を作成 |
テスト設計フェーズ | テスト観点からテストケース(前提条件・手順・期待値)を作成 |
テスト実施フェーズ | 作成したテストケースを基にテストの実施を行い、 不具合報告・改修確認を行う |
開発チームとコミュニケーションが必要な点
テスト計画フェーズ
QAがテストを実施する期間/検証環境/QAの実施担当者・開発チームの窓口担当者/
対象端末・ブラウザを纏めたテスト計画を基に開発チームと認識がずれていないかを確認します。
テスト分析フェーズ
テスト観点を作成するために必要な情報は、JIRA or Confluenceを活用して質問し、
認識が合わない部分や開発チームの担当者が複数になる箇所は、
打ち合わせを行い確認して、仕様を整理します。
仕様が整理できたら、テスト範囲(テスト対象/対象外)を明確に分かるような
テスト観点を作成して、開発チームと認識がずれていないかを確認します。
テスト対象/対象外については、ブラックボックステストの観点から、
ユーザーが実際に使う部分(QAが案件で必要だと思った所)を対象として、
ユーザが触れることのない部分(たとえばシステムの管理画面等)を対象外としております。
ただ、シナリオテストで一連の流れの確認も行うため、ユーザー側のテストで通る部分は、
対象外部分でもテスト対象となります。
※リグレッションの箇所については、品質が保証されているので、
連携頂いた期間とリソースを基にどこまで対象とするかを調整しています。
テスト設計フェーズ
テストを実施するための手順を確認しますが、
テストケースについては、テスト観点で認識あわせた箇所に基づいて作成するため、
開発チームとの認識合わせは、ここでは基本行わないです。
テスト実施フェーズ
不具合(仕様と異なる期待結果)、
質問(仕様として存在しない、もしくは仕様が不明瞭な箇所)、
改善要望(仕様と一致しているがユーザーに分かりづらい箇所)をJIRAで報告、
開発チームで対応(修正)後に、QAチームで再確認をしてます。
テスト実施は、テストケース+上記JIRA起票分の対応を含み完了 or
残っているJIRAの起票分が今回のQA確認対象外になった場合に終了となります。
実施が完了したら、全体の振り返り(KPT分析等)に参加して、
改善点を相談させて頂き、今後の案件に活かすようにしてます。
今後の課題
プロジェクトやプロダクトによって、「資料の纏め方」が異なる事があるため、
JIRA or Confluenceで仕様の認識を合わせた上で、QAでも、
ユーザーに関わるシステム全体の仕様やシステムの流れを資料に整理して進めています。
ただ、システムの規模によっては、時間がかかる箇所となりますので、
QAチームでの纏め方や進め方を整理した上で、開発チームと円滑なコミュニケーションを取り、
効率良く「QAチームで仕様を正しく理解するためのまとめ作業」をできるようにしたいです。
さいごに
QAチームが独立した組織になってるので、
開発チームからみるとQAチームに作業を依頼してる形になり、
テストをやってもらっているという認識になる事がありますが、
QAとしては、同じKINTOテクノロジーズ株式会社の一員として、
品質の良いシステムを一緒に作り上げたいと思っております。
そのため、今後も協力的な関係を築き上げていきたいです。
関連記事 | Related Posts
We are hiring!
【QAエンジニア】QAG/東京・大阪
QAグループについて QAグループでは、自社サービスである『KINTO』サービスサイトをはじめ、提供する各種サービスにおいて、リリース前の品質保証、およびサービス品質の向上に向けたQA業務を行なっております。QAグループはまだ成⾧途中の組織ですが、テスト管理ツールの導入や自動化の一部導入など、QAプロセスの最適化に向けて、積極的な取り組みを行っています。
【部長・部長候補】/プラットフォーム開発部/東京
プラットフォーム開発部 について共通サービス開発GWebサービスやモバイルアプリの開発において、必要となる共通機能=会員プラットフォームや決済プラットフォームの開発を手がけるグループです。KINTOの名前が付くサービスやTFS関連のサービスをひとつのアカウントで利用できるよう、様々な共通機能を構築することを目的としています。