-
pineapplecandy
- 827
- 2
- 0
- 0

@pineapplecandy 書かない理由も色々ありうるので何とも言えないですが、自分なら「(ユニットテストレベルの動作確認を)人が毎回時間かけてやるなんて馬鹿らしくないですか?」とかですかねぇ…。 「カバレッジ100%にしたい訳じゃないので、相談させてくれませんか?」とか。
2019-07-12 21:20:43
@pineapplecandy UTより後のバグチケットとかを一緒に見つつ 「コレとかアレって、実はUT段階で除去れるくないですか!? そーすれば、こんな『後になってバグ報告されて不確実情報も多い中でデバッグする』より めっちゃ楽くないですか!?」 みたいな感じで誘惑します
2019-07-12 21:26:03
@pineapplecandy ライオンスタンドのSSだす(笑) 真面目なところだとバグの傾向次第で説得するだけなのでバグがなければ説得しません。 この時代、デバッグしないで開発とかしてないでしょうし。
2019-07-12 23:07:09
@pineapplecandy 品質はソフトウェアだけのものではないという点から、品質文化醸成のための活動(わかりやすいスライドでプレゼン、社内報寄稿等)を開発部署だけでなく業務部署を含めた全社に向けて継続して行い、その中で実際のバグ数や分類を示し、単体テストは品質を高めるために大事なんだよってアピールします。
2019-07-13 03:14:46
@pineapplecandy そこからやらないと、自分がいなくなった時に何も残りませんからねぇ。事業会社の自社QAエンジニアだからこそできる戦い方かもしれまへん。
2019-07-13 15:57:37
@pineapplecandy バグ票があれば、その中からユニットテストでとれたものを調べてコスト算出とかですかね。早期発見の方がコストは安くなるので。 弊社はユニットテスト書いていますが、いま私が各種施策導入する際には「まずデータ」で始めています。
2019-07-13 14:28:07
@pineapplecandy BackEndチームにジョインしてユニットテスト環境、CI環境の整備をして、自分が率先してユニットテストを書いて周りの人に真似してもらう。 経験上、ユニットテストは書かないのではなく、書けない環境にいることが多いので。 単純にユニットテストを書かない人ならチームから抜けてもらいますね。
2019-07-13 14:29:04
@pineapplecandy @mkwrd 自分で書いておいてなんなんですが、この理屈で行くと単体テストよりもレビューを重視した方がよくなるのですよね。 単体テストでとれるバグは実のところ大して多くないはずで、どちらかというとデグレード防止の方が大きい気がします。
2019-07-13 22:13:40
@pineapplecandy @mkwrd 一般論であればバリー・ベーム氏かケーパーズ・ジョーンズ氏のデータがあります。
2019-07-13 20:39:21
@pineapplecandy 書かないならそんな感じ。 ただし理解を得られたとして、そもそも書けないなら書けるように環境やフレームワークの改良を一緒にやるって感じですかね
2019-07-13 16:42:54
@shimashima35 @mkwrd Boehmは知っていましたが、Jonesのグラフあるんですね、これは分かりやすい。ありがとうございます。 deanondelivery.com/product-manage…
2019-07-13 22:41:30