こんにちは。QAエンジニアの丸山です。2023年12月にアソビューにジョインし、現在は自社サイトを中心としたQA業務を行っています。
弊社では以前にもQAチームの体制についての記事を公開していました。その中で、”QMファンネルのバランスは必要だが、そのロールに囚われすぎず、本質的な品質改善につながることを意識し実行する、変化にも強いQA実行を目指す”といったことが記載されていました。私が担当するサービスにおける役割がテストエンジニア（TE）だけでなくQAとしての活動を実行する転換期にあたり、その点について具体的な状況や取り組みをご紹介したいと思います。
▼前回のQAチームの記事
QA体制の過去〜現在〜未来 - asoview! Tech Blog
▼その他過去のQAチームの記事
アソビュー！QAチームの紹介 - asoview! Tech Blog
◼︎担当プロダクトの現状
私が担当する個人のお客様向けのサービスは2023年の夏頃からQA体制の再構築が行われ、弊社のQAエンジニアがアサインされて業務を行っています。
それ以前は外部の第三者検証会社に参画いただいてテストを実施してもらったり、開発者自身でテストをしたりといった形で、QA業務を行なっていたそうです。
そうした変遷を経て、新たなQA体制構築がスタートしました。
現在は私含め3名のQAエンジニアが業務にあたり、複数ある開発チームに横断的に関わりながらサービスのテストを主に行っています。
ただ、本来のQAの意味合いを考えるとテストを実施するだけでは不十分な状態かなと感じることも多いです。
◼︎QAという仕事について
と、ここまでの説明の中で『テスト』と『本来のQA』という言葉の使い方に違和感を覚えた方もいらっしゃるのではないでしょうか。
組織によっても異なるとは思いますがQAとテストという言葉を同義で使っている現場も結構多いのではないでしょうか。弊社の開発現場でもテストという意味合いでQAと言っている場合も結構あります。
言葉の訳だけを見れば
QA ＝ Quality Assurance ＝ 品質保証
ということで品質保証全般（もしくはその担当者）を指す言葉ですが、
ソフトウェアテストの技術者資格のシラバスを見てみるとQAとテストについてはこう書かれています。
「テスト」と「品質保証」（QA）という用語を同じように使う人が多くいる。しかし、テストと品質保証は同じではない。テストは品質コントロール（QC）の形式の 1 つである。
参考：JSTQB認定テスト技術者資格-シラバス（学習事項）・用語集-
もちろん、QAエンジニアという職種をより細かくみていくとTE（テストエンジニア）という職種もあります。QAエンジニアがテストを主に担当していくこともありますが、品質を保証する目的の中ではテストは手段の一つであって、主たる目的ではないということですね。
その上で、先程のシラバスにはこうも書かれています。
QA は、プロセスの実装と改善に焦点を当てた、プロセス指向の予防的アプローチである。よいプロセスが正しく行われれば、よいプロダクトを作ることができるという考えに基づいている。
現状、テストをすることで向上させようとしている品質はお客様が使用するサービス（最終成果物）の品質で「プロダクト品質」という分類になる品質です。
これに対して、「プロセスの実装と改善」が目指すのは「プロセス品質」という品質の向上です。
例えば設計の際の手順は適切だったか、設計・実装段階のレビュー方法は適切であったか、テスト設計や要素選定の方法は適切であったかといった 各工程の作業のプロセスを適正で質の高いものにすることで、生み出される成果物の品質（プロダクト品質）の質を上げていく取り組みになります。
「でも、しっかりテストして不具合を発見・修正しきれば別に良いのでは？」
という考えの方もいらっしゃるかもしれませんが、全体を確認するシステムテストの段階で見つかる不具合は、多くて全体の55％なんていう数字もあります。
参考：https://codezine.jp/article/detail/13777
Beizer のバグ検出より抜粋
ですので、各工程のプロセス品質が低く、作り込まれる不具合が多ければ多いほどリリース時の品質も下がるということになります。
開発スタイルがウォーターフォールかアジャイルかなどでも違いはありますが大まかなイメージとしては以下のような結果の違いになります。
Bの方が各工程での品質が高い分、リリース時の品質が高くなりますね。
このような、各工程毎の品質を向上させることが最終的に公開するサービスの品質につながるという考え方のもとで開発工程にアプローチしていくというのが本来のQA活動の目的となっていきます。
もちろん、テストがおざなりでもよいという話ではありません。プロセス品質の改善の対象はテスト工程も含んでいますし、テストも行なっていきます。
バグを見つける為のテストというだけではなく、バグの統計をとり、どの工程での混入が多いのかのなどを分析し、工程毎の品質の向上に役立てる為の指標としてもテスト結果を使用していくことになります。
◼︎TE業務だけでなくQA業務へ
以上の通り、QAエンジニアは直接生み出されるプロダクトの品質だけでなく、プロセスの品質向上も視野に入れた業務が求められます。
その点を考慮して、テスト実施だけでなくプロセスに働きかける取り組みも少しづつ行っています。
◻︎実際の取り組み
すでにテストの実施を主な業務として担当している状態でしたので、まずはテストと並行して行える方策をとりました。
具体的には、テスト実施の前の工程であるテスト分析・設計の段階からレビューに開発メンバーも参加してもらうようにしています。
どういった観点・どういった要素の組み合わせでテスト項目を作っていくかを開発者も交えて擦り合わせることで、テストの品質の向上（必要なテストは行い、不要なテストは無くす）だけでなく、開発者側でも作る段階で考慮すべき要素に抜けがなかったかを考えられる機会になればという目的もあっての取り組みです。
実際、テスト設計レビューの段階で実装の考慮漏れに気がつくことができたといったケースもあり、少しづつですが効果は出ていると感じています。
また、新体制で稼働し始めて1年弱が経ち、テスト結果の履歴も溜まってきました。それらを分析して各工程のプロセス品質向上のための施策を打てないかについても徐々に検討が始まっています。
今後はテストだけでなく、工程別の品質向上施策もQAエンジニアと開発者で協力して対応を進めていくことになると考えています。
◻︎現状の課題
以上のような取り組みを行なっていく中で対応するべき課題もあります。
・ドメイン知識の不足
QAエンジニア側の課題として、担当サービス全体に関する知識が不足しています。
体制が変わってからまだ1年という段階のため、個々人に知識の蓄積がないことは致し方ない面もあります。ですが、テスト分析・設計を通して開発側の設計・実装の品質に役立てられる提案をする為には、まだ知識が不十分であるということは事実です。
・QAエンジニアの関わり方の差
複数ある開発チームそれぞれでQAエンジニアの関わり方に差があります。開発案件に定常的にQAエンジニアが関わるようになっているチームもあれば、まだ全くQAエンジニアが関わらないチームもあり、ばらつきがある状態です。
◻︎課題への対応
こうした課題について以下のような対応を行い、改善を進めようとしています。
・ドメイン知識を得る機会を増やす
テスト作業の中で機能について調べるだけでなく、開発部門への他部門からの機能仕様の確認や調査依頼として上がってくる問い合わせにも対応しています。問い合わせを受けた際に関連する機能について調べることで知見を得る機会を増やすことが狙いです。
また、得た知識を展開できるようドキュメントの整備や他の開発チームのQAメンバーとの共有会なども行なっています。
・効果・実績を共有する
まずは今稼働しているチームでの取り組みについて効果があった方法を共有・展開していくことでQAが関わる状況をイメージしやすくできたらと考え、準備を進めています。小さなタスクからでもQAエンジニアが参加できそうな案件を見つけ、そこから段階的に関わりを深めていきたいと考えています。
◼︎さいごに
今回はQAエンジニアが関わっている業務の一部をご紹介しました。
個人的には、テストで不具合が見つかった場合、「報告」「修正」「修正の確認」といった工数が発生するので、テストを設計している時点で開発者にも内容を共有して、テスト時にNGにならないようにしたいなという考えを持っています。
結局のところ、品質の高いサービスを素早くリリースすることが重要なのですから、テストで不具合を見つけることを目的にする必要はないですよね。
”テストは特に問題ないことを確認する作業”として業務できる、品質と生産性が高い状況を作れるよう努力しています。
