みなさんこんにちは サッカー大好きぽんつよ です！
元々開発チームにいた自分ですが、この度テストチームに移動し、テスト消化をする日々を過ごしていました。

そんななか、とあるミーティングの時に

HAPPY隊長: 「ぽんつよ、テスト設計やってみようか？！」
ぽんつよ: 「是非やりたいです！(楽しみだなーどんなことやるんだろー)」
と安易引き受けたことから、この記事は始まりますwww

テスト設計がどういったものなのか、どのような仕事なのかも知らず
この感覚で引き受けてしまったことが
この後の地獄の怒涛の日々を過ごすきっかけでもありました。。。

ということで、
ぽんつよのように地獄を見ないように
開発経験が若干あって、テスト設計初めてという
ぽんつよと同族諸君のために
アドバイス記事を執筆致します！！！

ps.地獄を乗り越えた心境
壁を乗り越えて清々しい気分です！
一人では間違いなく乗り越えられなかったのでフォロー頂いた3隊長には心から感謝しております！

テスト完了までの流れ

以下が今回経験したフローになります！
このフローに従って経験したことと、同族諸君へアドバイスを列挙します！

ヒアリング
↓
テスト設計
↓
テストケース作成
↓
レビュー
↓
テストケース消化
↓
完了

1.ヒアリング

テスト要件を整理するためにPMとヒアリングを実施するフェーズです。

◯同族諸君へアドバイス

・重要なことを聞き漏らさないよう注意すること

PMさんとのミーテイングの際に会話の中で重要語句が飛び交っていたのですが、相談しているだけかと勘違いをしてしまい聞き漏らしかけていました。
ポンジュース隊長と聞いていたこともあり再確認の際に気づくことができ確認漏れなく、メモ取ることができ設計の際に取りいれることができました。
みんな、今現在要件を考えているという意識を忘れないことが大切だよ！！

◯開発の知識が活かせた点

・イメージができる

開発経験から話していることがプログラムのコードとして「あの要件に対してはこのコード使うのかな」など
イメージがどんどん湧いてきました！
イメージすることができたのでヒアリング工程では、かなり開発経験が活きたと思います！

2.テスト設計

テスト設計はヒアリングで出たことの確認作業、落とし込み、仕様書との照らし合わせを集結させるフェーズです。

◯同族諸君へのアドバイス

・確認の劣化を防げ

確認不要な箇所をケースに取り入れてしまっておりました。
受け身で確認していたため、言われてない観点が漏れたことが原因です。
記者のように自ら情報を拾いにいくことが大切ということが今回の案件通して気づけました！
受け身になったら負けだ！

・人への伝え方

品質は『伝言ゲーム』のように劣化していくため、伝えられれたことを差異なく伝えられるように確認することが大切です。
その確認が疎かになったり、抜けがありましたので、先ほどの確認の劣化でも話しましたが
受け身になったら負けだ！！！

・わからないなら聞いて頼れ

いざテスト設計となったが、テストケースしか見たことないぽんつよはテンパりました。
何にテンパったか。

テスト設計に対してのイメージが全然湧いてこないことです。
結果としてはHAPPY隊長、ポンジュース隊長のお力添えをいただき、完成することができました。
テスト設計の際に、ポンジュース隊長からはたくさんんおご指摘をいただきました。

頼って、聞いて、感謝を述べろ！！！

◯開発の知識が活かせた点

・DB設計書から読み解けた

開発の際にDBの勉強していたこともあり、DB設計書からテスト設計に落とし込むことができました。

3.テストケース作成

テスト設計、レビューも無事に終わり、テスト消化のためのケースを作成していきます。
ここでようやくテスト実施をしていた見たことのあるケースになります。

そんな中でも大変だった点、今回は開発ではなくテスト実施していたことが活きた点を紹介いたします。

◯同族諸君へのアドバイス

・誰にでもわかりやすい言葉で書こう！

こちらですが、自分にしかわからない言い回しをしてしまったせいで「何語？？」とご指摘を・・・
語尾がバラバラでもあったためまとまり感もなかったので、品質として悪い状態になっておりました。。。
自分以外がテストを実施するという視点を忘れないこと！！！

・テスト設計書のありがたさ

仕様書を見て再確認しても期待値が何になるのかわからなかった箇所がいくつかあった。
テスト設計書から起こしていたこともあり、テスト設計書を再度確認することが多々ありました。

仕様書を見てもわからないからテスト設計書をヒアリング段階で書いてるんだ！！！
テスト設計書最強！！！

・第三者確認をお願いしまくれ！

ここのフェーズでは3隊長のご協力をいただき。
HAPPY隊長には流れを教えていただき、ポンジュース隊長からは抜け漏れの指摘、赤髪の隊長からは細かな指摘をいただき完成いたしました。
自分一人では、自分しかわからないテストケースになってしまったところを、３隊長のお力添えもあり誰が見てもわかるテストケースになりました。

初めてで完璧なテストケースは絶対ムリだ！！！
レビューをお願いしよう！

◯テスト実施していたことが活かせた点

・考えられるNGがイメージできた

似たような案件を携わらせていただいたこともあり想定されるNGを事前にケースとして取り入れることができました！
境界値であったり、欠陥の偏在があることも加味した上で今回テストケースを作成することができました！

4.テスト消化

◯同族諸君へのアドバイス

3隊長のお力添えで品質の良いテストケースを作成することができたが、修正前の自分のケースだったらという観点で見ると
示唆を得たので共有するぜ！

・当たり前のことかもしれないが、自分だけがわかる言い回しはNG！
・見やすいテストケースは、自分を含め他の人もテストしやすい
・テストを行う上で忘れていけないのが、納品する上での最後の砦と思うこと

つまり、他の人が見て他の解釈をされるものを作ったりするのではなく、全員が同じ考えになるものを作ることが品質向上のための最大の攻略法だ！

総括

今回初めてテスト設計を実施してみて、
気づいた点のまとめをテスト実施者目線・テスト設計者目線でみるテストの違い２つの目線で書いていきます！！

◯テスト実施者目線

・テスト設計なめたらアカン

消化のみしかしていなかったこともあり、ケースを作成するだけだろ??っと思ってました。。

しかし、PMから渡された情報をもとにテストケースを作ってみるとケースに起こすまでに
・システム仕様を理解する
・開発知識もなければいけない
・誰が見ても理解できるケースを作るためにワーディング能力も必要
と実際には色々なものが積み重なってテストケースができている事実に気づきました！

テストケースを作成することで視野が凄く広がります！

◯実際に行ってみたテスト設計者目線

・テストケースは自分自身

テストケースはテスト実施を目的に作成しシステム品質を向上させるものであると思ってましたが、
テストケース作成時は何が出来ていて何ができないのかがわからない状態であることに気づきました！
とすると、テストケースはシステムの現状を把握することを目的として作るものだと示唆を得ました！

この示唆から、テストケースを作ることは自分自身を分析することに似ているなと強く感じました！
テストケースを作れば自分自身を深く分析できるようになります！

さいごに

テスト設計を携わらせていただきまして、今までテストに対して思っていた点、テストのあり方を知れたと思います。
確認の大切さ、受け身がどれほど怖いことか、十分に知ることができました。
さまざまな指摘が多かったこの案件で色んな失敗であったり色んな思いがありつつ、
自分の反省はもちろんですが、やり切れたことが大きな財産になると僕は思っています。
まだまだ未熟な自分にお力添えしてくださった３隊長を見習い今後の自分の成長につなげていこうと思います。