おすすめプレイリストの作り方
忍者式テストでおすすめテストスイートを作るアルゴリズムについてのメモ。
プレイリスト以前
バグもストーリーの同様に扱う、使ってみて気に入らないものもバグ（ストーリー）のように追加する、をやるので、実装の弱い部分、顧客の興味のある部分のチケットが自動的に厚くなるようになってるよ。
前準備
まず、チケットにテスト結果と、ステータス変更の履歴をつけておく。 ステータスの変更のうち、「機能追加や不具合修正などが終わって、試せるようになったよ！」を表すclose状態だけに興味があります。
1日一回やる
「1日に一回やる」を実現するにはテスト履歴の最後が24H以内のものはリストに表示しないぞ、ということである。 で、これは「次回実行するのはいつかを計算する関数」を作れば実装できる。チケットに対して「いつになったらテストしてほしい？」という問い合わせをする感じだ。
- closeされていない → 対象外
- 最後のcloseからテストの履歴がない → Time.new(1970, 1, 1) ≒ 大昔を表現できればなんでもいい
- 履歴がある → 最後の時刻 + 1 * 24H
この関数の結果をソートしてリストをつくる。関数の戻り値が現在時刻より前のものだけを選べばよい。
つまり最初の「1日に一回やる」を実現するために、この仕掛けは入っていた。
n日に一回やる
- closeされていない → 対象外
- 最後のcloseからテストの履歴がない → Time.new(1970, 1, 1)
- 履歴がある → 最後の時刻 + n * 24H
でよい。
私たちはdayが使いやすいけど、自動テストなどでdayよりも小さな単位でやりたいなら、24Hじゃなくて300secとかでもいいかもね。
チケットごとの調整がしたい
ここまでが基本形になる。nを全体で同じ値にせず、チケットごとに変えてもよいので、次のような調整も可能である
- なんどやってもOKのチケットの頻度を落としたいなら、最後のclose以降の連続するOKの数にしたがってnを大きくする。
- お気に入りの再生頻度を増やしたいなら、お気に入りはnを小さく、そうでないものはnを大きくする。（開発状況や製品のテーマで調整する）
全体の調整
自分たちは上記24Hに相当する全体の変数を使って調整できるようにしてはあるが、何年も調整してない。 20年分のあのグラフも発表用に作っただけで普段は全く見ない。前回見たのは2007年くらい。
今日やる分が終わらなかったらどうするか
気にしない。明日またリストされる。テストの消化ペースはあえて計測しない。なぜなら、消化することが目的ではないからだ。
それよりもまず
そう簡単に1日で全部テストできない！ってことは起きないんじゃないだろうか。まずは全部触りなー。
