最速で仕様理解！！「GX」QAチームが実践した仕様理解術の紹介
GO株式会社の堀と申します！
今回はQAチームで『GX』の最初の仕様理解を短時間で効率的に出来た事例を通じて気づいたことを紹介したいと思います。
仕様理解は、テストに関わらず、プロダクトに関わる人は常に行うことになると思います。この記事を読んだ方が、新たな気づきを得たり、ある種の納得感や共感を感じて頂けると嬉しいです。
『GX』のサービスについては以下をご覧頂けると幸いです。
仕様把握の事例紹介
さっそく、仕様把握の事例紹介から行っていきたいと思います。
QAチームが参加した時の状況
システム
複数存在している
仕様資料
PRDなどの概要が分かる資料あり
全体像を把握するためには基本設計書の理解が必須
スケジュール感
仕様把握から諸々の全てのテスト完了まで3カ月間ほど
機能が段階的にテスト可能になり、一番最初のテストは4週間目ごろから着手可能
テスト実施のスケジュールを逆算をすると、最初の仕様理解にかけられそうな時間は1週間ほどでした。
また、QAチーム参画のタイミングで、開発は実装ベースで細かい部分をつめている段階でした。そして、その内容の記載は基本設計書に行われていたので、PRDなどの概要が分かる資料はありましたが、テストをするには基本設計書を含めてトータルでの仕様理解が必須な状況でした。
最初、各種資料を見た時はそもそも関わった事のない領域で聞きなれない単語も多く、何となくのイメージを持つのも難しかったです。
テスト活動の初期導入時点でよくある状況なのではないかと思います。
実際に行った仕様理解の流れ
実際の仕様理解は下記の流れで行いました。
システムの大きな分けを考えた上で、担当を決める
各システムごとに「そのシステムで何が出来るのか」だけをまとめる
それぞれまとめた情報を持ち寄って教え合う
このように行った結果、3日間でテスト設計作業に移れるぐらいの仕様理解をチームで出来ました。
仕様理解度としては、システム全体のつなぎ込みを行った時の動きがある程度分かっており、自分の担当システムでどういうテストをするべきかイメージし始められるレベル感です。
これを見て「普通だな」と感じる方もいるかもしれません。
・・・はい、そこのあなた！私もそう思います。
ですが、案外こういったシンプルな解決方法の中に上手く行く要因が複数ある場合があります。無意識的に上手くいっている場合と、上手くいっている要因が分かっている場合ですと、後者の方が再現性が高くなったり、他の物事に応用できると思います。
私の場合は考えてみたところ、3つの要因がありそうだと気づいたので、それについてお話していきます。
3つの上手くいった要因
下記3つの要因があったと考えてます。
仕様資料はテストのために作られた資料ではない
段階的に仕様理解を進めた
人に教えるというゴールを設定した
1.仕様資料はテストのために作られた資料ではない
1つ目は、「仕様資料はテストのために作られた資料ではない」です。
テスト設計をする時に様々な資料を読むわけですが、基本的にどれもテストのために作られた資料ではないと思います。
当たり前ですが、開発するための資料な場合が多いです。
ここがポイントで、テスト設計者はこういった開発向けの資料を読み解いて、何をテストするか考える必要があります。そして、行うテストに関して根拠を持って他人に説明する必要があります。
これは言い換えると、元々テスト向けではない情報を読み解いて整理して、テスト向けの情報に加工しているとも言えます。
結論、このテスト向けの情報に加工して捉えるのに労力がかかるわけです。
今回のケースで言うと、基本設計書の読み解き作業が難しい状況でした。
それでも、担当システムを分けてテスト設計するにしても、それぞれが全体像を捉える必要があります。ただ、全部を知る必要があるかと言われるとそうではないです。
担当を分けてそれぞれで読み解き作業を行い、教え合うことで、少ない労力でチームとして仕様理解が出来ました。
2.段階的に仕様理解を進めた
2つ目は、「段階的に仕様理解を進めた」です。
難しいものを理解するためには簡単な部分から取り掛かる方が理解を進めやすいと思います。小学校の算数が解けないのに、中学校の数学の問題から解くことは出来ないですよね。
さて、開発されるシステムについて考えると、開発される実現方法は専門的な知識が必要で難しい場合もありますが、そもそも実現したいことはシンプルだったりすると思います。そして、テストは、そもそも実現したいことが出来ているかのチェックが重要になってくると思います。
そして、最初から特定機能を深く知るよりは、機能の横の繋がりを知り、全体像を捉えてから深堀していった方が、質が高く抜け漏れが少ないテストを考えられると思います。
結論、まず実現したいことをシンプルに把握する、その上で、段階的に全体像を捉え、詳細な実現方法を知る。これは、物事を理解するプロセスとしても効果的ですし、テストを考えるプロセスとしても重要だと言うことですね。
3.人に教えるというゴールを設定した
3つ目は、「人に教えるというゴールを設定した」です。
仕様把握は何かしらの目的があって行っているはずで、その目的に応じて必要な理解度は変わってくるはずです。今回は「テスト設計を始められる」が1つの目的です。
ここで難しいのが「何をもってテスト設計を始められるぐらい仕様理解が出来ているとするか」です。ふわふわしてますよね。そこで、「人に教えるというゴール」を設定することで「人に教えられるぐらい自分が理解できている」という達成基準を分かりやすくしたわけです。こうする事で、漠然とインプットするだけの仕様理解をするのではなく、「人に教える」というアウトプットの目的があるので時間の使い方や進め方が変わります。
そして、最終的に教え合います。これは、教える側は教えている間に頭の中が再整理されて気づく事もあると思いますし、教えられる側は理解しやすいと思います。
3つの気づきを通して
ここまで3つの気づきについては話をしてきましたが、応用が利くと思います。例えば、思いつくところでも下記のようなものがあると思います。
テスト設計で最初からテスト設計書の作り込みを行いすぎずに段階的に行う
テスト設計初期段階で、テスト設計者がレビュアーに詳しい仕様を教える形式でレビューを行う（レビュアーの仕様理解の時間が減る）
開発チームで資料の目的を整理して、複数のステークホルダー向けに適した内容にすると、全体として効率が良くなる
他にも応用の利かせ方はあると思うので、常に考えて仕事をする姿勢は忘れないようにしたいですね。
最後に
最初にお話しした通り、ここまで読んでくださった方にも何かしらの気づきや共感があったら嬉しいなと思います。
どうやったら仕事が上手く進められそうか？
これをいつもQAチームでも、開発チームでも話しながら仕事をしています。
意見に対して否定的ではなく、良さそうであれば、とりあえずやってみようの精神です。そして、上手くいかなくても、そこから学んだことを元に次のアクションに繋げてます。
今回記事を書いてみて、私自身にとっても良い振り返りになったので、また機会があれば発信していきたいと思います。
今回の紹介は以上になります。
GO株式会社では、私たちと一緒にチャレンジしてくれる仲間を募集中です。
私個人としても、課題に対して真摯に前向きに取り組める方と是非一緒に仕事をしたいと思っています。
興味のある方は採用ページからご連絡頂けると嬉しいです！
この記事が気に入ったらサポートをしてみませんか？