エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

テスト設計コンテスト2021 決勝に参加します

f:id:j-kubota:20210901114148j:plain

こんにちは。エムスリーエンジニアリング G QA チームの窪田(@kubota_junshi)です。来る9月18日(土)、テスト設計コンテスト'21 OPEN クラスの決勝戦が開催されます。エムスリーQAチームも予選を突破したので決勝戦に参加します。予選と決勝の準備で得た色々な経験と学びを共有したいと思います。

テスト設計コンテストとは

QA を生業にしている人でも、はじめて聞く方は結構いると思います。私も JaSST(ソフトウェアテストシンポジウム) 内で紹介されるまで知りませんでした。

テスト設計コンテストはざっくりいうと、お題として提示されるシステムに対して、テストを設計し、その設計の出来を競うコンテストです。2011年から実施されており、10年以上続いているコンテストになります。主催はソフトウェア品質界隈でおなじみ、NPO法人 ソフトウェアテスト技術振興協会(ASTER:Association of Software Test EngineeRing)となります。

コンテストの目的は公式サイト の説明によると以下の通りとなります。

  • ソフトウェアテストを分析設計から行うことを周知し、ソフトウェアテストエンジニアに対する教育の機会を提供する
  • コンテストという形式をとることにより、ソフトウェアテストが創造的な作業であり、楽しいということを経験してもらい、若年層及び初級テストエンジニアからベテランテストエンジニアまでテストへの興味を高める
  • ソフトウェアテスト業界における技術開発を競技を通じ、促進する

個人的には一番上の、「ソフトウェアテストを分析設計から行うことを周知し」が今回コンテストを通じて一番身に沁みてわかったと感じました。非常に重要です。詳しくは後述します。

また、テスト設計コンテストは年齢制限無しの OPEN クラスと30歳以下の年齢制限がある U-30 クラスに分かれています。今回エムスリー QA チームでは OPEN クラスに参加しました。

テスト設計コンテストの流れ

公式ページ にテストベース(テスト設計のために必要な各種資料)が公開されています。今回はテスト管理システム(テストケースを登録して、テストの進捗などをトラッキングしたり、レポートを出力したりするもの)がテスト対象でした。これらのテスト対象を分析して、テスト設計を行い、以下の4つの成果物を作成します。

  • テスト設計書
  • テスト設計に関わる成果物一式(テスト設計書を作成するために作成した成果物。分析結果資料など)
  • アピールシート(今回のテスト設計の狙いや熱い思いをまとめたシート)
  • プレゼンテーション資料(予選で用いる)

予選では、プレゼンテーション資料を用いてテスト設計についての説明を行い、成果物と発表内容の出来栄えで採点されます。採点基準は公式サイトに詳しく書かれています。

無事予選を突破できたチームは追加課題を与えられ再設計をして、決勝戦に挑みます。

エムスリー QA チームでの取り組み

社内でチームメンバーを募集したところ、私を含めて4名集まり、4人(窪田、城本、須賀、中塚)で参加することとしました。

まず、何をやればよいのか? からわかりませんでした。こんな私達みたいな人たちのために、説明会 を用意してくれており、大会の大まかな流れを説明してくれています。 では次にテスト設計! と行きたいところですがそもそもコンテストとしてどんな成果物が求められているのか、がよくわかりませんでした。これについても チュートリアル を用意してくれており、テスト設計の手順を説明してくれています。 我々、エムスリー QA チームでは、説明会資料と、チュートリアルに目を通すということからはじめました。我々も普段の業務でテスト設計を実施していますが、コンテストではどこまでの記述が必要なのか、作業イメージを持ちたかったためです。

次に、大まかな作業イメージが付いたところで、過去参加チームの資料(提出したテスト設計、発表資料) に目を通して過去の参加メンバーがどのような分析を実施しているかを把握することにしました。エムスリーの QA はそれぞれテスト対象の分析をしており、例えば私の場合はプロダクトにどんなリスクがあるのかを考えてからテスト設計を始める場合が多いです。しかし、無意識のうちにプロダクトを様々な視点から確認し、その部分を言語化せずにテスト設計している場合も多々あります。過去の参加者がそれらの分析をどのように言語化、可視化しているかを確認し、言語化、可視化のヒントになるかと思い過去の設計資料に目を通しました。 結果、過去チームも我々が普段実施しているようなアプローチを取っていることがわかり、そして非常にうまい表現をしていることもわかりました。これらをもとに、テスト分析、設計と進めていくことにしました。

分析開始

テスト分析は自分たちがやっていることと、チャレンジしてみたいことを挙げていき、それらを組み合わせながら進めることとしました。

