今日は@Yuko_skiさん主催の通称"テスコラ"に初めて参加してみますた。
理由は"統合テスト"についての取り組みをしているから。
"統合テスト"は僕がテスト人生をかけて取り組もうと思っていたテーマだったので
ものすんごく興味があった。
◆統合テストって難しいんですよね
"統合テスト"ってなんぞ、とゆー説明自体もかなり難しくって、
単体テストとシステムテストの間にやるテスト、というのが
いちばんしっくりくるかなぁと思っている。
最近はシステムオブシステムズとか色々あるじゃないですか。
あれもシステムテストってどこやねん、的な定義が難しかったり
ソリューションとか言われたりしてたり。
一体どこまでが単体/ユニット/コンポーネントだったりすんねん、とか。
んで、単体じゃないから統合だよね、とかなるんですけど
その粒度はホントに様々なんですね。
かの「バリ本」にも難しいって書いてあった気がします。←記憶が定かでないですが。
◆言葉の定義はわかるけど、なんで難しいの？
で、なんで難しいかというと、
@mkoszkさんのエントリがわかりやすく表現してあります。
http://d.hatena.ne.jp/mkoszk/20110103/p2
縦も横も考えるんだけど、作りだけでなく使われ方まで考えないと
うまくテストできないんですよね。
で、もちろんインターフェースだけに注目しても「いいテスト」にはならない。
※このあたりは用語の定義に反するのですが、そう主張する。
僕は業務で「統合テスト」のあたりを扱って8年ほど経ちます。
思えば「なんとなくプログラムも書いてるし、テストもわかるし」みたいな感じで
入ってみたのが運のつき。
大き目のシステムから小さめのシステムの統合テストみたいなものまで。
時には機能間の結合を見たり、時にはプロトコルのログとにらめっこしたり。
そんな感じで幅広い経験をさせていただいていて
めちゃくちゃ面白いところだと思っている。
早めに欠陥を見つければ修正コストも早いよね、と思って頑張ったりする。
さらに会社の基準とかでも、かなりのバグ抽出カバレッジを求められたりする。
◆でも統合テストってヤツは。
そんなニクいヤツ"統合テスト"ですが、
実際に事例とか"統合テスト"といえばこう！みたいなものって実は確立されていません。
※僕が知らないだけかもですが。
まぁ僕が思っているだいたいの理由は単純で。
「人間の感覚」の度合いが強いんですね。
だから方法論として確立するのが非常に難しい。
これはテスト全般に言えることだったりするんですけど
特に"統合テスト"というフェーズはそれの度合いが強い。
人と人との意志疎通であったり、認識のズレであったり
人が何かを作るときに思いついた「思いつき」であったり
そういった事とガチで向き合うテストなんですね。
しかもテスターらしく外からそれを見ないといけない。
※この感覚わかるかなぁ＾＾；
いわゆる"アジャイルテスター"みたいなことをする必要がある。
特に最近のご時世はひどくって、
高品質短納期が求められるくせに
システムオブシステムズで「機能ってなんだっけ？」とかいう状態なので
直接PMやら開発リーダーに話を聞いたりしてコミュニケーションをよくしないと何も解決しない。
仕様書がないことすらある"統合テスト"では、コミュニケーションやら
見える化などが絶対条件で必要になるんですね。
で。これを楽にしたいんですね。
そしたら皆ハッピーじゃん、と。
◆話は戻ってテスコラ。
でまぁ、テスコラに参加してみました。(前置き長ッ)
今日は今までのおさらいとどんな感じで進めようかねー、という話をしたのですが
その最中でも色々な議論ができて楽しかった。
で、今日感じたのは、
・「要求」には「現在のリアルから求められるもの」と「外部から求められるもの」があるということ。
・テストを引き受けるときに「この製品のコンセプトはなに？企画書プリーズ」という僕は
割と異端なのかもしれないということ。
※誰からも反応がなかったので、反論が無いのか、ポカーンとされたのか
どっちかよくわからないのだけれども。
そんな感じス。
