各種リリース
- PHPUnit Patch version (maintenance release)
- RabbitMQ patch version (maintenance release)
- いつもの「npm のバージョン更新」と「V8 のバージョン更新」
- AsyncLocalStorage API の stability が上がった
ニュースとか
InfoQ の記事で原文の Feed も購読し始めたので、たぶん来週あたりから取り入れられてくると思う。
「品質の左シフト」という言葉が流行ってるらしい？
『テストピラミッドを使って品質を左シフトする』という、2 月にニューヨークで開催された「ConTEST 2021」での講演のひとつを元に書かれた記事があった。
要するに「設計に対するテストは設計をした段階でやれ」って話。
根本的な原因は「アジャイル開発の思想を理解せずに手法だけとりいれ、形骸化している」みたいなところにあったりするのだけれど、その中でもっとも悪い結果を招くのがテスト関連の思想の欠落なわけ。
アジャイルの中でももっともシンプルな XP（エクストリーム・プログラミング）あたりをちゃんと理解していれば、テストを後回しにするのは論外なことがわかって当然なのだけれど、そのへんをわかってない人は結構多いらしい。
実際に「QA のみによるテストから開発者による e2e テストに移行」してみた話が 開発者が E2E テストを書くことで得たもの。
開発全体としては「プログラマが E2E も書いたほうが良い」のだけれど、現実的な問題として「QA チームに仕事を取られた感を与えてしまう」「開発者がやりたいことはコーディング」みたいなものがあって、じゃあどうするかって話があった。
この記事の中では、
- 望むなら、QA エンジニアにも E2E テストを書き続けてもラう
- プログラマにテストを書く時間を提供する
- 開発者用にテストシナリオの設計と改善をする
- 教育する
- テストに冠する優れたプロセスを構築する
- プログラマにはコーディングをさせる（E2E を書かせるのはよいが、本業をおろそかにさせるな）
あたりに気をつけろ、となっていた。
開発者が E2E テストを行う上での秘訣
- 設計カバレッジ；設計に対して E2E で 50% はカバーする
- 各テストケースは短く簡潔に実装する
- テストでは常に “常用” を念頭に置く
- カバレッジを分析して、時間をかけて改善する
- 教える
- レビューでは、まずはじめにテストをレビューする
- ベストプラクティスを作る
- 自分なりにやり方を考えておく；例えばバグでテストが落ちたときにどうするか
- マインドセットを変える；開発するときとテストを書くときは考え方が根本的に違う（はずなのでってことだと思う）
- ひとつの “良いテスト” から始める
- 習慣にする
- 数値を出す