2
ぱいん🍍 @pineapplecandy
テストエンジニアに質問) BackEndがユニットテストを書いてくれないときに、あなたならどう説得しますか?
K_Suzuki @keigo1450
@pineapplecandy 書かない理由も色々ありうるので何とも言えないですが、自分なら「(ユニットテストレベルの動作確認を)人が毎回時間かけてやるなんて馬鹿らしくないですか?」とかですかねぇ…。 「カバレッジ100%にしたい訳じゃないので、相談させてくれませんか?」とか。
ゆふ@仕事系 @yufu69
@pineapplecandy UTより後のバグチケットとかを一緒に見つつ 「コレとかアレって、実はUT段階で除去れるくないですか!? そーすれば、こんな『後になってバグ報告されて不確実情報も多い中でデバッグする』より めっちゃ楽くないですか!?」 みたいな感じで誘惑します
acchan @feb_acchan
@pineapplecandy ライオンスタンドのSSだす(笑) 真面目なところだとバグの傾向次第で説得するだけなのでバグがなければ説得しません。 この時代、デバッグしないで開発とかしてないでしょうし。
Mark Ward @mkwrd
@pineapplecandy 品質はソフトウェアだけのものではないという点から、品質文化醸成のための活動(わかりやすいスライドでプレゼン、社内報寄稿等)を開発部署だけでなく業務部署を含めた全社に向けて継続して行い、その中で実際のバグ数や分類を示し、単体テストは品質を高めるために大事なんだよってアピールします。
ぱいん🍍 @pineapplecandy
@mkwrd そこからかあー、流石です。
Mark Ward @mkwrd
@pineapplecandy そこからやらないと、自分がいなくなった時に何も残りませんからねぇ。事業会社の自社QAエンジニアだからこそできる戦い方かもしれまへん。
しましま(偽) @shimashima35
@pineapplecandy バグ票があれば、その中からユニットテストでとれたものを調べてコスト算出とかですかね。早期発見の方がコストは安くなるので。 弊社はユニットテスト書いていますが、いま私が各種施策導入する際には「まずデータ」で始めています。
おれたま @AHA_oretama
@pineapplecandy BackEndチームにジョインしてユニットテスト環境、CI環境の整備をして、自分が率先してユニットテストを書いて周りの人に真似してもらう。 経験上、ユニットテストは書かないのではなく、書けない環境にいることが多いので。 単純にユニットテストを書かない人ならチームから抜けてもらいますね。
しましま(偽) @shimashima35
@pineapplecandy @mkwrd 自分で書いておいてなんなんですが、この理屈で行くと単体テストよりもレビューを重視した方がよくなるのですよね。 単体テストでとれるバグは実のところ大して多くないはずで、どちらかというとデグレード防止の方が大きい気がします。
しましま(偽) @shimashima35
@pineapplecandy @mkwrd 一般論であればバリー・ベーム氏かケーパーズ・ジョーンズ氏のデータがあります。
こばせ🥴 @kobase555
@pineapplecandy よくありそうですね だとしたら、「テスト書いてー」より「テストしてー」の文脈のほうが近そう
acchan @feb_acchan
@pineapplecandy 書かないならそんな感じ。 ただし理解を得られたとして、そもそも書けないなら書けるように環境やフレームワークの改良を一緒にやるって感じですかね
ぱいん🍍 @pineapplecandy
@shimashima35 @mkwrd Boehmは知っていましたが、Jonesのグラフあるんですね、これは分かりやすい。ありがとうございます。 deanondelivery.com/product-manage…
リンク Medium Product Managers, do you know how much your bugs cost? Not knowing the cost of bugs is about as wise as learning to juggle using chainsaws. Sure, you learn from your mistakes, but at what cost?

コメント

コメントがまだありません。感想を最初に伝えてみませんか?

ログインして広告を非表示にする
ログインして広告を非表示にする