第1回「ヒンシツ大学 Evening Talk」 ”高橋寿一氏とアジャイルとテストを語ろう”
「テスターの半分以上の時間がテストケースを書いたり、メンテナンスする時間に費やされている。どうせ半分しかカバーできないテストの管理になぜそんなにコストを掛けるのか?」
2014-10-07 17:32:00998/1000件のTCパスしたところで、せいぜいカバレージは50%も行ってない。それで品質的な指標とは言えない。だったら、どうせ使われないTC書いてもしかたない。優秀なテスターでETやった方が意味ある。 #hindaiET
2014-10-07 17:33:18そもそもスクリプトベーステストで重要な障害なんてあまり見つからない。(寿一さんが計ったところによると)。また回帰テストでもそんなクリティカルなの見つからない。 #hindaiET
2014-10-07 17:37:30要求仕様は間違いというよりも、記述しきれてないものがバグになる。また往々して、要求仕様関連のバグは重大になりがち。要求仕様ベースでETを行うのではない。 #hindaiET
2014-10-07 17:39:23#hindaiET Exploratory Software Testing: James A. Whittaker: 洋書 : amazon.co.jp/Exploratory-So…
2014-10-07 17:41:32ETはいい加減ではないよ。ちゃんとstrategicな文書は書きます。どこのcomponentに対してどういう品質特性を定義するかが重要。 #hindaiET
2014-10-07 17:43:06「テストプロセスは1.製品の目的を明確にする、2.機能を明確にする、3.弱いエリアを叩く、4.テスト実行及びバグを記録、5.上記を継続的に実行する」
2014-10-07 17:45:27同意 RT @snsk: 経験と実感からしても、バグが出るのは「テストを考えてるまさにその時」と「テスト手順から少し脇にそれた時」なんだよなー。
2014-10-07 17:45:48まあ、極端な言い方をすればそうですけど、減らすことはできると僕は思っているんだな。RT @snsk: 「要求仕様の漏れを潰す、のは人間の想像力の限界を超えてしまう」
2014-10-07 17:47:17「ではその7%をどうやって見つけるか。さまざまな研究があるが、基本的には”たくさん変更されているファイル”、次に”長いファイル”」
2014-10-07 17:48:50ETでは弱いエリアを叩くことが重要。そもそも当たり前で皆が使うような機能の試験はやらない。理論的には継続開発では、7%のファイルかはすべてのバグが出る(しょっちゅう変えられているファイル、長いファイル)。Googleではこれをアルゴリズム化してレビューも集中 #hindaiET
2014-10-07 17:49:01これも極端な言い方。要求仕様どおりのテスト設計をしないことを指していて、要求仕様の周辺を漂うんだと思っているよ。 RT @snsk: 「探索的テストはハナから要求仕様なんて信じていない。要求仕様の漏れもキャッチすることをミッションとすることができる」
2014-10-07 17:50:10ETでの弱いエリアの見つけ方は、オーソドックスなやり方に加えて、James Whittakerの考え方も参考になる。 #hindaiET
2014-10-07 17:51:03「パワーポイントのInsertでは25x25がMAXだがそれ以上の入力をどうやって行うか。ソフトウェアは基本的に入力が弱い。そこを叩く。とウィタッカー先生は言っている」
2014-10-07 17:52:06