SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

【デブサミ2021】セッションレポート(AD)

品質保証をアジャイルに組み込むQEエンジニアの役割を徹底解説【デブサミ2021】

【19-D-8】QAをやっていた人のNew normal 自動化など品質への戦略をアジャイルに組み込む役割とは

  • このエントリーをはてなブックマークに追加

 アプリケーション開発で品質保証は地味ではあるものの大切な役割を担っている。テスターから品質管理へとキャリアを積んだ、伊藤忠テクノソリューションズ Buildサービス推進チーム 日野杉賢祥氏が「品質に関わるエンジニアの魅力を伝えたい」と、QAおよびQEについて解説する。テスト戦略や自動化などをアジャイルに組み込むことで、品質保証はニューノーマルへと進んでいく。

  • このエントリーをはてなブックマークに追加
伊藤忠テクノソリューションズ株式会社 Buildサービス推進チーム 日野杉賢祥氏
伊藤忠テクノソリューションズ株式会社 Buildサービス推進チーム 日野杉賢祥氏

品質保証に関わる職種や役割はこんなにもある

 QA(Quality Assurance:品質保証)とは、仕様に沿った動作の確認や製品の品質管理を行うこと。QAエンジニアはブラックボックスで動作確認するなどして、不具合で生じるシステム障害を回避し、ソフトウェアが一定の品質を提供できるように責任を持つ。中には第三者目線でテストやレビューをすることもある。エンジニアと呼ばれつつもプログラムを書かない人もいれば、がっつりとソースコードと向き合う人もいる。

 「ぶっちゃけ、なんでも屋さんだったりします」と日野杉氏は言う。なぜなら会社やチームより求められることが異なるからだ。QAエンジニアをテスターとみなす場合もあれば、成果ログや計測システムを確認する役割と見たり、品質管理担当やテスト自動化担当と見たりすることもある。

 テスト範囲も異なる。テストには単体テスト、結合テスト、システムテスト、受け入れテストなどがあり、基本的に単体テストは開発者が行い、結合テスト以降をQAエンジニアが行う。単体テストは個々の機能を検証するためにJUnitなどのテスティングフレームワークを用いるが、QAエンジニアが担当することもある。バグ修正コストを下げるために、早い段階からスモークテストを実施することもある。

QAのテスト範囲
QAのテスト範囲

 一概にQAと言っても、実は関連する職種は多数ある。簡単に紹介しよう。

QAコンサルタント

 自社のQAコンサルタントなら、関係者からヒアリングして品質リスクをとりまとめ、品質戦略を打ち出す。テストプロジェクトの立案、報告、予算管理などをまとめる。社外のQAコンサルタントなら、顧客からヒアリングして品質戦略やテスト計画を提案する。

QAディレクター

 品質について指揮・監督する。仕様の改善要望、作業品質、仕様バグをQAの視点でまとめる。QAコンサルタントやPMが提案したテスト戦略や計画を実際に推進していく。

QAマネージャ

 品質保証やテスト戦略の立案、業務フローの立案や改善、チームスケジュール管理、外部テストベンダーとの折衝、テスト自動化の計画策定、メンバーの評価や採用などQA実務を幅広く担う。

QAエンジニア

 第三者視点で品質測定、テスト設計、テストケース策定のほか、仕様の把握や仕様に関する改善要望や指摘も行う。

テストマネージャ(検証会社)

 検証会社のテストやテスターの管理業務が中心となり、エンジニアやテスターとの情報共有、教育、稼働調整などを行う。会社によってはテストケース作成も行うとか、QAエンジニアが兼務することもある。

テスター

 テストケース、スモークテスト、アドホックテストなどを実行する。日本ではウォーターフォールモデルの下流工程要員としてみなされがちで、クリエイティブなイメージではない。しかし海外では高額報酬をもらう優秀なテスターも存在する。

テスト自動化エンジニア

 Selenium、Appiumなどを駆使してJenkinsでテスト自動化の仕組みを作る。Detox、Cypress、TestCafeが使われることもある。求人ではSET(Software Engineer in Test)とも呼ばれていることもある。

 会社やチームにより定義が異なるだけではなく、こうした職種の違いにより品質についての価値観や姿勢が分かれることもある。時には衝突も起きる。それで日野杉氏は「自分が本当にやりたいことはどれなのか、分からなくなった」。そんな時にQE(Quality Engineer)に出会ったという。

QAではなくQEの役割とは何か 微妙に異なるSETとの違い

 ではQEとは何か。QEとはテスト戦略や自動化などの品質への焦点をアジャイルに組み込む役割となる。ステークホルダーや開発チームに品質戦略について教えて導いていく。具体的にはテスト計画の立案、プラットフォームごとのテストケース設計、テスト実行など、プロジェクトチームが適切な品質目標と合格基準を決定するのを支援する。もともとはSlalom社における役割が由来となる。

 とはいえ「既存のQAとほぼ同じで、名前を変えただけでは?」と思う読者もいるだろう。日野杉氏は「正直、そうなのかなと思います」と苦笑いするものの、「従来のQAと比べると、各要素を含めたテスト自動化エンジニアと呼ぶと分かりやすいかもしれません」と説明する。加えて、QAでは「第三者視点」などエンジニアと別チームという扱いになりがちだが、QEはエンジニアチームの一員として品質向上を進めていく傾向がある。さらに大きな違いとして、日野杉氏は「一番の違いは、実装完了後にテストするのではなく、実装開始と同時に品質に責任を持って行動する」点だと強調する。

