"QAエンジニア"を整理する
こんにちは。kubopです。
今回は"QAエンジニア"を整理して考えてみます。
QAエンジニアは定義が広く、
テストをしている人？あぁ、QAエンジニアね。
テスト自動化？あぁ、QAエンジニアね。
と十把一絡げになっているのではと感じて自分でもわからなくなってきたので、QAエンジニアの種類やどんな品質をどのように保証しているのかを整理しました。
※ まだまだ理解しきれていない部分があるため、解釈が異なる点があるかもしれません。
QA : Quality Assurance : 品質保証の整理
QAとは何か
IT業界で最近話題のQA。そもそも巷で噂のQAってなんだろう。
辞書を見てみると…?
ひんしつほしょう【品質保証 quality assurance】
QAと略称することが多い。JISにおいては，〈消費者の要求する品質が十分に満されることを保証するために，生産者が行なう体系的活動〉(JIS Z 8101)と定めている。
品質とは何か
ひんしつ【品質 quality】
品質とは一般的に、使用目的に応じた商品の有用な自然的属性（物理的および化学的諸性質）に基づいた実質的性能や消費に役だつ一定の機能を意味している。
原材料を加工して商品を生産するとき、商品の価値面は、価値（交換価値。価値の大きさが抽象的で、現象面は価格で表される）と使用価値（価値の大きさが具体的で、主として目で判断でき、現象面は品質で表される）の二つが創造され、この両者が統一されて商品価値が形成される。
QAは、製品品質と、利用時の品質を保証すること
つまり、プロダクトの交換価値と、使用価値を保証するお仕事のことらしい。
SQuaREの、製品品質と、利用時の品質とほぼ同じだと思う。
どのように品質を保証するか
では、その製品品質と、利用時の品質をどのように保証するのか。
ソフトウェアの品質というのは、突然現れない。
プロジェクトマネジメントと、ソフトウェアエンジニアリングの堅実なプラクティスの結果である。
製品品質保証
製品の品質は、システムの静的・動的両方の特質にフォーカスした8つの特性。
例えば、機能は仕様に基づいているかとか信頼性やセキュリティ、保守性の担保。性能や耐久性といった製品品質に対して、実際にユーザ が利用する際の有効性や満足度、危険な状況を招かないリスク回避性など。
冷蔵庫で例えると、ものを冷やす能力や何年も利用出来るかとかだと思う。
アプローチ方法としては、テスト技法を用いた不具合検出/集計、自動テストによるスケーリング、アジャイル・スクラムを利用した開発プロセスに関与した改善がある。
具体的には、仕様の要件定義や手動でのテスト、オブジェクト指向による実装、TDD、DDD、デザインパターン、ユニットテストによる命令網羅、E2Eテスト、性能・負荷テスト、アジャイル、スクラム開発などだと思う。
利用時の品質保証
ある特定のコンテキストで製品が利用されることを考える場合の5つの特性。
例えば、製品はユーザーにとってどんな価値を提供出来るかとか、ユーザービリティということになりそう。
冷蔵庫で例えると、清潔に保ちやすいか、ドアは開けやすいかとかだと思う。
言うなれば、ユーザーの主観的評価、UIUXのことになる。
アプローチ方法としては、実装前の仕様へのレビューや、経営方針、企画のレビュー、ユーザーレビューなどだと思う。
QAは、主に製品品質を技術的に保証する
保証範囲は主に製品品質、これらを様々な技術的アプローチで保証する。
テスト技法を用いた不具合検出/集計。
自動テストによるスケーリング。
アジャイル・スクラムを利用した開発プロセスに関与した改善。
などがある。
QM(Quality Management)ファンネル
テスト技法を用いた不具合検出/集計。
自動テストによるスケーリング。
アジャイル・スクラムを利用した開発プロセスに関与した改善。
QMファンネルという概念があり、
これらは、それぞれTE/SET(PE)/QAといった具合に分けられる。
ん？QAエンジニアはTEやSETには含まれないの？と思ったのですが
QAはQMに内包し、組織能力を高める職能に属するらしい。
さらに、ファンネル(漏斗という意味)ということでそれぞれのロールには深さがある。深さは、そのロールへの実業務の近さを表す。
QAファンネル
チーム全体の品質を向上させる。
開発プロセスや、プロジェクトの振り返りや、品質戦略を立案し、組織に対して能力を発揮する。
アジャイル・スクラム開発など。
TEファンネル
テストやレビュー、メトリクス測定など、製品やサービスを評価する能力を発揮する。
テスト技法・集計・分析など。
PE(SET)ファンネル
E2Eやユニットテストの自動化、CI/CDや自動化に対して能力を発揮する。
エンジニアリング文化、自動テストの書き方などにも関与する。
E2E・ユニット・自動テストなど。
深さ
スプリット（フェーズ ゲート）
開発現場とは別で業務をする。
別軸で動き、ペースメーカーとして役割を発揮。
インプロセス
開発現場で業務をする。
同軸で動き、問題があればミツバチ・アラームとして役割を発揮。
コーチ
開発現場へ出向き、技術・文化浸透させる。
コンサルタント
組織を横串で連携・技術向上を展開する。
プロモーター
組織全体に技術・文化浸透を推進する。
参考・合わせて読みたい
🤔
QMファンネルについて
TE・SET・QAの種別は明確に分けるというよりも、個人的にはその中を泳いでいけるような組織が良いのではないかと思いました。(人数の制限もあるし)
もちろん業務の種別として分けるべきで、どのようなスキルセットを伸ばしていくか、エキスパートとしてどのような方面に行くかを決める指標になると思います。
また、どこを伸ばせば製品品質の保証につながるか、業務の比率を考える指標にもなると思いました。
深さについて
人数が限られている組織では、スプリット・インプロセスはチームに内包したメンバが品質大臣として存在し、開発も出来るようにする。
コーチ・コンサルタント・プロモーターは別軸として存在していくのがいいのかなぁと思いました。
1人目QAとして…
もし、1人目のQAとして配属されるならば
TE : SET : QA = 2 : 2 : 6くらいの割合のスキルセットが必要になるなと思いました。
テスト技法や、自動テスト、それ自体を行う前提条件として
組織を動かす・影響を及ぼすことが必須だと思うので、QAのスキルセットが重点的に必要になってくるのではないかと思います。
仲間を増やしていくにしても、それぞれがQM全体を考えられるような形がいいような気がしますし、チームのエンジニアもTEやPEの知識があり、全員野球で品質向上が出来るといいのかなぁと思います。
お気持ち
QAもPEもTEのスキルもまだ全然ないのですが
— kubop/ note inc. (@kubop1992) May 14, 2022
QMファンネルを見ると何を勉強するとどこが高まり、何を発揮出来るかがわかるようになるのが良いのだと思いました。
QAエンジニアってスクラムマスターと近くない？と思ったので調べた結果。
この記事が気に入ったらサポートをしてみませんか？