128.テストプロセス　その⑩

今回は「テスト完了」です。

自社開発のチームだったりすると、結構なおざりにされるプロセスです。

まずはテストサマリーレポートの提出があります。

テストサマリーレポートは、どんなテストをしたのか、テスト結果としてどうなのか、残ったバグとそれに伴うリスクはどんなものなのか、といった情報をステークホルダー（関係者の意味）に伝える資料です。

これによって、ステークホルダーは意思決定を行います。

作者の経験上(web/app系自社開発)では、問題などについてテスト完了より前にすでに話し合っていて、テスト完了時には残バグなどの対応方針が決まったうえで完了、が多いかなといったところです。

残バグについては、マンガに書いたようにわかってること、わかってないこと、リスクを伝えましょう。

それと、放置はしないで対応方針を決めて（もしくは対応しないことを決める）優先度をつけて、バックログに積むなりしておきます。

ちゃんと積んでおかないと、新機能実装に追われて放置されることが多いです。

（ユーザーに言われて慌てて直すまでがセット）

作者は残バグを優先度順にリスト化してテストサマリーレポートに載せてました。

マンガに記載していないところだと、テストデータなどのテストウェアを次回も使えるように整理、保管します。

テストデータは使いまわしがきくようにできるのがベスト……と作者も思ってやっているのですが、結局新しいデータを作ることも多かったりします(汗)

テストケースは記憶が新しいうちに編集や追加をしてしまって次のスプリントに備えたりしています。

カイゼンのサイクルを回すためのカナメが「ふりかえり」です。

次から次へと案件が来るので忙しくて飛ばしてしまう気持ちもわかるのですが、やらないと次回に繋がらず、なかなか進歩もしないのですよね。

非効率なプロセスは非効率のまま、ただ忙しさに追われてひたすらこなす、ということになってしまいます。

そのことについてのマンガ（寓話？）も以前描いたりしました。

加えて、ふりかえりのような場がないと情報の共有もあまりされなかったりすることもあります。

自分が問題だと思ってるし他の人も問題だと思っているだろう、きっと誰か対策してくれるだろう……

と思っていると、自分しか気づいていなくて、対応もされないということがあったりします。

最近の現場だと、ふりかえり会をしていたのですが最初は全然意見が出なかったです。（そこそこ人数が多い現場）

内省といいますか、起きたことに関してどれだけ情報が得られるか、考えられるか、といったことには慣れが必要なのかもしれません。

よかったことも問題も感じないし何かするならすればいい、という場合が結構あります。

（それはそれで、特に問題なし、という意見でよいと思う）

毎回続けていくと徐々に意見が出てきていました。

それと「気づいた時にここに書いておいて」みたいなこともやりました。

これは言った時には効果がありました。しばらく経つと使われないシートが爆誕するだけなので、もしその方針で続けるならしつこく言い続ける、が必要そうでした。

あと、やたらしゃべる人がいるとみんなその人任せになってしまう、なんてこともありました。

この辺はファシリテーターの腕が必要かもしれません。