テストツールとエンジニアと私

この記事は ソフトウェアテストの小ネタ Advent Calendar 2023 24日目 の記事です。前回はとうまさんの「マインドマップによるテスト設計と実施」！実用的な内容となっていますのでぜひご覧ください😘
https://note.com/chopiner/n/nc9f7a628c158

メリークリスマス！サンタさんはやってきましたか？
わたしのところには今年もサンタさんはやってこなかったので、せめてと思ってクリスマスソングをかけながらコーラを飲んでいます。マライアキャリー、最高です。

さて、この記事ではここ何ヶ月か取り組んできたテストツールを使ったテストについて書いてみたいと思います。

テストツールとは

JSTQBFLシラバスの第６章に「テスト支援ツール」の章があります。ここでいうテストツールとはそのテストツールのことを指しています。こちらの記事では詳細な説明はいたしませんので、気になる方はシラバスの該当章をご覧ください。

提案はエンジニアから

この何ヶ月間か、とあるHRプロダクトのテスト計画や設計に取り組んでいました。プロダクトとプロダクトの目的から、とある計算ロジックに関する大規模なテストをしなければならず、そのテストをどう設計するかはもちろん、どう実行するか、を悩んでいました。計算ロジックのテストなので、本来はコンポーネントテストで補完したいところではありますが、いかんせん大量なのが悩みどころです。そんな中、本件テスト用のツールを開発側で作るのはどうか、と提案してくれたエンジニアのKさん。そんなことができるのか！と目の前がひらけた気持ちでした。

テストツールは業界によってはメジャーなのかもしれませんが、私の中では「新しいツールをエンジニアの工数を使って作る」という考えがなかったので、なるほどそういうコラボもできるのね。と思いました。テスト工数がかかるなと思った時点でチームで相談することの大事さが身に沁みました。もちろんテスト自体を削減することもしましたが、それをやった上でも実行工数がかかる、といった類のお話です。

仕様作成と設計

どのようなツールにするかの仕様をQAEから提出する必要がありました。簡単ではありますが、ツールのPRDを用意し、そのあとは設計担当のエンジニアのNさんと二人三脚であーでもないこうでもない、こうしたらもっと良くなるかもなど言いつつ仕様と設計を固めていきました。

ツールの検証

テストツールを作ると言うことはそのツールの検証もしなければなりません。思うようにすっと動けばいいですが、なかなかそうはいかないのが道理です。ツールが使えるようになった後は最低限のテストデータを準備し、ツール自体の検証を進めました。

自動化といっても人の手はかかる

周知の事実かなと思いつつ、私自身、ツールさえできてしまえば実行はサクサク！だと思って見積もりを出したところこれが大誤算😅テスト実行2日でいける！と思っていたのに箱を開けたら1ヶ月以上かかってしまいました。要因は色々ありますが、主には以下の工数の影響が大きいかなと思います。

• 不正なテストデータの修正と再作成
• テスト実行周りのエンジニアとのやりとり
• テスト結果の判定（TrueかFalseか）
• テスト結果のまとめ

もっと効率的にできる部分もあったのかしらと思いますが、見込みから大きく外れてしまい、なるほどなと学びが多かったです。E2Eテストの自動化にも取り組んでおり、同じようなところでつまづいているのに、気が回らないものですね😇

まとめ

上手くいかなかったことは多かったものの、結果として、手動テストで実施した場合の工数よりはかなりの工数を削減することができました。今後もずっと使い続けられるようなテストツールを残せたのではないかと思います。

私自身「手動のテスト実行に時間がかかるようであれば自動化を考える」ということは頭にあったものの、「今はないツールをテストのために作ってもらう（しかもそれが将来なんども繰り返し使えるように）」という観点は今までなかったので、そういったこともエンジニアとコラボしてできるんだなぁととても学びになった取り組みでした。これからもツールが使われればいいなー

皆さんもテストに関する工数で困ったらまずは周りの人に相談してみてください。時間をかければいつかは終わる作業かもしれませんが、ひとつ工夫すれば30人日の作業が3人日で終わるかもしれません。方法は数あれど、テストに関する工数を抑える（ROIの観点で）のもQAエンジニアの大事なお仕事のひとつかなって思います。