毎週、Twitter SpacesとDiscordで交互にテスト自動化の話をしながらランチを食べる会というのをやってるんだけど、この中でプログラミング経験の無いテスターが自動テストを覚えるのはプログラミングの技術を学ぶ上で有効かという議題が盛り上がった。
その場で出た意見は次のようなもので、概ねハードルが高いという意見で共通していたと思う。
- 自動テストは開発技術を転用したものなので、普通に開発スキルが無いと厳しい
- 自動テストだけ覚えてもプロダクトの品質向上には寄与しないことが多い
- 自動テストライブラリのシンタックスを覚えただけでは足りず、一般的なプログラミングスキルは当然必要になる
- 初めてのプログラミングの対象がブラウザなのはつらそう
- 自動テストはマイクロサービスとして捉えたほうが良い
以下は自分の意見。
モチベーションの重要さ
プログラミング経験が全く無い人が、自動テストからプログラミングに入門するのは大変そうだな、というのはその通りだと思う。特にE2Eでは、操作対象がWebブラウザやモバイル実機ということもあり、それらに対する知識がどうしても必要になってくる。期待する結果を得るまでに会得しないといけない知識と労力が見合わないと感じることもあるかもしれない。
ただ、ハードルが高いということが、すなわち入門対象として不適切とは言えなさそうだな、とも思った。例えば、ゲーム作りはそこそこ難易度が高いプログラミングだと思うが、本当に作りたいと思うものがあったり、優れたゲームプログラマーになりたいのなら、頑張って覚えると思う。
新しいことに挑戦するときに、覚えることが多いのは当たり前だ。エンジニアなら、何かをしようとしたときに、予想の10倍ぐらい新しいことを覚えないといけないことが多いと思う。それでも、学ぶことを諦めず、常に挑戦することで、優れたエンジニアになれるのだと思う。
自分の例で言うと、社会人3年目のときにExcel VBAで業務を自動化したのがプログラマーとしての入り口だった。VBAもまた、初学者にとってあまり親切とは言えない言語だったし（Basic、てついてるのにね）、Excelもまた複雑怪奇なインターフェースを持っていた。覚えることが無数にあり、「変数」「配列」といった基本的な概念が理解できず、そこで何ヶ月も費やした。学び始めてしばらくは、覚えることの量に対して、達成できるものがあまりに少なく、非常に実入りの少ないものだった。それでも、目の前の仕事を効率よくしたいという強い情熱があったので、根気よく取り組むうちに出来るようになった。何より、Excelそのものは自動化が面倒な類のものではあったけど、自分自身は普段の業務でExcelに慣れ親しんでいたし、コマンドプロンプトに比べれば間違いなくとっつきやすかったはずなのだ。
プログラミングに限らず、何か新しいものを学ぶときは、今の課題感や解決したい問題に対する直接的なアプローチになるようなものを選んだほうがいい。そのほうが今持っている業務知識をフルに活かせるし、モチベーションが高いから継続して取り組める。
モチベーションが薄いと、どうしても効率を意識してしまう。例えば、できるだけ新しいことを学ばず、難しい部分を回避しながら進めようとしてしまう。これは、何かを実現することが目標なのであれば良い姿勢なのかもしれないけど、当然知識として身につくものは少なくなってしまう。
なので、ハードルが高かろうがなんだろうが、学びたいと思ったものを学ぶのが結局一番効率が良いのだろうなと思う。好きこそ物の上手なれっていうしね。
自動化を覚えた先
それはそれとして、自動化を入り口にしたとして、その先に何が待ち受けているのかは整理しておいてもいいだろう。
例えば、ここに一人のテスターがいるとする。彼は自分の普段やっているテストを自動化するためにSeleniumのシンタックスを覚え、見事にその業務を自動化した。おめでとう！
これが品質に寄与するかというと、自分はほとんど寄与しないと思っている。彼はあくまで彼の仕事を自動化しただけである。よく言われるテストだけでは品質は上がらない法則の自動化バージョンだ。実際に品質を高めていくには、その先に進む必要がある。先に進むために必要な技術がある。アプリケーション開発の技術だ。
例えばテスタビリティ。自動テストは、ある程度書き進めていくと、非常に自動化が困難な箇所に出会うことがある。このような箇所は、自動テスト側だけを工夫してもどうしようもない。アプリケーションに新しいインターフェースを追加したり、適切な抽象化を行うなどして、よりテストしやすくする必要がある。
インターフェースという言葉が出てきたが、自動テストとは特定のインターフェースに対して行うものなので（実際は自動か手動かに関わらないけれど）、そのインターフェースに関する知識や、良い設計についての知識、経験がどうしても必要になる。もちろん、単にテストしやすいだけが良いインターフェース設計ではない。
つまり、冒頭のテスターが自動テストを覚え、それによって品質を向上させようとするならば、必然的にテスト以外の開発技術が必要になるのだ。テストの技術を学び、自動テストの技術を学べばそれでテストエンジニアとして完成ということはない。むしろ、テストに詳しい開発者になるぐらいの気概を持って望んだほうが良いと思う。
別の視点として開発者から見た自動テストについてはテスターもよく理解しておいたほうが良い。テスターは「完成品をテストする」という流れに慣れてしまっている。これはつまり「自動テストが無い状態での開発は安全ではない」という肌感を持たずに自動テストを書いているということだ。TDDのような「作りながらテストする（テストしながら作る）」流れを経験したり、あるいは自動テストが無い状態で複雑なものを変更する経験をすれば、異なる視座で物事を見られるはずだ。
品質を上げる手段はテストだけじゃない
いま、QA・テスターというロールはすごく注目されていて、いろんな会社で一人目のQAを募集していたり、テストを専門にする会社が並の開発会社よりも良い条件でテストエンジニアを採用していたりする。
一方で、これもよく言われることだけど、品質やテストという言葉で表されるものが幅広すぎて、採用する側・される側でミスマッチが起きがち、という話も耳にする。QAを必要としている会社は、間違いなく品質に課題感を持っていて、それを解決するためにQAを募集している。たいていはQAが入ることでテストの網羅性を上げたり、品質文化の醸成なんかを期待している。でも、実際に必要なのはそうではない可能性がある。
場合によっては、品質を上げたり、安心して開発できるようにするために必要なのはテストですらないこともある。普通に既存のバグを潰していったり、その過程でユニットテストを拡充させたほうが良いこともある。仕様を整理することからスタートしたほうが良いこともある。監視やアラートを入れる必要もあるかもしれない。開発者が品質にコミットできないようなプロジェクトマネジメントになってるのかもしれない。
「開発者がユニットテストを書いてくれない」というのはQAエンジニアから良く聞く悩みでもある。書いてくれない、という言葉が出るということは、QAがユニットテストやそのテスト対象について良く知らず、それゆえに書くように説得することも出来ない、ということだ。逆に、自分としてはそういう提案や説得もQAがどんどんやっていくべきだと思っている。品質を上げる手段はテストだけではないので、品質のプロたるQAはそうしたテスト以外の武器も持っておくべきだ。
おわりに
テストは、学習や理解のためのアプローチだと言われることがある。テスターは日々の業務でテスト対象のプロダクトとしての仕様や振る舞いについては良く理解しているはずだ。その知識をテコにして、プログラミングを覚え、自動テストを覚えるのは効果的だと思う。
一方で、プログラミングの文法を覚えただけでは良いコードが書けないのと同様、自動テストの書き方を覚えただけで良い自動テストは書けないし、効果も上がらない。
世の開発者たちは、コードが複雑になりすぎないよう、ドメインの複雑さを紐解いてシンプルにコードで表現することに日々全力を注いでいる。テスターもまた、同じことをテストというフィールドでやっているはずだ。開発者とテスターのそれぞれが複雑さに立ち向かわないと、ソフトウェアは堅牢にならない。堅牢にならないということは、つまり求めている品質を満たせないということだ。
開発とテストは表裏一体、分けようと思っても分けられないものなのだけど、なぜか分かれてしまっていることが多い。分かれている状態を正しいものと思わず、きちんとあるべき姿に戻さないと高い品質のものは作れないことが多い。自動テストを覚えたい、プログラミングを覚えたいと思うテスターは、そのあたりを意識しておくと良いのではないかと思う。
