読者です 読者をやめる 読者になる 読者になる

Create a new world

きっと誰もが新しい世界を作り続けているんだよ。

12.10 Agile Day 4 アジャイルでのテストを考える

Microsoftセミナールームで行われた、Agile Day 4 の中から、マインドマップでメモれたTIS近江さんの講演内容をば。

・なぜテストを行うのか。目的別に分けてみると、不具合の発見・リリース出来るかの確認があります。
でも、リリース出来るかのテストはスピードとコストが絡んできます。

・どうやってテストを進めましょう?
開発中はTDDをやったり、不具合を見つけるようにしたり。
リリース前には、リリース出来るか判定する材料としてのテストをします。この時仕様やプログラムは変更しません。

・必要なものはドキュメント化しましょう。
アジャイルでも、必要ならドキュメントは残しましょう。テストの際に仕様を俯瞰したり、コミュニケーションの材料になります。ドキュメントがないとだめだったり、あると機敏に仕事できる場合は用意しておかないと。

・仕様変更などに対応するために
見直すタイミングを作りましょう。仕様変更に対応出来るかを考えたり、現状に合わせる機会に使いましょう。
タイミングには反復内での何かのタスクを終えたときなどに行います。新しいやりかたや新しいツールは次の反復以降で行うようにしましょう。

コミュニケーションを増やしましょう。打ち合わせやペア作業、WikiBTSなど、多様なやりとりの場を設けましょう。
テスターがデモに参加するのも大事です。デモの際に出た要求をすぐ実現出来るか想定テスト量などから判断して、その場で調整したりできますよ。
また、設計やプログラミングの担当者とペアでテストして、その場で認識合わせをしたり、細かい仕様のチェックをするなどできますよね。

アジャイル開発プロジェクトでテスターをやって継続したいこと
状況が違う場合、他に工夫することができるな。アジャイルであることを活かしたいな。変化が起きることを利用して、最新状況を反映させたり、テストに役立たせたり。ふりかえりも。
そして、この経験はアジャイルでなくても、同じ状況だったら適用できるのでは?

・いろいろ考える足がかりにしていきましょう!

といった感じでした。

感想としては、アジャイルでもウォーターフォールでも、基本は変わらないんかなと。でも、アジャイルであれば、開発の最後に行うのではなく、毎回のイテレーション内でチェックしていくのだから、早い段階で不具合の発見なんかは出来るし、お客様との認識を合わせていけるのは、やっぱりいいなと。
そして、必要ならドキュメント化するのも大事というとこもミソ。ただ、これもBTSなどで管理して、必要に応じて出力する。それでは足りない場合は、手作業でドキュメント作るなどすればいいのかなと思いました。

あと、近江さんに「見直しをした結果の反映はどこでやったらいいの?」という質問をして、今反復内で出来ることは今反復内で、それが出来ない場合は、次以降の反復で行うようにしました。という話を聞きました。

(12.14 近江さんから頂いたフィードバックをもとに、一部修正しました。変更点は下の近江さんのコメントにあります。)