QEを既存QA職種と比べると
QEを既存QA職種と比べると

 プロダクト開発の最終段階では、バックログチケットが「QA完了待ち」となりがちだ。作業順から考えると致し方ないものの、「QAが完了していないからリリースできない」事態になることが日野杉氏にとって気がかりだった。不本意でもあっただろう。

 しかし今、プロダクト開発はリリース速度が重視される傾向にある。全体の進行をスピードアップするためには実装と同時にQAもスタートできるほうが有利だ。それゆえに「QEはこれから必要になる」と日野杉氏は確信している。

 ここでテスト自動化エンジニア(SET)との違いも確認しておこう。SETとQEはほぼ同じであるものの、立ち位置や視点が少し違う。大きな違いとして日野杉氏は「SETは仕様や機能にアプローチし、QEはプロダクト開発にアプローチする」ところを挙げる。SETはテスト自動化に特化し、自社プロダクトの品質を維持し向上させていくのに対して、QEは品質向上に必要ならテスト自動化を手段として用いる。どちらもリグレッションテストのE2E自動化は行うものの、SETはCIのビルド自動化やその先のCDも進めていく一方、QEはAPI/UIテスト実装、自動化レビュー、自動化のみならず手動のテストも担当することがある。

奥が深いQEの世界 どのように品質をアジャイルに組み込むか

 実際のQEの詳細について踏み込んでいこう。QEは次のような基本原則を持つ。「チーム全体が品質に対しオーナーシップを持っていることを信じています」、「クオリティエンジニアは品質に重点を置くことでチームに良い影響を与えます」、「我々は開発とテスト活動が密接に関わりあうと考えています」、「自動化は高品質で、迅速な納品を実現するために必要不可欠と考えます」。

 QEの品質活動は実装準備段階からテスト容易性についてレビューし、開発中には各種レビューやテスト実装を行い、テストを準備しテストを進めていく。重要なのは完了の定義となるのが全ての自動化完了となり、それぞれの機能開発や実装ごとに機能検証が完了していることになる。

 アジャイルの各セレモニー(イベントや会議)におけるQEの役割も定義されている。例えばスプリントプランニングでは最終見積もり、テストアプローチと複雑さのガイダンス提供、スタンドアップでは品質に関する問題や質問がないかの監視、テスト中のストーリー(機能)更新提供などだ。

 テスト自動化の実行可能性を確保するためのベストプラクティスもある。テスト自動化は開発そのものであり、テスト自動化は完了の定義の一部なので、コードの自動化に最も効果的な時期はコードを書いている時と同時と考える。また自動化には投資とコストのバランスが重要になる。そこで自動テストピラミッドに基づいてテストを自動化するのがよいとされる。

 自動テストピラミッドとは、テストを速くて低コストでできるものと、時間がかかり高コストがかかるものをピラミッドとして見る。底辺には膨大なユニットテストがあり、頂点にはE2E UIがある。自動化への投資はこのピラミッドをイメージしながら、決定していく。QEが重視するのは中央のコンポーネント/API(統合)テストとなる。

自動テストピラミッドのセオリー
自動テストピラミッドのセオリー

 QEの自動化戦略においては、QEはプロダクトやストーリーの内容次第ではE2Eテスト自動化をしない選択をすることもある。それは自動化を推進するのではなく、品質の測定、向上、維持を目的としているためだ。

 まだ自動化環境がない現場では、まずは啓発活動が重要になる。日野杉氏は「プロジェクトやプロダクトに関わる全てのメンバーがテストファーストの考えを持つ必要があります」と理解を深める重要性について語る。加えて同氏は「バグを見つけてありがとうと言える関係性が大事」と話す。

 「やってみたいけど無理そうなら、環境を変えてみては」と日野杉氏は言う。最新のアジャイル開発の専門家たちに指導してもらうのもいい。伊藤忠テクノソリューションズでは2020年4月からBuildサービス推進チームを結成し、DXに踏み出す企業に最新技術や手法を用いて一緒にプロダクトを開発し、顧客企業が自らの手で内製やDX推進できるように技術移転するサービスを提供している。ポイントは共創であり、請負ではないところだ。日野杉氏は「お客さまと伴走するチームを提供してDXを支援していきます」と話す。顧客チームと伊藤忠テクノソリューションズチームがひとつのチームとなり、ビジネスやプロダクトの実現にコミットし、新たなスキルやマインドセットを獲得できるようにする。DX実現の頼もしい仲間となってくれそうだ。

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/13718 2021/04/01 19:27

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング