テスト設計って結局何なのさ？

3月18日に楽しみにしていたPorter Robinsonの来日公演に行ってきました。
特に最新作の「Nature」は春の暖かい陽気の中で聴くと新しいことを始めたくなるような、ちょっとワクワクソワソワした気分になりますね。
残念ながら東京公演当日は雨でしたけどw

■テスト設計で心がけていること

今の案件ではメインの業務が何故か実行管理になっているのですが、内容によっては設計も担当しています。

設計をやるときに気をつけていることは「実行者がわかり易いように設計をすること」
正しく言えば「実行者が質問しなくてもスムーズに実行が行えるケースを作る」になるのかな。

前の会社の最初の長期案件で教わったことです。

前の会社も第三者検証で何件かの案件に携わりましたが、基本的に実行のみのアサイン。
入社して数ヶ月後には設計に興味を持ち、設計をやりたい希望はずっと言っていました。
最初の長期案件と退職前の長期案件で案件で「齧る」程度のことはやらせてもらいました。
その最初の長期案件の時に口酸っぱく言われたものです。

・要入力のケースでは具体的な入力値を指定しろ
・一ケースに期待値は一つだけ
・実行者が質問をせずに済むようにケースを書け

これらはなるべく忘れないようにしています。

■そううまく行くわけないんだよぉぉぉぉぉぉ！！！！！！

ただそうも行かない時もあります。
いやそのパターンの方が多いかな。

例えば去年前半に携わっていた案件は1ケースに箇条書きで1〜2個の期待値が存在することも多々あったし、今の案件は詳細が不明な所も多いので具体的な入力値の指定は正直無理な部分があります。

また、自分の場合はちょっと細かく書き過ぎる傾向があるらしく(粒度が先方が想定していたものよりも細か過ぎるらしい？)、アジャイル開発である今の案件のテストでステージング環境での確認はともかく、本番環境の場合は今までのスプリントのケースも実行しなくてはいけないので、ステージング環境でのケースを愚息に素直に積み重ねているとかなりの量となってしまい、正直本番環境でのテスト実行中には消化できません。
なのでケースを削ったり、本番用に作り直さなければならなかったりしますが、どのように簡略化すればいいのか正直言ってわからない。
細かく作る方法しか知らないからです。
この問題が発生した時に、今の案件のマネージャーにヘルプを出してポイントなどを教えてもらいましたが、正直「ちゃんとできているかなぁ」と言うのもあります。
曰く、彼が受け持っている別の案件でも同じように本番環境のテストは今までの範囲のテストも行うとのことですが、「ステージングでは10件あったケースを本番では2件に絞ることもある」とのこと。
本音言うと「そのワザを教えてくれ！」って感じですけども。

なので、結構ケースを絞るために本来ならもう少し細かくケースを書きたくてもまとめて書いている場合もあります(本番環境用のケースで)。
「下記が表示されていること
　・○○
　・××」
こんな書き方をケースに寄っては書いています。
または、メニューでの遷移確認で
「各画面に遷移すること」
とか。
うーむ、本当はアウトなんでしょうけども…。

確認手順に関しては本当は細かく書くべきでしょうが、メンバーが固定されているチームのテストだったらある程度の省略した内容になってもおかしくはないと思います。
とは言え、せいぜい最初を簡略化して「1.○○画面に遷移する」程度には止めるようにはしていますが。
ただ、固定メンバーでやることは多くても、いつ別案件の人が実行サポートに入ってくれるかわからないのですよね。
仕様書もないし、ケースに寄っては既に結構な手順数になっているものもあるので。

■いつも発狂しています

書いていたら、よく今の案件でテスト項目書を作っているな…と思って来ました(汗)。

割り当てられる課題チケットの内容が結構漠然としていることもあるので、課題チケットの更に元ネタとなっているチケットに貼られているリンクを遡りつつ資料を探したりして(ここは調べものが苦にならないことが幸いしているのかもしれません)、作成しています。
これはJIRAを見れる権限を与えられているおかげもあるでしょうか。
それでもわからないことも多々あり、質問はしているけれども返信までに時間がかかることもあります。
もちろん、資料を漁ってもわからない場合も多いですが、いやそっちのパターンが大半です。
大体設計時はいつも発狂しています(いやマジで在宅でよかったですよ…)。

そんな時は、時間があれば翌日に回すw
スッキリとは行かなくても、一晩経てば違った視点で見れるかなぁ…と言う感じですかね、効果があるのかは不明ですけど。

■そもそも設計って何よ〜？！

そもそもテスト設計とは？

今の場合、項目書のテンプレートに直接ケースを書き始めちゃっていますけど、これって本来ならばテスト設計ではなく、テスト実装の項目書作成にあたるのではないでしょうか。

前の会社ではテスト管理ツールのCATを使っていたこともあり(会社が会社だったからなぁw)、パターン表と言う表で最初に観点を洗い出していたのでは、と今更ながら思います。
所謂デシジョンテーブルの応用版と言う印象です。

今は先ほども言ったように課題チケットに沿って直接テスト項目書のテンプレートに作成している形になります。
なおかなりの激レアではありますが、課題チケットによっては「大体こんな感じかな」とイメージが湧く時もあったりします。

正直言うと、これでいいのかな、と思っています。
迷走している感があります。
設計についてちゃんと学びたい、特に今の案件に沿ったアジャイルテストの設計について。
粒度の合わせ方について。
感覚でやっているところをちゃんと理論付けたいと言うか。

去年心折れてから仕事絡みの勉強を一切しませんでしたが、そろそろ再開する時が来たのかもしれません←実際にやるかはわからないけど。

■とまぁカッコ付けては見たものの

人間なので、やらかすのです。

実行者「No.XXについてですが、○○のことを指しているのではないでしょうか？」
我「うわぁぁぁぁぁぁぁぁ！読み替えでお願いしまーす！！！！！」

大体毎回何かしらやらかすので、心の中で全力土下座です…。

■余談

冒頭でPorter Robinsonの東京公演に行った話をしましたが。
その翌週である3月25日、羽田空港で行われたMUSIC UNITY 2023でDJ NOT PORTER ROBINSONと言う謎wのDJが出演するとのことで、急遽観に行ったわけですが。
DJ NOT PORTER ROBINSONは誰なんだ？！と物議を醸しつつも、大盛り上がりでしたw

ぶっちゃけるとPorterご本人で、DJ NOT PORTER ROBINSONと言うのは
Porter本人とわかった上でのおふざけと言うか。
Porter自身は元々J-POPやアニソンの影響も受けている人らしいので、ミュージシャンPorter Robinsonとしてではなく、J-POPやアニソンオタク要素を盛り込んだDJとしての参加でした、の割には自作曲も合間に挟んでいたけどもw
J-POPやアニソンは全く知らないので、かけた曲についても本人の曲以外は知らなかったけど、空港でのDJイベントという物珍しさもあって結構楽しかったです。

18日の東京公演終わってすぐ帰国or次の公演先に行かなかったのか、ってのが正直な感想ですが。