1.はじめに
こんにちは、品質管理部の藤田です。 品質管理部では製品の品質を担保するために様々なツールや手法を用いてテストを行い、お客様に安心して製品・サービスをご利用いただけることをミッションとしている部署になります。
私は2021年にMOTEXに入社して約1年強テスト設計業務を行ってきました。
<経験した内容>
・テスト観点の作成
・テストケースの作成
・テスト実施管理
・課題の対応
一通りの業務を学び、成長を加速させるべく外部のワークショップに参加してきました。
この記事はテスト設計の業務経験が浅い方や、品質管理に興味のある方、ぶっちゃけテスト設計ってなに？という方向けになります。
テストについて少しでも興味や関心を持っていただけたら嬉しいです。
2.WACATEとは
今回参加したのは「WACATE」というワークショップです。
「Workshop for Accelerating CApable Testing Engineers：内に秘めた可能性を持つテストエンジニアたちを加速させるためのワークショップ」 https://wacate.jp/ （公式サイトより)
このワークショップの魅力は、主役が若手というところです！
実際に参加されている方の大半が、20〜30代、かつ、テスト設計歴が3~5年未満の方が多かったです。
また、Web系や、アプリ開発会社のテスト設計者・QAエンジニアの方が参加されており、違う業界の方と交流することもできました。
3.参加動機
WACATEに参加するにあたって、私は「具体的にどうなりたいのか」、「何ができるようになりたいのか」を考えました。
< 1 > テストの粒度を自分で根拠付けて考えられるようになりたい！
製品・サービスのテストは、スケジュール／人員／検証環境など限られたリソースの中で、効果を最大限にするよう実施しなければなりません。 改修範囲を正確に捉えることで、
「危なそうなので、ここは細かくパターンを分けてテストしよう。」
「逆にここは特に改修に関係ないので軽めのデグレ確認にして、こっちの機能の方に力を入れよう。」
という考え方ができるようになると有効なテスト設計ができると感じたからです。
< 2 > ユーザーのニーズも考えて仕様書を作成できるようにしたい！
お客様に気持ちよくご使用していただくためには、機能のテストだけでなく、お客様の運用に沿ったテストが必要だと思いその考え方を身に付けたいと感じたからです。
< 3 > 他社のテスト設計者の考え方の考えや業務について聞きたい！
他社のテスト設計方法や取り組みから学びを得たいと思ったからです。
4.ワークショップで経験したこと
私は「WACATE2022夏〜テストできないと言う勿れ〜」に参加しました。
6月18日(土)と25日(土)の2日間、1グループ5～6人のチームとなってオンラインでワークを行いました。
詳細スケジュールについては、WACATEの公式サイトに掲載されている活動を確認ください。
ここでは、一番学びが多かった要件定義からテストを考えるワークから学んだことをご紹介します。
ワークテーマ：「テストの基本であるV字モデルの最上位部分に当たる要件定義から受け入れ条件をつくってみよう」
（資料引用元：https://wacate.jp/assets/ ）
まず要件定義とは、基本設計の元となるもので「お客様が求めていることをシステム設計の要件へ落とし込む」ことです。
詳細設計と基本設計からのテスト観点とテストケースの作成経験はありますが、その前段部分に当たる要件の段階の設計は初めてでした。
最初は何をインプットに観点作成したらいいのかイメージが湧かなかったです。。。
まず、指定された製品に関して、下記の観点で受け入れ条件を考えました。
・ユーザーはどんなことを実現したいと思っているのか？
・ユーザーはどんな結果を望んでいるのか？
・ユーザーの悩みは何なのか？
・どんなものを提供したら喜ばれるのか？
・ユーザーの悩みを取り外すためになにをしたらいいのか？
要件定義の段階では製品の仕様やどんな製品にするか具体的なことも決まっていないので、受け入れ条件の書き方の粒度が掴めず、苦戦しました。 また、文章に書き出して見ると、当たり前の品質に気付かされたり（当たり前すぎて頭の中で完結しがちでした）逆にこういう機能欲しい、など品質について考えさせられることが多かったです。
要件を書き出したあと、では次にどうやってテストしていくのか。
テストケースを考え出したとき、細かい仕様が気になりましたので、大枠だけ定義することにしました。
・例）決まったメモリ容量通りまで写真をインポートできること
・ ギモン！？→メモリの容量は最大何MB?もしくはGB?
・ギモン！？→対応する写真のファイル形式は？
定義方法としては、多くのお客様が使用されるファイル形式、実際に写真立てとしてどのくらいのメモリで満足いただけるのかを調べて、受け入れ条件を作成しました。
・メモリの容量は最大何MB?もしくはGB? →写真1000枚なら約3GBあれば十分
・対応する写真のファイル形式は？ →JPEG、PNG、GIF、TIFF（有名どころ）
以上、要件から仕様定義、テストケースの作成とテスト設計の上流工程のワークを体験しました。 多くのお客様が望む仕様にするためには、ユーザーストーリーやペルソナなども考慮し、インプット情報から必要な要件だけを取り出して、受け入れ条件へ落とし込むことが重要だと感じました。
多くのお客様が使用している形式だから、メモリはこれくらいあればいいからという考え方ももちろん大切ではありますが、ターゲットユーザー情報を軸に受け入れ条件を考える方が使用されるお客様の要望だけでなく運用面から見ても近い考え方だと感じ学びを得られました。
5.これからのテスト設計者
（資料引用元：https://wacate.jp/assets/ ）
IT業界ではよく聞く「I型→T型の人材へ」この考え方は、テスト設計者にとっても重要だと実感します。
テストエンジニアの部分だけ一貫してスキルアップを測る（左側）のではなく、基本的なデザインやプログラム、システムやサーバーなどのインフラ系の知識（右側）がないとテストの観点作成やケースを十分に作成できないです。
現に、今のプロジェクトでもその空気は感じられますし、毎日が仕様や機能の勉強です。 テスト仕様書作成だけをメインにせず、浅くてもいいので幅広く知識を身に付けることが今後重要視されてくると思います。
また、知識を増やすということにも繋がりますが、開発メンバーや企画者、デザインチームの方々にもどんどん自分から関わっていき、「ここの観点大丈夫？」、「〇〇ということも考えられるよね？どうやってテストしますか？」と会話を重ねることもテスト設計者にとって必要なスキルだと思いました。
6.まとめ
ワークショップに参加したことで、下記のようなたくさんの悩みを聞けました。
・アジャイル開発で仕様が明確ではない場合、正しいテストの設計方法は何か、他の方のやり方を知りたい
・どこまでテストをするのかの取捨選択が難しい。どう乗り越えてきたのか？
・仕様が不明確で漏れが多い現状をなんとかしたい
共感できた悩みもあり、改めて悩みを共有し合える場は貴重だと思いました。
今回このワークショップに参加して、改めてお客様のニーズに応えた仕様やテスト設計について理解することができました。 この気づきからお客様に喜んでいただける製品・サービスをお届けいたします。
最後まで読んでただき、ありがとうございました。
