QAはどこまでテストをしたらよいのか?
ゆこゆこQA担当のmaikoです。
ゆこゆこのQAとなってから約2年が経過したので、今日は私なりに捉えた「テスト設計」についてまとめてみます。
ゆこゆこQAチームの紹介
まずはゆこゆこのQAチームを紹介します。
現在5名体制(24/7/1時点)
プログラミングなどの専門的な勉強をしてきた人や業務経験がある人はいない。(過去にテスター経験がある人は1人。)
特に私はサーバーの意味も知らないシステム初心者
システム初心者が集まったチームですが、システムのユーザー側だった経験や持ち前のコミュニケーション能力を生かし、助け合いながら業務にあたっている素敵なチームだと自負しています(* > <)⁾⁾
私の担当業務
異動した当初から社内向けシステムのQA担当をしていて、半年前から弊社予約サイトの担当もしています。
社内向けシステムは、前部署でシステムを使っていた経験や運用方法を知っていることを生かし、ユーザー視点のテスト作成・テスト実施をしています。
一方予約サイトの開発はスピードが求められ、知らない用語も多く、苦労しながら日々QA業務にあたっています。
直面した問題…どこまでテストをしたらいいのか
異動してきた当初は比較的簡単な案件のテスト設計をしていたので、QAとして順調な滑り出しだったと思います。
リグレッションテストもしっかりと行っていましたが、
と、心配性丸出しでリグレッションテストに命と工数を懸けていました。
そのため、順調だった私も壁にぶつかります。
QA業務に慣れてきたころ、経理関連システムの担当になりました。
経理経験はないですし、リリース日も決められているのでのんびりとテストをすることはできません。
開発担当者のおかげで改修内容は理解できたものの、
と途方に暮れました。
そこにいつもスマートに仕事をこなす開発者Aさんがアドバイスをくれました。
いつものコロッケに千切りキャベツが添えられていればいい
テストを作るとき、下記2軸で作成しています。
1. 今回の改修点が要件に沿っているか
2. 今回の改修点以外に不具合が起こっていないか ←ここが悩ましい!
「思わぬ不具合」という不安を払拭するため、テスト数をこなして安心材料を揃えていました。しかし、前出の彼女のアドバイスを受けて以降、やみくもにテスト項目を増やすことはなくなりました。
私が得とくしたテスト設計の考え方を「コロッケを作る過程」に置き換えてまとめました。
※注意:色々な作り方がありますが、私の作り方に沿って説明します。
【コロッケ調理手順】
1. 材料を調理台に集める。
2. じゃが芋を茹でる。
3. 玉ねぎをみじん切りにし、ひき肉と炒める。
4. ゆであがったジャガイモの皮をむき、つぶす。
5. 4.のジャガイモに、3.で炒めた玉ねぎとひき肉を加えてまぜる。
6. 成型し、小麦粉→卵→パン粉をまぶす。
7. 揚げる。
8. 皿に盛り付ける。
【開発の要件】
【テスト内容】
まずは今回の改修点が要件に沿っているかテストします。
続いて今回の改修点以外に不具合が起こっていないかテストします。
従来の私は「キャベツを扱うことで他の工程に影響を及ぼしていないか」と心配するあまり、全ての手順を一つ一つテストしているでしょう。
しかしそんなことしていたら夕飯の時間を過ぎてしまいます…。
アドバイスを受けてからの私は、この場合下記3点に絞ってリグレッションテストを行います。
キャベツを扱う工程が加わっている手順1・3・8の中でも一部に絞ってリグレッションテストを実施します。
あとは開発前のコロッケが完璧なコロッケであれば、開発前後のコロッケを比較し、相違ないことが確認できればコロッケ調理手順に「思わぬ不具合」は起こっていないといえるでしょう。
項目を絞ったテストでも、「コロッケwith千切りキャベツ」の品質は担保されます。
開発が加わった部分を確実にテストすることの重要性
前出の「開発前のコロッケが完璧なコロッケであれば」という言葉にも表されていますが、QAが不具合を見落とすことなく確実にリリースできれば、次の開発時にはリグレッションテストの範囲を絞ることができ、注力すべきテストに集中できます。
開発に好循環を生み出すためにも、リリース前に不具合をブロックすることの重要性を実感しています。
最後に
QAは社内では知名度は高くない組織ですが、組織が存在する重要性を数字で示していけたらいいなと考えています。
そのためには目の前のテストを確実に行うことだけでなく、テストケースの資産化を進めてナレッジを共有し、開発生産性を意識した組織にしていきたいと思います。