テスコンU-30チュートリアルに参加しました。
テスコンには参加しませんが、テストに関するスキルアップのため参加しました。もともとは資料を眺めているだけでしたが、同僚とテストの話をするときに資料を参考に説明をしていると、ふと「この説明であっているのだろうか」と不安になったため、この資料でどんな話をしているのか気になったので参加することにしました。
当日のチュートリアルに参加して
以下、口頭で説明されていた部分で、私がポイントだと思った点や気づいた点です。
（※理解がずれている内容もあるかもしれません）
本チュートリアルは、いかにいいテストをするためにどうするかを考えるもの
テスト技法が出てくるのは、具体的にテストケースを作るとき（工程としては最後のほう）
私にとっては新しい知見でした。今まではテスト＝同値分割！ブラックボックス！みたいな感じでした。「テスト設計」を考えると、技法についての検討はもう少し先なのは納得しました。
ワークショップにて
ワークショップで、結果を共有したときにマインドマップで検討している方がおられて、そういうツールがすんなり出てくるあたりすごいなぁと思いました。
バグが出ることがテストの価値ではない。テストしたからバグが出ないことがわかる。そのためにどんなテストをしたか説明できないといけない。
これまでの取り組みでは「テストでバグを見つける」ことを意識しすぎていたかもしれません。「バグがない」ことを知るためにもテストが必要ですもんね。
膨大なテストケースはレビューできない。テスト観点で構造化すればレビューしやすくなる。
これはチームでも何となく問題に思ってた点です。今のテスト仕様書はただの羅列でただただ数が多い。今のテスト仕様書を構造化する取り組みから始めてもいいかも。
制御パス・手順もテスト値に含まれる
今まで操作手順によるテストってアドホック的にしか考えてなく、それが「テスト値」という考えすらなかったです。テスト値と考えると、いろいろなテスト技法も活用できそうですし、ちょっと考え方が広がりそうな感触がありました。
感想
チュートリアルで具体的なイメージが付きやすい話が聞けたので、聞いておいてよ良かったです。また、スライドも十分わかりやすくまとめてあるので、理解に大きなずれはなかったかなと思います。
後日談
このチュートリアルに参加したあと、社内のメンバーにも共有を行いました。
共有するにあたり、以下の点に重点を置いて共有しました。
-
まずは「テスト観点」という考え方を理解してもらうこと
-
”チームで考える”ことに意味があること
-
テストにも開発と同様にプロセスがあること
主な反応としては、以下のような感じでした。
-
テストを構造化すればいいことはわかった
-
なんとなく雰囲気はわかるが、実際にどうすればいいのかもやもやする
-
とりあえず何かで試してみたい
私が理解した程度で話をしたので、十分に伝えられたかはわかりませんが、雰囲気は掴んでもらえたようです。特にチーム内で、今までの羅列していたテストよりもこっちのほうが良くなりそう、という感触を得られたのでよかったかなと思います。
