自動テスト結果のドキュメント化できれば受け入れられやすい？
四の五の言わずにとっととやれ、というご意見はごもっともですがｗ
テストの自動化という記事を読んで、そう思い付いたのを思い出したので、つらつらと書きます。
メモです。僕以外の誰が読んでも面白く有りません。
テストの自動化
って、そんなことないですよ。
テスト実行毎にテスト結果をDBに格納、任意の時点でのテスト結果をみんなが大好きなExcel形式でレポート化できれば、みんなに受け入れられやすいんじゃないかと。そうじゃなくても、何らかのレポートの形でテスト結果は必要になるだろうし、テスト自動化業界でそういう方面の検討ってどのくらい進んでるんでしょうか。
エビ的には、最終実行のテスト結果をエビデンスとして問題ないはずです。論理的には。
もちろん、テストケースのコードをベースに議論する文化になればまったく問題ないわけですが。
同じ結果で工数が減るのは良いことです！！と声高に主張したいです。
自動化したテストだろうがExcel化したテストだろうが、テスト項目に矛盾や漏れがあれば即ち不具合は起こり得るわけで、テストケースに対するレビューを以ってそれを仕様と定めてしまうくらいの決め事はしてもいいんじゃないかと思っています。要するに、テストケースに書いてないことに対するシステムの挙動は不定。「不定じゃ駄目だろ」なら、その「駄目な部分」のテストケースを増やしてくださいということで。
ん？…ということはもしかして、テストケースの数で大まかなシステム規模…というか見積り金額も決めれるかも。発注者/管理者はテストケースを増やして不定な動作を排除したいが、テストケースが増えると見積もり金額が増える。作る側にとっては当たり前のトレードオフを、頼む側に転嫁できる方法の一つになりそうな気がします。ので、誰かやってみてくださいｗ
少し話題を戻すと、TDDの正統な思想がどの辺りにあるかよくわからないけど、eclipseのjUnitプラグインの挙動によると、テスト対象としてクラスメソッドを強く意識してることは確か。それに対してBDDの思想は比較的ブラックボックステストなので、ボックスの大きさを変えることで超概要のテストから、メソッド単位のテストまでが一応可能になってる。結果的にやることは変わらずに使い方が違うだけなんだけど、この差ってでかくないですか？
だからお前ら、BDDでいこーよ。なんて思っていますので、TDDすら導入できていない自社で試してみようと画策中です。
ちなみに、バグ収束曲線とかの統計的手法で「品質に問題はない」とする文化はまったく的外れなので、いい加減にやめにした方がいいです。"+ offset"のプログラムミスを統計的手法で排除できる根拠は皆無です。
って、引用元記事では「まとめ」として
また、いざと言うときのためにユニットテストからテスト仕様書を起こせるような、ハックを作っておければ尚可。（これしたいんだけど、なぜかまだやっていない。）
テストの自動化
と書いてあったｗｗ。考えることはみんな同じですね。
あぁ実行力…。
