テスト実行経験がないけどテスト実行管理をやってみた~前編~
まえがき
皆さんお久しぶりです！半年ぶりにブログを書いております！畠山です！
案件にアサインされて半年が経ちましたが、この半年間は色々なことがありました。その中から今日は私がテスト実行管理を行ったことについて話していきたいと思います。
プロローグ
きっかけは少し気温も暖かくなってきたある日。1年以上続くフィーチャーのリリースまで残り4ヶ月を切ったタイミングで、フィーチャーのテストを管理していた先輩Oさんが別案件への異動となった。聞かされたのは異動まで残り1ヶ月ということ。
「Oさんがいなくなってこのフィーチャーは大丈夫か？」とテストチームの誰もが思っただろう。自分も非常に不安だった。不安と共に、ひとつの疑問も生まれた。
「このフィーチャーのテスト実行管理って誰がやるんだろう？」案件管理者に聞いたところ「畠山さんやってみたら？」と言われた。私はあまり考えずに「やります！」と答えた。
第一の壁 タスクサイズって何？
まずは日々のタスクの見積もりで壁にぶち当たった。テスト実行をやったことがないから、どのテストにどれぐらい時間がかかるのかわからない。そもそもリリースまでにテストが完了するのかわからない…。私はとりあえず時間で見積もりを出してみたがなかなかそれ通りに進まなかった。そんな時に上司にWBSというものを教えていただいた。
WBSとは必要なタスクを細分化し、着手順序を設定し、構成図を作成するもの。1日当たり全員でどれぐらいのタスクができればリリースに間に合うのか。今のペースなら1日当たりどれぐらい消化できるのかを出してガントチャート化することができた。リリースまでのスケジュールを可視化することによって、自分以外の人にもテストの進捗を共有することができた。
今回は時間で見積もりを出してみたが、同じ画面の設計でも人によってタスクにかかる時間は変わる。そういった点でも苦労をしていたが、プランニングポーカーを使用すればよかったかなと今になって思う。プランニングポーカーは1つのタスクにかかる見積もりをフィボナッチ数列という技法を使用し、全員でポーカーのようにかかる工数を出して話し合うというもの。そもそも1人でタスク工数を考えずに全員を巻き込んで考えるべきだった。
第一の壁にぶつかっている最中、私はまた別の壁にあたることになる。
第二の壁 開発が遅れていて予定通りテストが進められない
不慣れながらもとりあえずのテストスケジュールはできたが、再び問題に直面する。
デプロイされると伺っていた画面が予定日にデプロイされない…。その画面がデプロイされないと他の画面もテストを進めることができない…。立てていたスケジュール通りに進めることはできなさそうだし、どうしよう。終わらないものに何を言ってもしょうがないので、終わらないことを受け入れ、私たちは何をするべきかを考えた。いつ頃デプロイ可能かを確認し、スケジュールの修正を行った。
私たちは画面分析書を作成することにした。 (※1) 設計書作成前に一度分析は行っていたが、長期に渡るフィーチャーの為変更点が多くあったのだ。分析書を作成する中でトリガーなど仕様について改めて疑問を多く持つことができた。実行前に仕様の再確認をする場にもなり良い時間にすることができたと思う。
分析書の作成を終えてもまだ時間はあった。次に私たちはテストデータをまとめた。(※2)テストデータはテスト設計書を確認し、必要となるデータを設計書ごとにExcel内に保存した。これについては後で後悔することになる。各設計書ごとでなく1つのシートにまとめておいた方が管理しやすい。又、一度作成した設計書から必要なデータを洗い出すのは二度手間になるので、設計書作成時に必要データもまとめておいた方が効率的と感じた。
第三の壁 テストのやり方がわからない
予定より遅れはあったが次々とテスト対象画面がデプロイされていった。今回はスマートフォンで使用する画面もあるのでいくつかの端末でのテストや、SMS、メール、LINEとも連携するサービスなのでそういった部分のテストも行う。まぁどれもすぐにテストできるだろうと思っていた。
結論から言うと、SMS、メール、LINEはすぐにテストができない。いずれもタイトルや本文、送信の確認はすぐにできるが、メッセージボックスや、メールボックス、LINEのトークに届くことの確認は準備が必要になる。これが全て一緒の作業なら負担にはならなかったが、それぞれ別々のサービスや他社との連携が必要になり私は大混乱だった。今のチームにはSMS、メール、LINEのテストを行う際の流れがどこかに記載はされていなかったので、まとめることが必要だと感じた。
テスト実行中はトリガーの認識ができていなくて苦戦をした。対象ロジックのトリガーがバッチ実行なのか、業務日付の切り替わりなのか。恥ずかしいことに当時は「バッチ」という言葉の意味すら知らなかったのだ。これらについては自身で画面遷移図を作成し、その中にトリガーを記載してまとめることによって解決できた。
次のフィーチャーではテスト設計書の中にトリガーはバッチ実行なのか、業務日付の変更が必要なのかをまとめておいた方がテスト実行者の負荷の削減につなげることができると思った。
3つの壁をどうにか乗り越えてここまできたがテスト実行期間中もいくつかの壁が現れることになる。
後編に続く。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
執筆者プロフィール：畠山 一海
新卒で通信業界にてキャリアショップの店舗スタッフを約1年間経験後、人材業界にて転職プラットフォーム新規開拓営業を約2年間経験。2021年1月にSHIFTに入社し、案件管理者を目指して、日々奮闘中。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/