しまった写真取り忘れてた。
どの方もとても良い講演でした。
ライブテスティングって何だろうと思ったら実況中継みたいな感じなんですね。名キャスティングで楽しめました。
ツイートしましたが、LTで発表していただいた方々もLTじゃなくて１セッションとして今度聞いてみたいです。本当に。
来年も開催されるということなので、次は登壇する側になれるようネタを仕込んでおきたいなぁと思います。TDD とかとか。
以下、今日知ったことをまとめておきます。
Astah* で状態遷移モデルから自動で試験項目を作れる
残念ながら Professional 以上でしか利用できないようなので、今使うことは出来ないかな…
1024パターンのテストを9パターンにする
原因結果グラフ。たとえば音楽再生時に着信して一時停止した場合に使用する。本当に５年前知っていればよかった。
テストについて経営層・マネージャに３つ抑えておいてほしいことは３つ
- テストは欠陥があることしか示せない。バグ０を強要するお客様とはおつきあいを考えて欲しい。
- 全数テストは不可能。「いいから全部やれ」は勘弁。テスト技法を用いてテスト数を間引くこと。指示する人は全部のサイズを理解していないことが多いので確認すること
- テストは条件次第。「有人宇宙ロケット」「プロモーション限定スマフォアプリ」ではドメインが違う
Selenium と Jenkins で自動化
Selenium IDE で記録したテストは、Jenkins で自動化できて、IE等でも実行できる。前に IDE で記録したテストを WebDriver で書き直そうとしたけどナンセンスっぽい。
メトリクスは一つの指標に過ぎない
たとえば信頼度成長曲線だけ見ても、テストがクソなのかソフトが良いのか判断がつかない。同じプロジェクト・同じ人であれば、過去の実績から判断がつくが、ソフトウェア開発で同じ条件になることは考えづらい。
じゃぁ、どうするかというと判断材料の一つであって、それだけ信じてもしょうが無い。自分たちが何をどうやってなんでテストしたかが重要。お客様に説明できるか？