普段から取り組んでいることとしては以下が挙げられます。

  • ステークホルダー(利用者)のニーズを考える
  • リスクとして何があるかを列挙する
  • ユースケースを列挙する
  • ユーザビリティの確認

また、この機会にチャレンジしてみたいこととして以下が挙がりました。

  • リスク分析
  • ユーザビリティ分析
  • SWOT 分析

普段から取り組んでいることと重複はあるのは、普段実施していない人が取り組んでみたということと、いつもと違うアプローチで実施してみたからです。

これら方針が決まれば、後は作業をしていくのみ! 週に1回の進捗共有をしながら方向性を合わせつつ進めていきました。

紆余曲折

上記の通り、少しずつ進捗を進めていた我らですが、4月は業務と評価などがかちあい、非常に忙しい日々を過ごしていました。そしてある時(4月後半)このままでは提出できないといった事態になりそうであったため、とりあえず分析は今ある形で終わらせて、それら分析をどのように組み合わせるかを考え始めました。大まかな方針ができる頃にはゴールデンウィーク直前になっており、そこはメンバー全員が腹をくくり、作業量を増やして頑張ることに決め、以下の作業を実施しました。

  • 分析の総括を作る
  • 分析で得たアウトプットを用いて各自テストケースのサンプルを作る

テスト設計、ケース作成を全て実施する時間はすでになかったため、テストケースをサンプルで作成することとしました。 これは、コンテスト直前にてす豆さんと合同発表練習をしたときにいただいた、サンプルすらないとコンテストとして評価できないので、サンプルだけでも提出したほうが良いというアドバイスによるものでした。

その結果、なんとか提出できました。 発表資料 ご参考。

予選本番

予選は15分間の発表と5分の質疑応答で構成されています。そして、参加者はチームへの意見や感想を Jamboard に書いていくという仕組みでした。

予選では、発表中から発表後にかけて多くの人から様々な質問と感想 をいただくことができました。思いの外多くのご意見をいただけて非常にありがたかったです。これらの感想を実は来る決勝に向けて参考にさせていただきました。

また、審査員の皆様にも多くのご指摘をいただきました。

ご指摘としてはやはりテスト設計移行の手薄さに対するものが多かった印象です。分析も至らない部分が多くご指摘いただき非常に参考になりました。また、ポジティブなご意見も少ないながらもいただけており非常に嬉しかったです。

感想

大変だったこと

大変だった点は2点ありました。 1点目はテスト対象が比較的大きかったことです。テストベースとなる文書の合計ページ数が200ページも有り、4月の初めから着手した我々としては1ヶ月そこそこでその大きさの QA をするのはほぼ業務と遜色ないレベルであったため、非常に苦労しました。また、評価の時期やプロジェクトの佳境と被っているメンバーが多く進みが遅かったということも挙げられます。

2点目は普段作っていない資料を明示的に作っていったことです。普段からテストケースの分類なども意識しながら整理をし、それを再利用、改定しながらテスト実施をしているため改めて整理のためにテストアーキテクチャをし直すことも多くはないです。また、小規模の案件を大量にさばいているメンバーが多いため、ここまでの大物を体系的に分析し、分析資料を作り、トレースを意識しながら設計を……。というのは個人的には久しぶりの作業でした。これにはメンバー全員でこまめにコミュニケーションをとる必要がありましたが、週一のペースでのコミュニケーションだったため、明らかに足りなかったかもと思っています。

学び

学びとしては以下のものが挙げられます。

  • 他チームのテスト設計資料をたくさん見ることができ、どのように資料に落としていくかは非常に参考になりました。
  • 各資料を作っていく際にチュートリアルを始め、様々な資料を参考にしたため、テスト設計の知識、実力が向上したと感じています。
  • テスト対象が大きいと大変ですね。当たり前ですが。改めてそう思いました。
  • チームで活動しているのでこまめなコミュニケーションと積極的な意見交換が大事であることを改めて認識しました。

決勝に向けて

決勝戦は追加のお題が出されます。今回は自動テストについての追加課題でした。この部分は弊社の須賀が非常に力を入れてくれたため、充実した内容になっていると思います。 また、皆様からご指摘への対応も一部実施しました。余談ですが、やはり時間的な余裕はなく最後もバタバタしてしまいました。反省ポイントです。

9/18 改善したテスト設計をお見せできると思いますので、よければ決勝戦見ていただけるとありがたいです。 

We're hiring!

今回の記事の通り、各メンバーがアイデア出し合い、議論を交わしながらテスト設計コンテストの準備をしましたが、実業務でも熱い議論を交わしながら QA しています。興味のある QA エンジニアは社員とカジュアルなお話ができますので、興味を持たれた方は下記よりお問い合わせください。

jobs.m3.com