常に行う「アクティビティ」としてのテスト
講演の始めに、ブロッコリー氏は「機能開発はしたものの、本当にユーザーの課題解決につながっているのか不安になったことはありませんか」と聴衆に問いかけた。
プロダクトを開発するにあたり、エンジニアはつい、こなしたタスクやリリースの多さというアウトプット量を意識してしまいがちだ。しかし、本当に重要なのはユーザーの課題解決や行動変容、すなわちアウトカムである。冒頭の質問はこのようなズレから発されたものだが、覚えがあるオーディエンスが多いのか、会場では多くの手が挙がった。
会場の反応を確認したブロッコリー氏は、講演を通した主張として、「エンジニアは、一般的な『テストの完了』をゴールに置くべきではない」と説く。一般にテストはコードをマージしてビルドする際に行うものという認識を持たれることが多いが、アウトカムを重視した立ち回りをするのであれば、コード実装前（シフトレフト）やリリース後（シフトライト）のテストも重視すべきだと言うのだ。「テストはもはやフェーズではなく、常に行っていくアクティビティ（活動）」。そんなブロッコリー氏の考えを表したのが、以下に示す「継続的テストモデル」だ。
本日のテーマを確認したところで、話は実践例に移る。ブロッコリー氏は10Xにおけるシフトライト・レフトの具体的な活動を紹介する前に、コンテクストを合わせるため同社の事業を簡単に紹介した。10XではStailerという小売・流通事業者向けのECプラットフォームを開発しており、ユーザー向けのアプリだけでなく、注文後にスタッフがピッキングやパッキングを行って配達するまで、一連の業務管理を担う店舗アプリ開発も行っている。
今回の講演では、このアプリにおけるピッキング・パッキングに着目する。たとえばネットスーパーにおいては、ユーザーAから牛乳2本・ユーザーBから3本という注文が入った場合でも、すぐに個数を確定させることはない。ときにはユーザーが考えを変え、注文をキャンセルする可能性もあるためだ。
そのため裏側のシステムには、オーダー後の変更締め切り時間が設けられている。これを過ぎると発注内容が確定し、店舗スタッフが5本の牛乳を実際の店舗内の陳列からピックアップ（ピッキング）する流れだ。あとはこれらをバックヤードに持ち込み、バーコードを読み込んだ後、注文ごとに商品を梱包（パッキング）して配達することになる。このオペレーションについて、どのようなテストが可能だろうか。
まずシフトレフトについては、TDD（テスト駆動開発）よりもさらに前段階である、プランやブランチの段階でもテスト活動が可能だという。これは受け入れ基準（タスクチケットの完了基準）を作成する際の活動であり、とくにスクラムにおけるリファインメントの部分で行うものだ。なお10Xの場合、リファインメントは開発者だけでなく、POのようなビジネス関係者とQAの3者で協調しながら進める3amigosという考え方を用いる場合がある。
先ほどのオペレーションについては、もともと「hogehogeメソッドが注文の締め切り時間の前に呼ばれているので対応する」という受け入れ基準が定義されていた。それに対してQAであるブロッコリー氏は、リファインメントの場で「コードの内容は分かった。でも、これはアプリの振る舞いでいうと、どの画面をどう操作したときに発生するんだろう」と疑念を投げかけた。
そうして調査を進めると、「注文確定前の段階にもかかわらずピッキングを終わらせてパッキングまで進んだ場合、完了ボタンを押すとエラーになり、前画面に戻る」というものだとわかった。また「完了ボタンを押さずとも、その画面で15秒放置した場合もエラーを返す」という振る舞いを行うことも判明した。
ブロッコリー氏は「このように書くと、何をもってこのタスクが『完了』になるのかがはっきりする。特に15秒放置するケースは、最初の『hogehogeメソッドの〜』という記述だけではよく分からなかったかもしれない」と振り返る。また余談として、「今回のように早い段階で行うべきことをはっきりしていると、そもそもバグが作られずに済むため追加コストが不要になる」と、副産物も示した。
