最初に ～記事の目的と主な想定読者～

この記事の目的はとあるプロセスを周知させて、この世からテスト工程での躓きをひとつでも減らすことです。

著者のしくじりのお焚き上げではございません。

主な想定読者は、例えば以下のような理由でモヤモヤしたエンジニア全般です。

• 受入テストで月またぎでの状態変化を見たいのに、月またぎのタイミングでシステムメンテナンスがあるとテスト実施期間中に言われた

• テスト実施期間中に「開発担当者しかこのテストデータが作れないので準備してほしい」と言われたけどもっと早く言って欲しかった

• WBS作成時に「設定ファイルの書き換え等のテスト環境準備はテスト設計とは思えないけど、厳密にはテスト実行に入れていいのか？」と迷った

どれもピンとこないなら読まなくても問題ないかもしれませんが、一応読んでみてください。

そのテスト、本当にサクッと実行できますか？

そろそろ年末年始の準備が始まる時期となりました。いつぞやにCTFの記事を書いた大阪第1拠点のチルダ鰯です。自己紹介が気になる方はこちらの記事の冒頭をお読みください。

忙しくなる年末年始ですが、クリスマスは生まれて初めてケーキを焼こう、年末の大掃除は使ったことはないけれど評判のよい洗剤で挑もう、と新たな挑戦を試みる方もおられるかもしれません。あわただしい中でも何かに挑戦する遊び心や若々しさ、素敵です。

しかしですよ...

有名パティシェの書いたレシピでケーキを焼こうとした当日、「だいぶ前に買ったはずだよね」と今回購入不要と判断した焼き型がいくら探しても見つからないなんてことはないでしょうか？

せっかくインフルエンサーもおすすめしていて口コミサイトでも高評価の洗剤を買ったのに、自分が一番掃除したいリノリュームの床には使えない成分が入ってはいないでしょうか？

完成度が高い指示書や有用なテクニックがあっても、実行できる環境と材料・道具が揃っていない、実行する上での制約が守れていない、などの理由でなかなかうまくいかないことがあります。

テスト工程でも同じことはあるのではないでしょうか。テスト手順と期待値が一意的で質が高いテスト仕様書を完成させた場合でも、テスト環境の準備が不十分だった、事前データの作り方やテスト実行手順が一意的でないので作業が進めにくい、などの理由でテスト実行に支障が出ることがあります。

このようなトラブルはテスト実装というプロセスを充実させることで防止できると考えられます。

テスト実装はテスト実行準備のためのプロセス

「テスト実装」はテスト実行準備のためのプロセスです。具体的には、テスト環境の準備、事前データ作成、日またぎでの挙動を確認する時などのスケジュール調整、テストユーザーの準備などが行われます。

あまり聞きなれない言葉かもしれません。現に私もJSTQB FLの試験対策をするまで知りませんでした。しかし、あらゆる案件のテスト工程でほぼ100％実施されているはずの、いわば隠れプロセスです。

弊社にはSQF（SHIFT Quality Framework）という、社内に蓄積されたナレッジと業界標準に基づいた独自の品質保証標準があります。SQFではテスト実装は個別のプロセスとして扱われています。弊社サービスサイトのこのページのポイント3にも、SQFおよびSQFの中でのテスト実装の位置づけが記載されています。

また、IPAから2010年9月に発行された『高信頼化ソフトウェアのための開発手法ガイドブック- 予防と検証の事例を中心に -（Ver.1.0）』内にも一部だけですが特段の用語説明なしに登場します。つまり、（著者が「ここが使ってる用語ならIT業界では特段の説明なしに通じる言葉だと認定していいよね」と信じてる）IPAも認知している用語です。

ちなみに「テスト実装」でググると、検索結果上位に弊社のマーケティンググループのページ『テスト実施(実行)ですべきこと～必要な準備と実施手順について紹介～』があります。

こちらにテスト実装の目的やすべきことが詳細かつ簡潔に書いてあります。ぜひご覧になってください。私が本ブログでの説明をさぼりたい訳ではございません。

しくじり先生「テスト実装への配慮が甘いままテストデータを設計したら、実行者が何回も質問する羽目になった」

準備は大事だと皆口をそろえて言いますが、テスト実装というプロセスを軽視した結果失敗した例を私は知っています。なんせ私が経験したんですから。

開発中のWEBアプリ（以下、アプリA）を姉妹品のWEBアプリ（以下、姉妹品）も使って検証する案件に参画していた時のことです。

私は姉妹品で特定のパターンで事前データを登録した時のアプリAでのアラート表示を確認するテストにむけて、テスト仕様書に加えて各アラートの表示/非表示を確認できるテストデータを設計したことがあります。

同時登録する項目数もアラートの種類も多く、データパターンと各アラートの組み合わせが複雑でした。

それどころか、姉妹品では

• 項目1にこのデータを設定すると、項目2、3は入力不可になる

• アプリAの仕様書だけ見ると項目4には何種類もデータが登録できそうだが、実際の姉妹品では3種類しか登録できない

などデータ設定の複雑な制限がありました。ですので、事前データ登録時には注意が必要でした。

しかし、私は頭の中だけで理論上のテストデータを設計しただけで、姉妹品での挙動はそこまで見ていませんでした。

すると、実際にテスト実施に備えて事前データを入力するテスト実行者から「このデータパターンだと実機で設定できません。他の登録可能なデータに振り替えてもいいですか？」等の連絡・質問が相次ぎました。一応スケジュール上は間に合っていたはずですが、テスト実行者には申し訳ありませんでした。

今回の失敗の原因は、実装可能なテストデータを設計できていなかったことです。これはテストデータ登録における制限を考慮できていなかった、つまり、テスト実装への配慮が甘かったことにあると考えています。

この失敗を思い出すと、理論ベースで設計したテスト仕様書などの成果物を実際に役立てる状態にするのがテスト実装だと実感します。

存在感が薄くなりがちなテスト実装もプロセスとして名前を呼んであげて

このどこのプロジェクトでも行われているはずのテスト実装ですが、いかんせん呼び名の知名度が低いためプロセスとして存在感が薄くなりがちです。おまけに実際の担当者が次の例のように分散しがちです。

• 事前データはテストデータ設計に基づいてテスターが登録する

• テスト実行手順はテスト設計者が作成する

• テスト環境の準備や制約の確認は顧客側が担当する

• 実行スケジュールの調整は案件管理者と顧客で相談する

一時期「名もなき家事」という言葉が流行りました。麦茶や洗剤の補充や写真整理のように、掃除や炊事のように大きなくくりには入っていないために分類しづらい家事のことですが、テスト実装は名前があるのに名もなき家事と似たような扱いを受けているような気もします。

しかし、せっかく名前があるなら名前を付けて呼ぶ方がプロセスとしてより強く意識することができ、テスト計画時やテスト設計時により配慮できるかもしれない...と昔の自分に言いたいです。

なお準備は大事ですが、私は書くネタこそは準備していたものの執筆というプロセスを先延ばしてしまいました。準備だけじゃだめですよ!...とちょっと前の自分に言いたいです。

★★SHIFT公式ブログでアドベントカレンダー★★
明日の記事は、
『自慢や嫌味にならないー成果を上手に伝える方法 Day.7』
お楽しみに！

お問合せはお気軽に

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら