タイトルも思いついたら更新します

JSTQB(ALTM)の試験勉強の記録を日々つけていましたが、2019年10月からはJSTQB(ALTA)の学習記録をつけるブログ

【振り落とされたが】テスト設計コンテスト'20 チュートリアル行ってきた①【聞いてよかった】

■テスト設計コンテスト'20チュートリアルとは?
http://aster.or.jp/business/contest/tutorial.html
より引用
>このチュートリアルでは、過去のコンテストの応募作を基にして、
>意図がきちんと分かり全体像を説明できる質の高いテストを設計するための考え方を解説します。
 
■実際どのようなかんじだったか
・「どんどん振り落としていく」方式のロデオスタイル。
めくるめく言葉の嵐によるテスト設計についての講義。エキサイティングな120分
・ただし大事なところは念を押して言ってくれるスタイル
・内容はテストをいかに分析しやすく、説明しやすく、成果物として質の高いものにするかのお話
<ベースからいきなりテストを作らず、ソフトウェアと同じように成果物として作る!>
 
■感想
・振り落とされた
・振り落とされたけれど、テストコンテナが「設計しやすく分析しやすく分解しやすい何でもありのグルーピング」
というのはわかった
・振り落とされたけれど、抽象度を挙げたり図を描いたりして、俯瞰できるようにすることで説明がしやすくなる。
→説明しやすくなると、人とわいわい相談しやすくなる、というのはわかった。
・テストモデルを作ることに正解・ゴールはなく、その場にいる人の技術的限界までやりきるしかないということもわかった
 
わかった、ばかりであれですが(しかもわかった気になっていてわかっていない可能性は高いですが)
なぜ抽象度を上げてテストモデル(ひいてはテストコンテナ、アーキテクチャ)を作る必要があるのかを
ものすごく丁寧に順序立てて説明してくださっていました。
一つはなぜこのテストをするか、テストの目的を明らかにするため
一つはバグが出た時の分析のため。(どこが悪かったかを突き止めたいときに、工程がモデル化されていないと原因を特定できない)
一つはテストの組み立てやすさ(同じ考え方で作るテストをまとめる)を上げるため。
一つはテストの自動化を容易に行うため(将来膨大な手動テストを増やして負債にしないため)
 
私はテストを実行したり作ったりする人なので、普段実施している内容と被るところがありました。
テスト抽象度を挙げることの必要性を、見やすく、レビューしやすく・・程度に考えていましたが
今日の講義で、テスト全体の「形」を見渡すことは、今を場当たり的にテストするのではなく
テストを資産として活かしていくのに必要なことなんだなと痛感しました。(バグ分析の下り、コンテナの活用とかとくに)
Excelは、みんなで相談するネタにするのは見づらいですね。。ここは本当に身をもって感じます。うへあーってなるので・・
そして、テスト設計は・・・完璧にできた!は無く、いつまでも全力で取り組むのが出来うる最善策なのだと、、、明日からもがんばろー(今日や
 
■内容
振り落とされたものの、長くなるので次記事へ続く
(今日中にまとめようと思ったが徹夜になるので明日へ…)