117. テスターの一日 その⑧
YWT (ふりかえりの方法）
YWT（わいだぶりゅてぃー）は、
- やったこと
- わかったこと
- 次にやること
でふりかえり、次に経験を活かすやり方です。
まずは「こういうことあったなぁ」と考えながら、やったことを書き出します。
そしてそれらを思い出しながら「そういえばこんなことわかったっけ」とか「これいい感じだった」とか「こういう風にやればちょっと速かったんじゃない？」といった、わかったことを書き出します。
それらから「じゃあ次はこういうことをしよう！」と出していくわけですね。
経験のふりかえりに良い、といったところです。
他のふりかえりの方法にはKPT（けぷと）があります。
KPTは、
- Keep (続けたいこと、よかったこと)
- Problem (問題点、よくなかったこと)
- Try (次に試してみること)
でふりかえり、カイゼンをしていくやり方です。
まずはKeepを書き出します。
そしてProblemを書き出します。
その後Tryに行くのですが、KeepやProblemを同じような内容でグループ化してあげるとTryが出しやすくなります。
そして、KeepとProblemからTryを出して次に活かしていきます。
Tryについては全部やろうとする人をよく見ますが、欲張らずに、できれば着手しやすくて効果がありそうなものを１つ２つやることをオススメします。
（いっぱいTryを積みすぎると、次のKPTで「～ができなかった」のPが並びますｗ）
KPTはKeepとProblemからTryを出すのですが、どちらかというとProblemにフォーカスが当たり、それをどうしていくかという流れになりやすいです。
よってカイゼン向きのやり方と言えるでしょう。
トレーサビリティ
トレーサビリティは、難しく言うと追跡可能性と言います。
要は、追うことができるか、です。
テスト項目の実行の部分だと、Failed（NG,失敗した部分）があります。
テスト項目でただFailedとステータスがついてるだけ何も書いていないと「何でFailedになったんだろう」となってしまうのですね。
そしてそのFailedになった部分が直ったのか、直ってないのかも追えなくなってしまいます。
なので、Failedになったところには大体の場合はバグ票のURLなんかを貼っておきます。
そうするとそこで何があったかがわかります。
また、そのバグ直ったらそのテスト項目の確認テストを実施することができます。
テスト項目がFailedになってから、バグが直って、そこの項目がPassになるまで管理ができるようになるわけですね。
地味に大事です。
見てると、チームの成熟の流れがだいたいこんな感じで思っています。
＊＊＊
とりあえずテスト実行すればいいやの段階。
テスト項目もFailedはFailedのまま。
特に支障もないし、わざわざ記録する意味もないと考えるのでこのプロセスで進む。
↓
Failedの部分が直ったのか直ってないのか確認しないでリリースかけることが常態化。
↓
本番障害が発生！
「テストの項目にあったよね？」ってなる。
再確認するとFailedのまま。
この項目のバグは一体どれなんだ……と探し回ると、バグ票も放置されていた！
すごい怒られる。
↓
テスト実行ちゃんと管理しようね、ってTryがあがる
テスト項目でFailedになったところについて、バグ修正したらPassにしようね、って手順が具体化される。
↓
何回目かのKPTでテスト項目にバグ票のURL書いておいた方がわかりやすいよね、ってなる。
（バグ票の方には出したテスト項目番号貼っておこうね、も出るかも）
＊＊＊
大体こんな経験を踏んで、トレーサビリティ大事（テスト管理大事）だよねに行きつきます。
僕の経験上、一番最初の段階にいるチームにトレーサビリティの話をした場合に返ってくる言葉はこんな感じ。
「いえ、記載に時間がかかりますし、テスト項目も多いので省略したいです」
