テスト指導
はじめに
当技術士事務所は、固定のお客様（１社）から継続してお仕事をいただけるようになってきました。
大変ありがたいことだと感謝しております。
一方で、これまでは私のスキルアップのために技術検証を中心にブログを書いてきましたが、今後はもう少しラフな形で技術士事務所としての活動内容を投稿していきたいと思っています。
今回は、テスト指導についての記事となります。
どのような状態だったのか
ある会社様向けのシステム開発を、途中段階からリリース（今風に言うとローンチ）までを担当させてもらいました。
状況は以下のような感じでした。
- オフショア開発、ブリッジSEあり
- 日本側のSEが書いた仕様書は存在するが詰めの甘い内容
- 日本側のSEは経験が浅くシステムの構成などを把握していない
- テストも感覚的にしか行われていない
- システム構成の概要は以下のような感じです。
- Web画面からある商品を登録し、それらの売却、在庫管理を行うシステム
- インフラ：AWS上のEC2、RDS（Postgres）
- サーバーAP：Tomcat+Spring＋Kotlin
- クライアントAP：React
動作確認した結果
結論から言うと、全く動作しませんでした。
画面入力もダメ、帳票出力もダメ、売却も在庫も何もかもまともに動作していませんでした。
そして、前任担当者も原因不明の体調不良となってしまい、かなり困った状況に置かれました。
リリースまでの期間は3週間ほどしかありません。
さぁ、どうする。。
テストの準備
まずは、経営者にアラームをあげました。
テスト要員を増員して体制を組むように依頼したわけです。
結果、パートタイムのテスターさん3名の体制を組んでいただきました。
続いて、テストケースが未作成でしたので（！）ケースを作成しました。
時間がないですし、私も仕様を6割くらいしか把握していなかったので、以下のような対応をしました。
- 時間がないので、ある程度の残存バグは仕方がないと割り切る。開発規模からの適正なテスト項目数なんて固い話も抜きにする
- テスターさんも仕様を把握していないので、テストケース作りもテスターさんに依頼
- テストはマスター登録などの簡単なケースから着手
テストの実施
テストは、以下のように進めていきました。
- 概ねのマイルストーンを決め、テスターさんに作業を依頼
- 日々のコミュニケーションは、Slack
- Trelloというタスク管理サービスを使ってバグチケットを管理
- 私は主に以下を担当
- 再整理が必要な仕様のまとめ
- ブリッジSEへの説明
- マトリックス表の作成などテストの方針の提示
- 不具合発生時にログやデータベースを確認して切り分けなどの実施
最初の段階ではテスターさんも私も仕様がわからず不慣れでしたが、幸いシンプルなシステムでしたので、1週間程度で仕様の大部分を把握できるようになり、作業も捗るようになりました。
特に重要な機能については、テストの粒度を上げるためマトリックス表を作成してテストする対応を行いました。
また、テストの後半は、以下が多くなってきました。
- 仕様があやふやな部分の明確化と改修
- お客さまからの追加要望や仕様の誤解などの改修
リリース
システムは、先週無事、リリースすることができました。
お客様からも業務効率化が達成できそうとの感謝のお言葉を賜ったそうで、素直に嬉しく思っています。
細かな問題はまだ残っていますが、業務に大きな影響を与えるものではないので、少し落ち着いたら改修を入れていきたいと思っています。
まとめ
守秘義務があり、詳細を書けないので抽象的な記事となりました。
ここまでひどい状態は、久しぶり（30年ぶりくらい）にみました。
原因を挙げるとキリがないのですが、軽く整理すると以下のようになります。
- 経営者（営業担当者）が担当者に丸投げして放置
- オフショアとのコミュニケーションが不十分
- オフショア側の役割が不明確
- 製造だけなのか、テストもするのかなど
- オフショア側が個人のようで、そもそも”テスト”という概念を理解していない
- 担当技術者の力量不足
今回はある意味、気合いで乗り切った感が強いのですが、所感は以下の通りです。
- リリースの成功は、作業者の熱量に比例する
- テストケースが作成できる優秀なテスターさんは非常に大切
- 今回は本当に救われました。大変感謝しています。
- データベースを実際に確認することの重要性
- オフショア側との役割分担やプロセスの取り決めの重要性
- どのようなテストをするのか
- リリース前に必要なプロセス（リリースの事前通知やリリース項目の通知方法など）
リリース後は、（いつものように）不安と脱力感だけが残り、お客様の感謝の言葉だけが唯一の喜びでした。
コメント