まずは改修からお願いします🙏 仕様書？自動テスト？...ないですね！

はじめに

はじめまして！テスト実装大好きマンです。

私の場合はテスト自動化の前に、そもそもテストすらおざなりになっている案件を経験してきましたので、自動化に加えてテスト駆動開発を導入したお話も混ぜました。
導入にあたって社内でワークショップも行ったので、記事の後半で紹介します！

はじまりは仕様書なし、テストなし案件

期初になり、ちょうど別案件を担当することになった私は上長から詳細を伺います。

上長「お疲れ様です！次はこちらのシステムをお願いしたく...メイン担当者が他の案件を担当することになりまして」

私「承知しました！

上長「もう一人アサインするので二人でまずは改修からお願いします🙏」

私「仕様書や自動テストはありますかね」

上長「ないですね！」

私「」

（自動）テストがない世界線

私「これでリリース完了ですね！」

メンバー「お疲れ様でした。また明日よろしくお願いします！」

〜翌朝〜

私「さて、今日も1日がんば...おや営業さんから連絡だ」

営業「先ほどお客様より問い合わせがありました。至急確認をお願いします」

メンバー「おはようございます。これバグっぽいですね。」

上長「おはようございます。まず一報入れますね」

私「ログ確認したら解決目処の連絡いたします！」

~以降(同日)~

調査 → 対応目処の一報 → 対応 → リリース → 対応完了の報告 → 報告書作成

そして営業さんはお客様に謝罪をすることになります。場合によってはお客様から解約の連絡を受けることも。

テストがおろそかになることで、このような事態が発生しやすくなってしまいます。

手動テストではなく、自動テストが理想

• 手動テスト

手作業で画面の動きを確認　→　スクリーンショット　→　資料にまとめる

などの手動テストも行ったことがありますが、これだけで数時間溶けます。

また、影響箇所の特定が大変です。手動テストの実施内容をまとめた資料を確認する必要があります。

そして、レビュー依頼を出して追加の改修箇所が入ったらまたやり直しなんてことも...

• 自動テスト

自動テストがあればコードを改修した際に影響がある箇所はエラーになるので、影響範囲の把握が楽です！
影響範囲の把握ができると修正漏れを防ぐことができるので、リリース後のバグを抑えることができますね。

どのように導入したか

皆さんテストは入れるべきという認識は持ってたので、導入に反対する方はいませんでしたが、テストを書く代わりに機能開発やバグ対応が遅れてしまうので、導入する時期は相談しました。

一方で、テストコードを書くのに苦労しました。
一つのファイル・メソッドでいろんな処理をしていたので、テストケースが複雑になったり、モック祭りだったり...

せめて動作する綺麗なコードではあってほしかった、というのが本音です。

導入してみて

楽です！
画面で確認してスクリーンショットしなくて済むんですよ！
また、自動テストを通して他の箇所でエラーが起きないか確認することができるため、リリース前のバグ検知ができます。

テスト駆動開発も導入しました

プロトタイプではなく製品として開発する際は、「動作する綺麗なコードを書く」、「テストを後回しにしない」という目的でテスト駆動開発を導入したく、社内でワークショップを開きました。

• テスト駆動開発とは

テスト駆動開発（TDD）はテストコードを先に書き、テストが通るように実装とリファクタリングを繰り返す開発手法です。 これにより、早期に不具合を発見し修正することが可能となります。

• テスト駆動開発を知ったきっかけはこちらのハンズオンです！

テスト駆動開発のワークショップ概要

開催目的

• テスト駆動開発を体験してもらい、メリットとデメリットを実感してもらう
• 開発の流れを体験してほしいので、コーディングスキルは求めない

開催後に期待する結果

• 参加者がテスト駆動開発の進め方を理解している
• 参加者が自身のプロジェクトに導入したいかを考えてくれる

開催後のアンケート結果

開催目的が「体験会を通してテスト駆動開発の導入について考える機会にしてもらう」なので、評価基準を厳しめに設定してみましたが平均約4点(実践してみたい)という高評価でした！

テスト駆動開発について、体験会前の理解度も聞いてみました。
実践したことがない・知らないという方が半数以上だったため、体験会を通して半数の方に実践してみたい(評価約4)と感じてもらえたようです！

とはいえ、テスト駆動開発を知っているけど実践したことがないという方は何かしらの課題を感じているはずなので聞いてみました。

・結果的には早そうと思いつつ部署内、特に営業サイドへの布教が進んでいないため納期優先になりがち

・テストを書くのが面倒に感じていた
・テスト駆動する分の工数がデフォルトで計上されていない
・テストの書き方がわからない
・やったことがないと調べながらの実装となるので、まず実装することを優先してしまう

そして体験会を通してテスト駆動開発の導入を検討してもらいたかったので、導入にあたってのメリット・デメリットも聞いてみました。

• 実装優先でテスト・リファクタリングは後から！→保守工数確保できなかったみたいなパターンに皆さん耐性がありそうだなと感じました…

• テストを先に書いているとテストの書き方が悪いのかコードの書き方が悪いのか分からなくなり、とりあえず動くものを作っていました。改めてテスト駆動でやる利点と方法を理解できたら取り入れやすいなと思いました。

• テスト→処理を書く⇒テスト→処理を書くでリファクタリングの時間が減りそうな気はしています。

• 営業やお客様にその分の工数がかかるという理解が必要だと思いました。

• 手戻りが発生しづらそう。

• テスト駆動開発を行えていない点として、実際に動いている画面や結果を逐一確認しながら構築しているのが要因になっているのかなと思ってます。(何が返ってくるのかを完全に把握できていない)
  よりシンプルなコードやテストを期待してテストから記載する意識を持っていこうと思います

• 仕様の把握と認識合わせはやりやすくなりそうだと思いました

テスト駆動開発のメリットである、仕様の早期理解や動作するきれいなコードについて実感した、という意見が多かったです。一方、関係者に理解してもらう必要があるという課題も挙がりました。

開催情報

• 月一で開催している部署MTGの枠でオンライン開催
• 参加者は自分を除き10名ほど

体験会のようす

環境構築の時間(10分)

• 事前に環境構築できなかった参加者が数名いましたが、時間内に構築できました。思ったよりスムーズで驚きました
• 環境構築の所要時間はおよそ3~5分程度

導入(5分)

• パワポ資料を使ってテスト駆動開発について簡単に紹介

体験会(30分)

• READMEを参考に参加者が各自ハンズオンする形式で実施
• スタバのBGMを流し、ゆるい雰囲気に
• 体験会準備の裏話をしたり
• 質疑応答したり
  • テスト駆動開発を導入するにあたっての懸念点
  • 他の人に勧める場合はどのようにしたら良さそうか

まとめ(5分)

• テスト駆動開発のメリット・デメリットなどを紹介

おわりに

ここまで読んでいただいた方、ありがとうございました。
自動テスト導入による効果は中長期的に効くもので、システムを長く利用してもらう上では切り離して考えられないものだと思います。自動テストがあるとエンジニア・関係各所も安心・安全なのでどうか導入を...！難しければせめて綺麗に実装して！と切実な願いを込めて...早いですがメリークリスマス🎁