![見出し画像](https://assets.st-note.com/production/uploads/images/105372648/rectangle_large_type_2_13548a91ca69f2f18b849457585ed7b9.png?width=1200)
映えるテスト設計を目指して
良い子のみんなー!
愛と平和を歌って笑顔を届ける愉快なピエロ、MR.SMILEだよー🤡
前々回と前回でテスト分析を紹介したよ。
今まで読んでくれてた良い子のみんなの
一部はもうわけ分からんと
脱落してしまったんじゃないかと
気が気じゃないよ、、、
かなりニッチな方向性なので
続けて読んでくれてる
良い子の方が少ないのは知ってるけどね。
引き続き読んでくれる良い子や
これから読もうと思ってくれる
良い子のためにも、今回はテスト分析の
次にやる作業、テスト設計を解説していくよ。
何を設計するの?
テスト分析では、
どの機能をテストするのか、
機能を構成する要素のどこを
テストするのがいいか
と言うの特定するよね?
その分析結果を元に機能や構成要素が
どんな条件や手順で
どう動くのが正しいのか?
と言う条件、手順ごとに
パターンを出していくんだ。
既にIT業界で働く良い子のみんなには
どんな条件と入力値で
正しい出力(期待値)になるか?
と言うパターン抽出をすること
と言えば伝わるかな?
簡単に言えば、テスト分析で検討した
「何をテストするか?」を元に
テスト設計で「どんなテストをするか?」
を決めていく作業になるよ。
結局、何すんの?
お馴染みのJSTQB は次のように述べているよ。
• テストケースおよびテストケースのセットを設計し、優先度を割り当てる。
• テスト条件とテストケースを支援するために必要なテストデータを識別する。
• テスト環境を設計し、必要なインフラストラクチャーやツールを識別する。
• テストベース、テスト条件、テストケースの間で双方向のトレーサビリティを確立する(1.4.4 節を参照)。
どんなテストをするかの設計図、
テスト設計仕様書と呼ばれたりする
資料を作ることが解説されてるよ。
上の方で書いた
「条件、手順ごとにパターンを出していく」
と正しい結果(期待値)が何かを
書いていくことが
テストケースの設計に該当するよ。
テストケースのセットは同じ機能や
関連する機能の組み合わせの
テストケースをグループ化してまとめる
というイメージで掴んでおこうね。
テスト設計仕様書の作成を例に考えると
理解がしやすいと思うよ。
テスト分析で出した機能
(テストアイテム、テストフィーチャー)
の一覧表、
機能に対してどんな内容に注目して見るか?
を書いてある観点一覧表、
機能と観点一覧を組み合わせたテストマップ、
他にもテスト技法と言う考えを元に
分析や情報整理した資料、
テストに必要な環境、機材、データの一覧とかも
をまとめてテスト設計仕様書として出すんだ。
![](https://assets.st-note.com/production/uploads/images/105386998/picture_pc_1c1d0d9d391f09c124ac3ee7956fe593.png?width=1200)
ここで細かく、更に分かりやすく
作ることができていれば
次の工程、テスト実装がかなり楽になるし、
テスト設計だけ担当して、テスト実装は
別の人にパスすることもできるんだ。
トレーサビリティについても説明しておくね。
テスト設計を作る元になった
テスト分析資料のどこを見て作ったか
分かるよう参考箇所や番号などを付けて
後から追いかけられるようにしておくことだよ。
もちろん、テスト分析の資料の方にも
元になった設計書、仕様書とかの資料
(テストベース)を辿れるようにしておくのが
重要なんだ。
![](https://assets.st-note.com/production/uploads/images/105386796/picture_pc_02ac810fcd75a9989e4c637d45bbfa02.png?width=1200)
そして何より映えること
ここからは僕が今まで担当したお仕事での
経験を元にしたお話をするね。
JSTQB FLだけがターゲットの人は
読み飛ばしてOKな話だよ。
大体、テスト設計の次の工程、
テスト実装で作る物はボリューミーな
内容になることが多いので
事細かにチェック(レビュー)されることは
少ないんだ。※
テスト設計で書いた内容の重要なポイントが
しっかりとテスト実装に入っているかどうか?
と言う点に絞らないと
相当な時間が掛かってしまうからね。
その点、テスト実装の前段階の資料、
テスト設計は細かくチェック
(レビュー)されることが多いよ。
だから、テスト設計の資料はチェックしやすく、
分かりやすく、自分も説明がしやすい、
そんな映える資料であることが期待されるんだ。
ただ、これも実際にはレビューをしてもらう
担当者の趣味が入ってきてAさんは見やすいと
言ってくれていた形式で作ったとしても、
レビュー担当者が変わってBさんからすると
分かりにくいと指摘を受けたりすることもある、
この辺は担当者に合わせて頑張って変えるか、
自分の説明スキルを上げるかを
考えることになるよ。
少なくとも誰かにお見せする資料であることを
頭に入れて作っていくのは
忘れないようにしないとね。
(と自分自身への反省も含めて言ってるよ)
※「少ない」だけで細かくチェックされることも
あると言えばあるので手を抜いてはダメ。
むしろ、後の工程のテスト実行担当者から
怒られるよ。
テストプロセスの中でもテスト分析に
比べると分かりやすい内容だったんじゃないかな?
次回はテスト設計の後工程、
テスト実装を紹介するね。
では、今回はこの辺で!
最後まで読んでくれた良い子のみんなー!
さんきゅーすまいる🤡
この記事が気に入ったらサポートをしてみませんか?