◯ はじめに
エモーションテックに2ヶ月前にjoinしましたQAエンジニアの中島です。
私はウォーターフォール開発（以降、従来型開発）の現場に長くおり、アジャイル開発でのQA活動はエモーションテックが初めての経験となりました。
QAとしてのベース部分は変わりませんが、QA to AQ（Quality Assurance to Agile Quality：品質保証からアジャイル品質へ）という言葉が示す通り、従来型開発とアジャイル開発では品質保証の進め方やマインド部分に大きな違いがあり、アジャイルQAの概念を理解して整理がつくまでは、従来型の考え方に引っ張られてしまい、戸惑うことも多かったです。
今回はその戸惑いの中で、特に印象的だった点をご紹介します。
この記事はエモーションテック Advent Calendar 2023 の15日目の記事となります。
◯ 「QAって何をするんですか？」
本題に入る前に、join後に各部署へ自己紹介をする中で、「QAって何をするんですか？」「テストエンジニアと何が違うのですか？」といったQA業務についての質問をもらうことが多かったので、まずは「QAエンジニア」という職種について自分なりに整理してご紹介しようと思います。
・そもそも「QA」とは、何でしょうか？
QAとは「Quality Assurance」の略で「品質保証」を意味します。 その名の通り、「品質を保証する」というミッションがQAエンジニアの活動の中心となります。
「品質を保証する」と言われて、多くの人が思い浮かべるのは「テスト業務」ではないでしょうか。 テスト業務は「対象製品が仕様通りに動くことを確認する」、つまり「機能要求を満たしていることを保証する」業務です。
「テストをする」というイメージが強いこともあって、「QAエンジニア」＝「テストエンジニア（テスター）」というイメージを持つ人も多いです。
しかし、実はQAエンジニアが保証する品質はそれだけではないのです。
・「QA」が保証する「品質」とは？
QAエンジニアを知ってもらう為、まずはQA活動の関係者について説明していきます。
ーーー
テスター（テストエンジニア）
「対象製品の機能としての品質」を「テストの実行結果」を通して「買い手（ユーザー）」に対して保証を行う
テストマネージャー
「対象製品の製造プロセスにおける品質」に関する定量化したデータを元に、品質管理（QC：Quality Control）等の「マネジメント」を通して、「作り手（会社・開発チーム）」に対して保証を行う
QAエンジニア
「対象製品に対して求められる”様々”な品質」を全工程の中で、定量化したデータを元に「客観的、且つ、優先的な判断」を通して、「買い手・作り手」に対して保証を行う
ーーーー
QAエンジニアの説明で「”様々な”品質」と書いたのは、「対象製品の機能としての品質」や「対象製品の製造プロセスにおける品質」以外にも、保証すべき「品質」があるからです。
例えば「買い手であるユーザー」にとっては「性能や安定性、価格、使い勝手やリリースの速さ」であり、広範囲に及びます。
また、「作り手である会社・開発チーム」に対しては、開発工数や設備投資などの「コスト」や売れる「機能」といったビジネス要求もQAが保証する対象になりえます。
上記のことから、QAエンジニアが保証すべき「品質」とは、テストに限定した品質を保証するだけではなく、ユーザー目線、開発目線、ビジネス目線といった様々な観点に対する「品質」となります。
◯アジャイル開発のQAエンジニアとして
少し前置きが長くなりましたが、ここからはアジャイル開発におけるQAについて触れていきます。 join前に書籍等でアジャイル開発のQA活動について学習し、従来型開発とアジャイル開発ではそのマインドや進め方に大きな差があることは理解していましたが、いざjoinして現場に入ったところ予想していた以上に自分が従来型開発の考え方に引きずられ、もどかしい思いをすることになりました。
特に、もどかしく感じたのがこの2点...
ドキュメントの在り方
スピード感の違い
・ドキュメントの存り方
アジャイルソフトウェア開発宣言で定義されている「包括的なドキュメントよりも動くソフトウェア」という思想の のもとで開発を進めている性質上、従来型開発の様に上流工程で準備された包括的なドキュメントを読んで理解して進めるということができず、慣れるのに時間がかかりました。
そのサービスの現状動作が本当の意味で品質保証できるかという観点については、実装資料や議事録を読み込み、実際に触り、様々な観点での動きを確認して、なぜこの仕様にしているのかをしっかりと開発者と確認していくことが大切だと、この2ヶ月で実感しました。
・スピード感
従来型開発では、要件定義から運用までの順に工程が進みますが、アジャイル開発では「設計」「開発」「テスト」「リリース」を小さな開発サイクルで何度も繰り返し、その中で品質の保証とスピード感も求められます。
アジャイル開発は、従来型開発の様に前工程で要件や仕様を詳細に決めて進むわけではないので、仕様変更にも柔軟に対応していくことが可能ですが、一方でテストを行う際はその柔軟性を全て押さえる必要がある為、最初はQAエンジニアとしてついていくのが大変でした。
また、アジャイル開発では速さと品質を両立させていく為、テスト方法も闇雲な全網羅ではなく、ユーザーストーリーを意識したマニュアルテストや自動テストや探索的テストなど、適切なテスト手法を見極めて進めるスキルが求められます。
従来型開発のQAに慣れていると、この違いは大きくもどかしい気分になる時もありますが、常に新しいことに挑戦して継続的な成長を目指す経験ができるのはアジャイル開発だからこそと思います。
◯ 最後に
従来型開発しかやってこなかったQAエンジニアが、アジャイル開発のQAを初めて経験した時に戸惑ったことを紹介させていただきました。 今後、初めてアジャイル開発にふれるQAエンジニアの方に向けて、私の話が参考になりましたら幸いです。
