この記事はポエムです
当記事はAdvent Calendar 2023で「自動化できたらうれしいテスト、してみたいテスト」というお題があり、今日この頃テスト自動化したいと思っている思いを記しておこうかなという軽い”ノリ”の記事です。
現状自動テストに取り組めていないチームに所属している中で、なぜ取り組めていないのかとどうすれば取り組めるのかを考えた内容にアドカレのお題を混ぜる形で書いています。
自動テストの経験値
プライベートでPython（Pytestを使用した）やJavaScriptで簡単なテストコードを書いて、GithubActionsで自動テストを行ったことがあるレベルです。
TDD（Test-Driven Development：テスト駆動開発）の研修を受講して、テストコードを書き日々テストを回すことでデグレを起こさないようになり品質が高まるかもと思い始めている今日この頃です。
現在（2023/12/08時点）所属している会社では、自動テストやテスト駆動開発といったワードがちょと話題に出るレベルで業務の中で開発プロスとして取り込まれていない。
自動テストのイメージ
自動テストというと、TDDが真先に思い浮かべるが、今までテストコードを書くことを開発プロスに取り入れてこなかったチームにはハードが高い。
前述しているが、自動テストはテストコード（テストケース）を積み重ねてデグレが発生していないかやフルパステストを行うことでプログラム単体の品質は間違いなく向上するというイメージがある。
コミットごと、毎日自動でテストサイクルを回すところまで持っていければ、着実に品質アップに繋がるし今まで手作業、目検で確認していたテスト負荷が着実に下がると思う。
自動テストを阻む壁
日々見聞きして感じる阻害要因の代表的なものを書き出してみる。
テストコードを書くのが大変という偏見
今までテストコードを書いてこなかった開発者からすると、実装すべきコードに加えてそのコードをテストするコード書く必要があり倍のコーディング量がいると思いがちである。
業務ロジック等が変更になりコード修正の度にテストコードも直す必要があり、テストコードを直し忘れてテストが回らなくなるのではと心配の声もある。
テストコードは書かないが、毎回手作業で画面から入力したり、INPUTデータを手作業で作成して手動でテスト実行している
チーム全体の自動テストに対する意識の差
自動テストのスコープを考えたときに、色々な考え方があると思う。
- プログラム単体でのテスト
- 自動入力による画面遷移を伴ったテスト
- シナリオ（ストーリー）を設定して実行するテスト
・・・・
自動テストに取り組みたい私のような
は、まずはプログラム単体でテストコードを書くことろが始めて仕様変更による構築工程戻りが発生してもデグレ発生していないテストは自動でやって負荷を下げたいと思う。
しかし、PM（プロジェクトマネージャー）、プロダクトオーナーが以下と思うと一気にプロジェクトでの自動テスト導入が進まなくなる。
- これらのテストを全部自動でやるのが自動テストをやっているという初期ハードルを高くする意識
- シナリオを設定しても、次のプロジェクトではシナリオが変わっていて作成したテストケースが使い物にならないのではという懐疑心
- 自動テストなんて信用できない。テストが通るようにテストコード書いているかもしれない。人の手で人の目でやるテスト以外は信用できない
自動テスト導入の最大の壁
下２つの意見が出るともう自動テストを導入できる雰囲気ではなくなる
自動テスト導入を進めるために
簡単なテストケースからテストコードを書いて自動テストするの成功体験を醸成する
端的に何もないところからは何も生まれないので、ごちゃごちゃ考える前にテストコードを書いて自動テストへの1歩を踏み出すことが大事だと思う。
関数の返却値やファイル出力結果の比較など、単純なケースでも良いので踏み出すことが大事！
1つ1つの成功体験を積み重ねることで、チーム内でテスト自動化の意識が変わるのではないでしょうか。
この小さい成功体験を広げていくことで、テスト自動化へハードルを徐々に越えていく。
個人で始めても社内の文化を変えるには長い時間を要するため、中々社内の開発プロセスに組み込むにはハードルが依然高い。
外部の力を借りて一気に変革する
文化を変えるには果てしないので、外部の力を借りるのも一つの手であると思う。
予算規模が大きいプロジェクトやシステム更改であれば、外部ベンダーとしてテスト専門会社やテスト自動化に知見のあるベンダーに参画してもらって一気に変革を起こす。
このアドカレの主催者であるバルテス社様に頼るのが近道かもしれません。
私はバルテス社様とは関わりはないことは、注意書きとして記載させていただきます。
やってみたい自動テストについて
結びになりますが、取り組んでみたいテストについて記載します。
これができたら生産性が上がると日頃から思っているテストパターンになります。
画面遷移の自動テスト
画面入力のパターンを定義して、そのパターンごとの画面遷移を自動でキャプチャーして期待遷移画面と突き合わせを行い正しくアプリケーションが起動しているか確認する。
SeleniumやCypressが使えるのではと密かに思っています。
バッチの処理結果比較
INPUTデータとそのINPUTから出力されるOUTPUTを定義して、自動でテスト実行し結果比較する。
手動で実行するは、手間がかかるが自動すれば毎度毎度のデグレ確認を効率化できるのではと思っている。