「テストからはじめよ」～忍者式テスト20年の実践から～

忍者式テスト

受け入れテストのレイヤーでTDDのようなものをやるやつ

たしかに「どう試せばユーザーの困りを解決できたと言えるか」とかはよいね

なるほど、チケットにすべてを書くのか

開発日記ね

毎朝1hぐらいやってるらしい、マジか

結構長くね？って言われそう

バグもストーリーとして扱う

実際複数イテレーション開発を回して最後に検証するというやつ、どんくらいの期間になるんでしょうね？

ストーリーが複数のタスクで構成されている => 長くなりがち

ストーリーを試すまでが長い

Story自体を短くする

システムで試せる一番小さな変化は何か？

なんか話を聞いていると「そのへんは自然にやってそう？」みたいなところはあるな

コンポーネント単体で作ってどこにもおかない、みたいなのはあんまりないかも

現状で言うとフロントエンドはStorybookがいるのでそれで試せたりする

ストーリーを搭載しても既存が壊れない

Storyの分割とか順序がイケてないかも

試し方が思いつかないとか

ストーリーが完成しないとか

自然にこれまでのストーリーも確認する感じになる

例えばボタンを置いてからのモーダルが出る→空のモーダルの中身の実装とすると、中身の実装を試す際に1つ目のストーリーは確認できている

実際すべての最後に結合する、ってスタイル全然想像がつかない…

そうしたことがなかったので

バグを見つけたらストーリーを止めて原因究明する

チームのキャパは一定である

例えばバグがめっちゃ多い場合は扱ってるストーリーが多いんじゃねとか

調速装置といっていた

イテレーションがきれいに揃うことよりは、早く確認できることのほうが大事である

なのでペースが違うことはそこまで深刻にとらえなくていい

全てを試すのは開発が長くなればなるほど無理なのでは？

ある期間でテストケースを試すように

まんべんなくかつ効果の高いものを抽出