※ こちらはミツモアAdvent Calendar 2022の22日目の記事です。昨年の記事については ミツモアAdvent Calendar 2021 こちらを見てみてください。
こんにちは！ミツモア エンジニア の髙橋（@yumit414）です。
もうすぐクリスマスですね🎄☃️
突然ですが皆さん、手動テストはどのくらい行っていますか？ 新しく実装した部分だけ？実際にユーザーがしそうなアクションだけ？
ユニットテストである程度カバーできると言っても、手動テストも実装時に必ず行っていると思います。（ユニットテスト、書いてますよね？）
今回はそんな手動テストをする際、私が意識していることをいくつか紹介していきます。
入力と表示パターンを網羅せよ
例えば一番よく使うであろうTextInput。
仕様を含め、以下の項目をチェックします。
入力（form）
- 空のままsubmitできないようになっているか
- 空白文字（半角, 全角）のみの入力値を許すか
- 空白文字（半角, 全角）が前後にある場合は入力値をtrimするか
- textareaの場合、改行出来るか
- submitされた後のフォームの値はどうあるべきか
- ページのロード後、適した初期値が反映されているか
- ダイアログ内フォームの場合、ダイアログのopen/closeでdefault値がおかしくなっていないか
<script>alert(’xxx’)</script>等をsubmitしても文字列として扱われるか（XSS対策）
表示
- 長文をsubmitされたらどう表示されるか（レイアウトが崩れないか）
- 日文
- 英文
- 長文の場合、途中で省略(…やフェードアウト)するか
- textareaの場合、改行が反映されるか
特に長文、改行、空白考慮あたりは忘れがちかと思います。
動作確認のための「aaa」や「アイウエオ」等、厳密に言えば実際に使われない内容でのテストだと抜け漏れてしまうのです。
実際に使われる場面を想定してテストを行なっていきたいですね！
画面幅に適したUIになっているか？
パソコンの画面幅だけ見てヨシ！👍と思っていませんか？
スマートフォンはもちろん、タブレットでのレイアウトやデザインが適切かどうかもチェックしておきましょう。
周辺機能を壊していないか？
例えば関数を拡張した場合、その拡張した部分のみのテストになっていないでしょうか？
関数に変更を加えたということは、今までその関数が使われていた箇所の動作が変わってしまう可能性が十分にあり得ます（当たり前ですが）。
実装前に関係箇所をチェック・仕様を把握して、実装後にそれが壊れていないかを確認する必要があります。（ほとんどがテストコードを書くことで保証できることでもあります！）
変更内容やどう使われているかにもよりますが、全ての箇所をチェックする必要はないと思います。最低でもいくつかpickして動作確認はしておきたいです。
頭では分かっていても「まあ大丈夫っしょ！」と慢心してしまいがちです（自戒）。
レビュアーも人間である
レビュアーは大体の場合、ソースコードを目で見てチェックすることで修正すべき誤りを発見します。誤りとまではいかなくても、「こういう関数を作れば流用できるかも」「こういうデータの持ち方をすれば良さそう」というようなアイデアを出し合うことで、改善のための議論に繋げることも出来るでしょう。
そしてレビューを受け取った側は、「確かに！いう通りだ！」と納得して言われた通りに修正し、再度レビュー依頼をすることもあるでしょう。
信じ切って、動作確認を怠って…！
だめです🙅♂️ 特に自分より遥かに優秀なエンジニアにレビューしていただいた場合に起こり得ることかと思います。いくら優秀だとしてもレビュアーも人間です。もしかしたら認識に齟齬があるかもしれません。
軽微な修正だからといって、動作確認をすっ飛ばしてはいけません。
「よく分からんがコピペ」は絶対ダメ
少し手動テストとはずれてしまいますが、割とあるパターンではないでしょうか？
「似ている機能だから引数やロジックをちょっと変えれば動くはず…→ 動作確認OKいけてそう！」
だめです🙅♂️ 例え動いたとしても、本当にそのコードが実装したいものに適しているのかをコードを理解してから判断してください。そして理解した上で似たコードとなるようであれば共通化してください。
既に実装・リリースされている機能からコピーしたからと鷹を括って、ちゃんとした動作確認を省略してしまうことにも繋がります。
もし何らかのバグが起きた際に、「コピってきただけでよく分かっていないんです…」では迅速な対応ができません。
自分のcommitするコードには責任を持ちましょう！
まとめ 〜QAチームへの感謝を添えて〜
手動テスト、正直面倒くさいです。（エンジニアは面倒くさがりが多いと聞きます）
上に書いた通り確認しなきゃいけないことが多いですし、スピード感を持って開発しているなら尚更、あのタスクもやりたいしこのタスクもやらなきゃ！と焦りもあるでしょう。
でも、こんなメリットがあります。
- 自信を持ってcommitできて、心理的安全が保たれる！
- バグを起こしたとしても最小限で対応できる！
- 他のタスクをやっている最中に修正依頼が来て、てんてこまいになることがない！
- FBが最小限で済むのでQAチームが助かる！
いいこといっぱいですね☺️
後から沢山修正する手間よりも、面倒くさくても実装時にテストをしっかり行う方が結果として開発のスピードを保てるのではないでしょうか？
そしてQAチームがいてくれていることに甘んじてはいけません。QAチームは完成品(仮)の品質の保証をしてくれているのであって、未完成の足りていないパーツを指摘するためのチームではないのです。（と、私は思ってます）
QAチームの皆さん、いつも本当に助かっています。ありがとうございます！
つまり手動テストをきちんと行うと、自分も、QAチームも、他のエンジニアメンバーも、プロダクトも大助かりということになります。
そう、手動テストはあらゆるものに対しての”救い”となっているのです。
最後に
ミツモアでは様々な職種のエンジニアを積極的に採用しています！ ご興味がある方はぜひ気軽に面談しましょう！
