フルスタックエンジニアから「フルサイクルエンジニア」へ。和田卓人氏による「組織に自動テストを根付かせる戦略」（その3）。ソフトウェア品質シンポジウム2022 － Publickey

「コスト削減のためにテスト自動化をしないほうがよい」
というのなるほどだなあ。なんでコストを減らしたいんだっけ？というのを自答する必要がありそう。

「フルサイクルエンジニア」の記事はこれか。

重要なキーワード多くて良きでした。ただ、すぐtryできるようなハウツーじゃないので心構えだったり戦略立てする時の一つの指針にすると良さそう
フルスタックエンジニアから「フルサイクルエンジニア」へ。和田卓人氏による「組織に自動テストを根付かせる戦略」（その3）。

わかりみがふかい
E2Eに向かいがち問題、あると思います

アンチパターン「買ってきた自動テスト」

コスト削減ドリブンの自動テストだと月1のリリース前とかしか実行してもらえなくて、
結果メンテナンス難易度が余計上がるしコスパも出なくてうまくいかない、という例ならE2Eでたくさん見た。

>いろんなスキルを持ってるエンジニアのことを「フルスタックエンジニア」と言いますが、最近ではフルスタックではなくて「フルサイクルエンジニア」が大事です。

まったく開発に携わってないやつのテストコード書いてくれって言われててこれ最近読んだアンチパターンのやつだなと思うなどした

ためになる話でした
身近だとそもそもサイクルが止まって放置されちゃうパターンが多いかも

先生の話はこれ

フルスタックよりフルサイクルであること。開発スピードと品質は両立する。

自分はこれまで開発者自身が実装とセットでテストコードを書いて当然の文化に浸かってたけど、それでもなお興味深いお話でした。

「ソフトウェア開発というのは基本的に、既知と未知の陣取り合戦です。未知の世界をどれだけ削り取って、既知の状態に取り入れ、既知の状態の砦をどれだけ広く取っていけるか」

"QAチーム、つまり開発チームとは別に存在する品質保証チーム、あるいは外部委託先が作成管理している自動テストは、企業の業績と相関関係にない、と判明したということです"

自動テストへの動機というものはコスト削減ではなくて、変化についていきたいから、ですよね。

↑ビジネスのサイクルを回しやすくするために設計があるし、テストがあるっていつ認識

後半の記事もよかった。

t-wadaさんの最新作。

あとでちゃんと読む

QAチーム、つまり開発チームとは別に存在する品質保証チーム、あるいは外部委託先が作成管理している自動テストは、企業の業績と相関関係にない、と判明したということです。

Lean と DevOps の科学読んでる途中だけどそうなんだ

保守で変更する時、既存コードのテストが存在しないと怖いね。影響調査しきれないから

"自動テストは既に分かっているものが、今もその通りである、ということを高速に確かめる最強の手段の一つです。既知を既知のままにし続ける。"

・継続的デリバリーの5つの基本原則
・継続的デリバリーの3つの技術的な基盤
_φ(･_･

読んでる。

「1日は流石にないだろ〜」と思ってたら、自動テスト導入による損益分岐点が1時間ぐらいで来るのを実感してしまったがために、自動UTが無いと生きていけない体になってしまった

おもろい

企業ITに関わる人みんなに読んでほしい /

"フルサイクルエンジニア"というのがあるのですね。