テストに対するエンジニアと QA のジレンマ
こんにちは、けんにぃです。
2022年12月3日（土）に開催された『ソフトウェアテスト自動化カンファレンス2022』という勉強会に参加してきましたので、テストについて色々と思ったことをまとめようと思います。
テストの進め方
テストの進め方にはエンジニアと QA の間でいろいろと考え方のギャップがあるなと前々から思っていました。
テスト仕様書について
テストをするためのドキュメントは何をどこまで記述すべきか、というのは悩ましい問題で、次の 2 つの考えがジレンマとして生じます。
仕様についてまとめられたドキュメントが欲しい
ソースコードは仕様書も兼ねているのでドキュメントは書きたくない
テストの自動化について
すべてのテストを手動で行うのは困難なため、自動化をしたいというのは自然な発想ですが、実現方法には次の 2 通りがあります。
ノーコード・ローコードツールを使う
テストフレームワークを使う
いずれのケースもコードの読み書きができるか、という点でどちらに共感しやすいかが変わってきます。QA は前者、エンジニアは後者の心理になりやすいのではないかと思います。
もちろんドキュメントを書きたいと思うエンジニアもいれば、コードを書いて改善を図りたいと思う QA もいるでしょう。これはどちらが正しいかという話ではなくて両方のバランスを考慮して、いい落とし所を見つけていく必要があるものです。
ジレンマの間に立つ存在
つまるところ上記の課題は『ドキュメントっぽく見えるけどテストとして実行ができ、たまにプログラミング言語でもテストが書けるもの』があればいいのですが、そんなものはあるのでしょうか？
勉強会でその解決策となりそうなキーワードがいくつか見つかりました。
SET
勉強会に参加して SET (Software Engineer in Test) という職種を初めて知りました。調べてみたところ、いわゆる『テスト自動化エンジニア』と言われる人たちのようです。
SET はテストと自動化の両方の知見を持っているため、どこまでドキュメント化すべきか、何を自動化すべきかといったところでアイデアを出してくれそうです。
問題は優秀な SET を採用できるかどうかです。勉強会で出されていたアンケートを見る限り、どの企業もこの点は苦労をされているようでした。
Karate
API テストを実施する際に Postman を使っている方は多いと思いますが、勉強会では Karate というフレームワークが紹介されていました。
Postman で作成したテストは JSON でエクスポートできますが、この JSON をレビューで見せられても差分が分かりづらいという課題から Karate を導入したそうです。
Karate は下記のように Gherkin という記法を使ってテストを記述できます。
ビヘイビア駆動開発で見られる記法ですね。記述が宣言的なので、これがそのままテスト仕様書になりそうです。
UI テストも可能のようで Playwright と連携することもできるみたいです。Karate の存在は以前から知ってはいましたが、実際に使ったことはなかったので少し使ってみようと思います。
ちなみに Karate の公式サイトはだいぶ読みづらいので、時間があれば日本語ドキュメントサイトでも作ってみようかなと思います。
余談ですが Karate と似たようなアプローチをしているフレームワークに Gauge というものがあります。こちらは Markdown 上でテストが記述できるといったものです。
MagicPod
ノーコードテストツールの MagicPod も気になりました。ノーコードテストはそもそも使った経験がないので、とても興味があります。
MagicPod の新機能としてノーコードで作成したテストとソースコードで記述したテストの同期ができるようになるそうです。
ノーコード・ソースコードのテストが同期できるようになると、エンジニアと QA で作業分担ができそうでいいですね。
まとめ
私は普段エンジニアとして働いているのですが、QA の方がどんな工夫をしてテストしているのかが分かってとても面白い勉強会でした。
私も昔は QA をやっていてその苦労はよく分かるので、テストが楽になる環境を求めていろいろ試行錯誤をしてみようと思います。
この記事が気に入ったらサポートをしてみませんか？