ホリスティック・テストについて

すこし前にMarkさんが書かれた記事を読んで、自分の場合はいつどんなことを考えているかな？と気になったので書き出してみました。

元記事の図2：開発ライフサイクルは8つのフェーズに分かれています。個人的には、だいたい2つずつに区切ると意識しやすかったので、その区切りで書いてみます。

DISCOVER & PLAN

これから何を作っていくか、ざっくり考えるタイミング。大まかな機能を考えて、デザインを詰めていって、ユーザーストーリーの単位まで詳細化する。このタイミングではユーザーのユースケースやデータパターンをいろいろ考えていて、何かしら例外的なことを考慮する必要があるかを考えています。代替パスとか。決まった仕様に対してテスト分析やテスト設計をするのではなく、テスト分析やテスト設計の考え方を使って仕様を考える感じ。あとで考えるべきことを、いま考えないように意識しています。チームで話してみて、「それはあとでもいいんじゃない？」となったらまたあと(の工程)で考えます。

UNDERSTAND & BUILD

ストーリー単位で開発をするタイミング。いわゆるATDDで開発しているので、最初に受け入れ基準を考えて、まずは自然言語で受け入れテストを作ります。このタイミングでは大まかな仕様は決まっているので、それに対してはテスト分析やテスト設計の考え方を使ってテストを組み立てます。逆に、これから考える部分(詳細な仕様)については、またテスト分析やテスト設計の考え方を使って仕様を考えます(ややこしい)。考えたテストは自動化して、あとはテストが通るように(プログラマーが)設計・実装します。実装を進めるなかで設計を見直すこともあるので、いちど書いた受け入れテストを直すこともあります。実装が終わったらパイプラインを流して、過去に書いたテストを含めてリグレッションテストが全部合格したらデプロイします。「考えたテストは自動化して」とさらっと書いたけど、これに結構エネルギーを使うせいか、他のことは考えられないです。自動化の実装をしている最中は視野が狭くなっている気がします。

DEPLOY & RELEASE

人間が、動くソフトウェアに対して動的テストができるのはこのタイミングから(厳密には実装中でもできるけど、ぼくは実装をしていないのでほぼ触りません)。このタイミングで、また例外的な方向に思考がいきます。追加で受け入れテストを書いた方がいいと気がつくこともあります。ただ、リリースしたい気持ちが結構強いタイミングでもあるので、意識的に冷静にならないと問題を見逃したりします。ここのあたりはもうちょっとうまくやりたい。

OBSERVE & LEARN

リリースしてから、自分たちでもソフトウェアを触ります。いわゆるドッグフーディングと言われていたりするやつ。作文を一晩寝かせると新たな気づきがあるのと同じく(？)、リリース後しばらくして問題に気づくこともあります。また、ビジネスサイドの人たちもドッグフーディングをしてくださるのでフィードバックをもらいます。少し時間差があって、実際のユーザーさんの声もいただくことがあります。これらのフィードバックが、次のDISCOVER & PLANにつながっていきます。個人的には、いろいろ視野を広げないと...と思いつつ、機能を細かいところでいろいろ触って問題を探す方向に意識がいってしまいます。

書き出してみた感想とか

開発を進める途中途中で、そのタイミングごとの不確実性というか、何がはっきりしていて何がはっきりしていないのかを見極めるのが難しいと感じています。そのとき必要なことだけを考える＆あと回しにしたことを忘れない、の両立も結構難しい。がんばります。