2011年12月15日木曜日

統合テストの分類について #swtestadvent2011


@takanorigさんのお声がけによる
"Software Test & Quality Advent Calendar"の12/16版エントリです。

12/15は@shuji_w6eさんのエントリでした。
-----

明日からWACATE 2011 冬なのですが、ドタバタする前に上げておくことにします。
WACATEに興味のおありの方は是非、オフィシャルサイトや
MagazineManiaXなどで雰囲気を感じていただければ幸甚です。
-----
さて。たまたま書き貯めていたネタを投下させていただくことにする。
ニセコでミッキーさんとお話をしたときに考えたというか気づかされたことなど。

わたくしコヤマンは「統合テスト屋さん」を自称している。
で、その統合テストってなんぞ?というお話。

◆◆◆統合テストとは。
組織によって名称が異なるが、
・「結合テスト」
・「連結テスト」
・「インターフェーステスト」
・「インテグレーションテスト」
・「サブシステムテスト」
・「コンポーネント統合テスト」
・「システム統合テスト」
などと呼ばれるものの総称である。
明確な方法論が存在しないと言われており、組織によってさまざまな実施形態があるため、定義も困難になっていると思われる。
個人的にもっと整理しようと思っている領域である。

◆◆◆定義
ここは鉄板、JSTQB用語集(JSTQB-glossary.V2.0.J02)を見てみよう。

引用-----
●統合テスト(integration testing):
統合したコンポーネントやシステムのインターフェースや
相互作用の欠陥を摘出するためのテスト。
component integration testingおよび
system integration testingも参照のこと。
-----
参照先は以下。

引用-----
●コンポーネント統合テスト(component integration testing):
統合したコンポーネント間のインターフェースや相互作用の欠陥を検出するためのテスト

●システム統合テスト(system integration testing):
システムとパッケージを統合するテスト。また、外部システム(たとえば
電子データ交換やインターネット)とのインターフェースのテスト
-----
まぁ、塊をくっつけたときにするテストなのね、というのはご理解いただけるかと思う。
ちなみに統合テストについては、以下のURLに詳しい説明がある。


布川さんの連載には最上階は「システム」であると記載がされているが、ここ最近では「システムオブシステムズ」や「ソリューション」といった概念が出てきており統合テストの範囲は年々広がっていると言える。

つまり、以下のような粒度があると言える。
○コンポーネント間統合
○サブシステム間統合
○システム間統合

ちなみに、筆者は全ての粒度が担当であったりする。
※現在はシステム間統合が多めだが、基板上の通信内容を冶具を使って採取してProtocol Analyzerにかけたり、モジュール間の通信Logの内容の解析をしたりもするし、単にシステムの動作について確認したりなどもしている。

では、その中でどのようなテストをやっているのか、の話に移ろう。

◆◆◆統合テストの分類
今のところ、ざっくり統合テストというと以下の分類が存在する。

◆◆範囲の分類
○インターフェースに特化したテスト
・「連結」テストと呼ばれることもある。
・インターフェースのプロトコルやメッセージのやりとりに特化したテスト。
シーケンス図等を使ってやりとりが正しいことや有り得ないパターンの通信を受けたときの動作が妥当なものかどうかを評価するテスト
※とあるモジュールが出した命令を受けて、期待どおりに次のモジュールが動くこと、正しい通信を返すこと、といった点が主な焦点になる。
★結合することをテストする。

○サブシステムやシステムを結合した状態でのブラックボックステスト
・いわゆる「結合」テスト。
・既に「現在の対象が外部にリリースする単位」(=これを単体と定義する)では内部のテストが終了しており
 他のモジュールとの連動や
 組み合わせによって表現される機能に対してのテストを行う。
※要求から一つ一つブレイクダウンした「実現方法」が主な焦点になる。
★結合した状態の動作をテストする。

この結合テストでいう単位というのがテストレベルになったりする。
組織によっては細分化されたり、丸められたりする。
品質を厳しく見る組織では、細分化されたり、まったく違う軸のテストが定義されたりもする。

◆◆実施方法の分類
○トップダウンテスト
いわゆるスタブを使ったテスト。
モジュール構造において下位にあたるモジュールを仮に生成して上位モジュールから呼び出してテストをする。
・メインモジュールやモジュール間インターフェースに対して早めの段階でテストが可能になる。
・下位モジュールのテスト時にも上位モジュールのテストになるため潜在バグを発見しやすい
といった長所があるが、
・開発の初期の頃には、テストしながらの開発が難しい
・スタブの作成が割と難しい
といった短所がある。

○ボトムアップテスト
いわゆるドライバを使ったテスト。
モジュール構造において、上位にあたるモジュールを仮生成して下位モジュールから呼び出してテストをする。
・テストケースの作成や結果のチェックが容易。
・開発の初期からテストしながらの開発がしやすい
といった長所があるが
・最終的に接続した際に、インターフェースのバグがあったりすると修正量が多くなってしまう
といった短所がある。

◆◆◆特徴
統合テストとして特徴的なのは、スケジュールや対象物、環境によって
これらのパターンがコロコロと変わることである。

例えばスタブとなるシミュレータがあらかじめ用意されている環境では
トップダウンの方式を取ることがあり、納期が非常に厳しい対象であったりすると
ボトムアップの方式を取ることがある。

なので、最近はボトムアップが多い気がする。なので最終的に(ry

また、基本的にはがっつり開発中だったりするので、
・テスト期間中だが仕様が定まらずドキュメントが無い
・仕様がコロコロ変わる
・連結先の都合で止まる
・シミュレータのバグに翻弄される
・要求が変わる
・スケジュールが無い
といったことが当然のように発生する。
まぁ、上記は統合テストに限ったことではないが、より発生しやすい、と認識いただければ幸いである。

◆◆◆まとめ
統合テストの厄介なところはコンテキストが合わないことが多いところだと思う。

粒度も範囲も実施方法も色々な方法があるというところではないかと感じている。
またこれが組織によって(会社の中ですら)まちまちであったり、妥協の産物がごろごろしていたりなどする。
結合テストや統合テストといっても、どのイメージで話をしているかについては事前に話し、コンテキストを合わせた方がよいだろう。
その中でいくつかの分類を紹介したので、皆さん自身でマッピングしていただければ幸いである。

統合テストをしている人は
もしかしたらプロトコルのインターフェースを見ているかも知れないし、
システム間のデータのやりとりを見ているかも知れないし
ある値を与えられたときの関数の振る舞いと見ているかも知れないし、
ある操作をしたときの機械の動作を見ているかも知れない。

これらを整理したうえで、統合テストの方法論をみんなで構築できたら素晴らしいと考えている。

2011年10月13日木曜日

僕はこんなことを考えている。(テストの視点の話)

-ちょっと修正:2011/10/18
風使いになりたい。
暑いときには扇風機がわりにできるし
寒いときは温かい空気を送ったりできるし、
刃物もカマイタチがあればいいし、走るときはいつも追い風だ。
そして何より「神風の術」が使える。スンバラシイ。


ども。コヤマンです。


なんだかドタバタしていたけれど、少し落ち着いてきたので考えていることなどを簡単に書き出してみる。

テストの視点の話。

大雑把な書き方なので何を言いたいのかよくわからないと思いますが、
僕がテストを考えるときに何を考えているのか、という"視点"を大雑把に出してみた。


  • モノ
  • コト
  • ドメイン(背景など、対象を取り巻く世界)
こんだけ。んで、これって何かモノを作るときと全く同じだよなーと思った。
モノを作るとき、同じことを考える。
※もちろんこれは僕の個人的意見に過ぎないので、異論はあるかと思う。
 なるほど、テストを開発する、と考えると

 「何かを作る」ときに共通に使える概念かもしれない。

では話を戻して、
「開発成果物の作成」「テスト開発成果物の作成」では、
決定的に何が違うのか? 

と考えた場合に以下の視点が増えた。
  • モノ:
    • 開発成果物そのもの
    • 開発成果物の持つ癖
  • コト:
    • 開発成果物が実現したこと、実現出来なかったこと
    • 現在の開発成果物をユーザが思うこと
  • ドメイン:
    • 開発成果物を作るうえで関係した背景(基盤技術やドメインの特性、使用した技術の特徴など)
    • 開発チームを取り巻く環境(コミュニケーション状況や組織状況)
つまり、モノを作りましょうといった時に考えることよりも少し考えることが増えた。
基本的には変わらないのだけれど、
複雑に作れば作るほど、考える幅が増えるんだろうというのがよく分かった。


図であらわすとこうなる。
考えているものを3つの視点で見る
テストはそれもひっくるめてさらに3つの視点で見る
複雑に作ると
視点は変わらないが、幅が広がる
これをまぁよく理解せずに
「ボクちゃん後工程だからそもそもの背景とか考えなくていいんだもんね!」
とか言っちゃう人もまれに?いるが、
それだと論拠・根拠が無くなるため、何をやっているんだかわからなくなるうえ、主体性がなくなる。

僕が
「ウチは後工程だから考えなくていいんだよ」
「言われたことだけやってりゃいいんだよ」
「開発者がいいと言えばいいの!」
と言われた時に感じる"気持ち悪さ"というか違和感はどうやらここにあるようだ。
※ただし、スコープの定義の話は勿論別だある。
根拠のあるスコープの中での定義であれば違和感はない。

なのでまぁ、簡単に言うと3種類の視点で考えていて、
その中の「要素」が沢山あって、それをテストする立場で見る
んだな、と。

でまぁ、この「要素」というのがたぶん肝なんだな、と。
といっても大雑把な話だとよくわからないと思うので具体例を列挙してみる。

  • モノ
    • 部品などの構成要素
    • 部品の特性
    • 流用したベースとなる存在

  • コト
    • 要求(満たしたいこと)
    • ちょっとした制限事項
    • 自分がなんか怪しいと思うこと

  • ドメイン
    • なぜ、そのものが産まれたのか
    • 業界の標準や常識
    • どんな人が使うのか
と、こんな感じ。
定量的に説明出来ないが、僕はこんなことを考えている。


でまぁ、最近色々考えさせて頂く機会があって、実践もさせていただける場所もある。
そこでちょこちょこ実践しているのだがー

…これがまぁ、なかなか上手く出来ないw


いや、そこそこは出来るんだけど、考えることが多すぎてイッパツでバシッと決まらない。
何回も何回も修正する羽目になる。

朝起きると「あぁっこんな事も考えられるじゃないか!」と閃いちゃったりして
モンモンとしながら会社に行ったりする。モンモン通勤。


でもまぁ、それはそーゆーもんだ、と割り切ることにした。
イッパツでバシッとキマると格好いいんだろうけど、僕はそんなに格好いいタイプではないし、頭もポンコツなのでそのくらいが丁度いい。
何回も何回も修正するけど、それなりにいいテストが出来るなら、それがいい、と考えた。

予め予測出来ることを全て列挙するよりは、いくつかガイドワードから導きだすフレームワークの方がテストに向いてる気がする。
→理由としては、考えることを全て出すと恐らくコストに見合わない。
ガイドワードから、というのはミッキーさんの意地悪漢字なども参考にできるだろう。

まだ予想に過ぎないが、ドメインを固定したときには、そのガイドワード、
あるいはいくつかの「要素」がスケルトンやパターンのように生成されればいい気がする。

とか考えてたら、僕の考えている範囲はアーキ生成モデルなのか?とか思ったりしたり。


…脱線した。

まぁ、そんな感じでどうやら僕は割りと単純な視点でものを見ていて、
ときどき考え方を流用して「要素」の抜き出しをするらしい、ということが分かった。

この考え方や説明がわかりにくかったり、そうではなくてこうなのでは?
と思われた方は是非、教えていただけるととても嬉しい。

-----
★にしさん(@YasuharuNishi)
★あきやまさん(@akiyama924)
★きょんさん(@kyon_mm)
コメント有り難うございます!

2011年9月18日日曜日

今日のいろいろ

実はよさこいのチームに所属していたりするのですが
今日は地元のよさこい祭りの中で最大のお祭りだったので一日中踊ってきました。
踊る阿呆です。

総踊り(参加者全員で踊る踊り)にて担ぎ太鼓で2曲→1曲を獅子舞
→1曲を踊り子→1曲を獅子舞→最後の総踊りにて担ぎ太鼓で2曲
というスケジュールでやったのですが、既に太ももとお尻、右腕がヤバい。
明日の朝、起きれるかどうかが問題。


ども。コヤマンどぇす。


今日はずっと放置していた
MBAirにEclipseとPleiades(Eclipse日本語化プラグイン)、AndroidSDKを入れる作業をしてみた。
Windowsだと入れるだけーみたいなカンジだったけど
Macだとそうでは無く、いろいろ勝手が違って面倒だった。

下記のサイトにとてもお世話になった。
◆日本語化
http://labs.uechoco.com/blog/2009/04/mac-eclipse-install-pleiades-japanese.html
◆AndroidSDKインスコ
http://www.textdrop.net/soft/mac-android-sdk-install2/

目指せ日曜プログラマ。
で、実はWindowsではサクラエディタがお気に入りだったりするのだが
mac版に無いとのことで、んじゃこれもチャレンジだーとemacsを入れてみた。
ー全然使いこなせないw

まぁ、元はPGしてましたがセンスが無いのは知っていて、
そのときはVisualStudio6でVisualC++上で書いてたし
現役でなくなったあともVisualBasicやExcelVBAくらいでしか
プログラミングしてなかったので
※javascriptはサクラエディタで書いてましたし。。
なんかもたもたしながらも地味に使っていこうかな、と思ってみたり。

生産性が非常に悪いけれども
新しいチャレンジを楽しんでいたりします。
生暖かく見守っていただければ幸いです。

他にもいろいろ知らなければならない技術がたくさんある。
ひとつひとつ、知っていこうっと。

2011年9月3日土曜日

テスト実施者のキャリアパスをどう作るか。


気温が下がって快適になってくると女子の露出が減って心が寒くなりますね。

ども。コヤマンどぇす。

まぁ、こんなしょーもないことばかりしてる僕でも色々考えることもあるんですよ。えぇ。
色々世の流れにアンテナ張ってると、某G社さんのSETみたいなスキル(http://googletesting.blogspot.com/2011/02/how-google-tests-software-part-two.html)が求められていて、作るときに品質上げていかないと!とゆー流れなのはとっても良くわかる。予防であるべきというのは全く正しいと思う。
でもまぁ、そーゆー人はそんなにぽこぽこいるもんでもなく、
会社を見てるとスキルもバラつきがあるし、プログラムを読むことも作ることもしないひとなんて沢山いるわけだ。
いわゆる、テスト実施のみのキャリアである。

勿論、時代に取り残されてしまったと言って切り捨てるのは簡単だ。
しかし明らかに怠惰をしていたわけでない人も少なからず存在するわけだ。
現場から「頼むからやめないでくれ」と言われ続け、ずっと同じ仕事を強要され続けた人も。

僕より年上のそういう人は沢山いる。そして、単価の高い日本人である宿命により、ある日突然コストカットという名目で切られる可能性に怯えている。

そういう人は日本の中でどこを目指すべきなのだろうか。
そう考えた。


〇そのいち。
テスト設計者。

一般的に考えられている最も多いキャリアパスなのではなかろうか。 
いつもやってるテストを作る側になってみる。
いつもあの人が出してくるプアなヤツを改造しているから
なんとかなるだろうと甘く見てると痛い目を見るキャリアパスであるw

どの世界にも言えることだが、他人が作ったものを批判するのは簡単であるが、ゼロから作るのは大変なのである。

よく見る光景として、
「テスト実施者だったときは凄かったのにテスト作らせたらあまりにショボい」
「テスト実施者としてはとても有能であったが、テストを作らせるといつまでも細かいところにこだわりすぎて作業が終わらない」
「本人がやりやすいと思って作ってはみたものの、実は皆がわかりにくいものが出来てしまった」
といったことはありがちである。

その結果、やっぱり「テスト実施者」でいてください、ということが
しばしば起こる。


〇そのに。
テストマネージャ。
実施が上手いひとがマネジメントも上手いひとがかというとまたこれが別の話だったりする。

そもそもテストリーダーとテストマネージャって会社の切れ目なんじゃ、とゆー
大人の事情はさておき、求められるスキルセットがあまりに違うので
突然テストマネージャ、という話にはなりにくい。
顔の広さやらヒューマンスキルが高い人は割りとすんなりハマッたりもする。
ただし対外交渉でしっかり主張が出来るだけの胆力は必要になるだろう。

最悪なのは何を勘違いしてるのか、一日中雑談だけして過ごす輩。
社内政治のみに走ると使えないのにずっと残って現場に害を与え続けるが、上司には届かないという
やっかいなゴミになる。が、割りと良く見かけるタイプ。

ちなみにテストリーダーやマネージャになってからは要求の方のキャリアに行ったり、
プロジェクトマネージャになったりなどといったキャリアパスも増えると思う。


〇そのさん。
実施の自動化推進及び切り分けとその利用者。

いきなりハードルが上がったように見えますが気のせいですw
端的に言うとノウハウの形式知化にくわえ、形式知の利用と発展である。

つまり、生産性を上げながらもテスト実施にフォーカスを当て続ける道。

その中でどこから自動化すべきか?ということを考える。そしてそれを使いながら自分の強みが活きるところを探す。
TABOKで言うと、スキルカテゴリ6、TestAutomateArchitect的な仕事かも。
下記参照。


なかなか最強だが汎用性を犠牲にしすぎると属人化して視野が狭くなったりするので注意が必要。
特定ドメインから出れなくなるリスクは考えておく必要があるだろう。
ドメインの没落とともに技術者人生も…とならないような施策が必要になったりする。

上手く自動化の勉強が進んでプログラミングやツール作成が進めばしめたもの。
活躍の場に広がりが出ます。
湯本さんや松木さんはマネージャを経てこのプロセスを踏んだひと、と理解しています。


〇そのよん。
探索的テストの専門家。
※このへん、少し空想入ってます。

最近、脚光を浴びはじめた探索的テスト。
極端なことを言うと正にウデ一本で生きていく生き方だ。

絶え間ない実績と自らのプロモーションが必要になるだろう。 
「オレに任せてくれれば、バグ出してやるぜ」的なイメージ。

但し探索的テストに必要とされるエビデンスはしっかり取っておくしたたかさと、自分のなかにある経験やパターンとのマッチングの能力が必要であり、探索的テストの利点などを深く理解していないと難しい。

また、対象ドメインの知識やプログラミング知識も探索するには
勉強が必要であろう。
しかも普段から探索する癖をつけていたりなどができないと、パターンとのマッチング能力を継続的に発揮するのは困難であろう。
また、多岐にわたる製品カテゴリの経験が要求されるため、仕事に巡り会う運のよさも必要だ。
フリーランステスターとでも呼ばれるのだろう。
僕はこういったタイプの人にはあまり巡り会った事はない。
長く同じ仕事をするひとの中に稀に見かける。
が、そのコンテキストから外れるとどうなるかはよくわからない。※ドメイン依存の人が多い気がする。
正確には、日本の産業状態では難しいから存在しないだけかも知れない。
とはいえ、海外のイベントに出ていない身としてはどれほどの探索的テストの事例やプロがいるのかはわかっていない。
※Cem KanerやJames Bachのセミナーを受けた方がどれほど専門性を持って活動しているのかは
よくわかっていない。


〇そのご。
実施におけるメソドロジの構築などの今までに存在しないジャンルの仕事を開拓する。

正直言うと空想の存在。
だがその世界は今まで存在しないだけであって、作る価値はあると思っている。

探索的テストやテスト実施についての知識体系の構築などをするひと。
スーパーテスターみたいな人が何を考えてどのように操作などを行い、
その考え方はどこまで通用するのか、などを形式知化する。
探索的テストのパターンとのマッチングの形式知化などが求められるだろう。

化学、物理、論理、人間についての勉強など、多岐にわたる学習が必要になるだろう。



とまら僕がおぼろげに考えられるのはこのくらいだ。

ま、どれにでも言える事は
「めちゃめちゃ勉強が必要」ということぐらいであろうか。

「今の仕事が楽しいからこのままの仕事だけしてたーい♪」というひとには先はない。野垂れ死にが待つだけだ。
それだけは確かかな。
ま、それはどの業種にも言える事だったりもするのだが。

人生そんなに甘いもんじゃないんだなー。うん。

2011年8月25日木曜日

探索的テストをいつやるべきか。

ども。コヤマンどぇす。

先日は水面下で打ち合わせをしている、あるイベントの打ち合わせだった。
(名前はまだ言えない)

ともあれ、その打ち合わせ後の飲み会中に
「探索的テストをいつやるべきか」
という話題になった。
それを通勤中の時間を使っていくつか考えている事を書いていく。

コヤマンの結論は「場合による」だ。
当たり前なんだけど、必殺技主義でないので、この回答にならざるを得ない。


―理由を述べる。

まず、探索的テストの前提として
ソフトウェアが「探索できる状態」である必要がある。
つまり、ある程度形になっていて、ある程度安定動作をしている必要がある。

なぜならば、例えば原因解明中のクラッシュ/ハングする問題があったとする。
どこで落ちるかわからない状態で探索を行って、途中でクラッシュ/ハングしたとする。
こうなると自分の操作が原因なのか、既知の問題なのかはパッと見ただけではわからない。

動作ログがあるなら切り分けは出来るが、動作ログを解析するツールなどが整備されている必要がある。
解析を開発担当者にやらせれば良いとお考えの方もいるかも知れないが、作る側からすると「どうせ既知の問題だろ」と考えるのでモチベーションも上がらないうえ、
徒労に終わってしまった場合には所謂時間の無駄遣いを強要することになるため、信頼関係の問題となる。
なので個人的にはオススメしない。


また、組織やチームの役割も関係する。

僕は統合テスト屋であり、主にシステム全体として見た場合の単機能の実現などがメインミッションとなるのだが
規模によっては製品単体の単機能であったり複数の組み合わせなとも
クライテリアとして存在する場合もある。

組み合わせの場合には単機能の品質次第であるが、早めに実施することをオススメする。
組み合わせの仕方による違いや、弱みみたいなものが早めに触ることにより浮き彫りになる。

逆に単機能の実現が目的なのであれば、ある程度機能が安定したあとに更なる品質向上を目的としてユーザの観点などを加えながら実施するのが良いだろう。


作りや重要度によっても影響を受けるのだが、これは多岐にわたるので割愛する。

重要度が高いものや、作りが特殊なものは早めに触る方が良い。
とはいえ、技術確立がなされていないなど、全く動作しないような状況ではあまり意味がない。


上記のようにさまざまな要因があると考える。よって「場合による」のだ。

と、考えたことをぼんやりと。

2011年8月9日火曜日

Software Testing ManiaX vol.5に寄稿

ども。コヤマンどぇす。


創刊から記事を書こう書こうと思っていたにもかかわらず
周りの方々の豪華っぷりに尻込みしたり、
記事を書いてる余裕も無かったので
作成側にいながらも書いていない状態でしたが、今回やっと書けました。



伝説のソフトウェアテストの同人誌
Software Testing ManiaX vol.5に
「テストの必要性を考えたときに考えたこと」という内容で寄稿しました。

決して技術肌でない僕が書くのはためらいを禁じ得ませんでしたが 想いを強くするために恥を覚悟で書きました。


熱さだけ、勢いだけですが、目を通していただけると嬉しいです。
-----
2011/08/14[sun]
C80 東2ホール P-28b
-----
http://circle-official.wacate.jp/


2011年7月30日土曜日

初テスコラと統合テストと僕。

ども。コヤマンどぇす。

今日は@Yuko_skiさん主催の通称"テスコラ"に初めて参加してみますた。
理由は"統合テスト"についての取り組みをしているから。

"統合テスト"は僕がテスト人生をかけて取り組もうと思っていたテーマだったので
ものすんごく興味があった。


◆統合テストって難しいんですよね
"統合テスト"ってなんぞ、とゆー説明自体もかなり難しくって、
単体テストとシステムテストの間にやるテスト、というのが
いちばんしっくりくるかなぁと思っている。

最近はシステムオブシステムズとか色々あるじゃないですか。
あれもシステムテストってどこやねん、的な定義が難しかったり
ソリューションとか言われたりしてたり。

一体どこまでが単体/ユニット/コンポーネントだったりすんねん、とか。
んで、単体じゃないから統合だよね、とかなるんですけど
その粒度はホントに様々なんですね。

かの「バリ本」にも難しいって書いてあった気がします。←記憶が定かでないですが。

◆言葉の定義はわかるけど、なんで難しいの?
で、なんで難しいかというと、
@mkoszkさんのエントリがわかりやすく表現してあります。
http://d.hatena.ne.jp/mkoszk/20110103/p2

縦も横も考えるんだけど、作りだけでなく使われ方まで考えないと
うまくテストできないんですよね。

で、もちろんインターフェースだけに注目しても「いいテスト」にはならない。
※このあたりは用語の定義に反するのですが、そう主張する。

僕は業務で「統合テスト」のあたりを扱って8年ほど経ちます。
思えば「なんとなくプログラムも書いてるし、テストもわかるし」みたいな感じで
入ってみたのが運のつき。

大き目のシステムから小さめのシステムの統合テストみたいなものまで。
時には機能間の結合を見たり、時にはプロトコルのログとにらめっこしたり。
そんな感じで幅広い経験をさせていただいていて
めちゃくちゃ面白いところだと思っている。

早めに欠陥を見つければ修正コストも早いよね、と思って頑張ったりする。

さらに会社の基準とかでも、かなりのバグ抽出カバレッジを求められたりする。


◆でも統合テストってヤツは。
そんなニクいヤツ"統合テスト"ですが、
実際に事例とか"統合テスト"といえばこう!みたいなものって実は確立されていません。
※僕が知らないだけかもですが。

まぁ僕が思っているだいたいの理由は単純で。

「人間の感覚」の度合いが強いんですね。
だから方法論として確立するのが非常に難しい。

これはテスト全般に言えることだったりするんですけど
特に"統合テスト"というフェーズはそれの度合いが強い。

人と人との意志疎通であったり、認識のズレであったり
人が何かを作るときに思いついた「思いつき」であったり
そういった事とガチで向き合うテストなんですね。

しかもテスターらしく外からそれを見ないといけない。
※この感覚わかるかなぁ^^;

いわゆる"アジャイルテスター"みたいなことをする必要がある。

特に最近のご時世はひどくって、
高品質短納期が求められるくせに
システムオブシステムズで「機能ってなんだっけ?」とかいう状態なので
直接PMやら開発リーダーに話を聞いたりしてコミュニケーションをよくしないと何も解決しない。

仕様書がないことすらある"統合テスト"では、コミュニケーションやら
見える化などが絶対条件で必要になるんですね。

で。これを楽にしたいんですね。
そしたら皆ハッピーじゃん、と。


◆話は戻ってテスコラ。

でまぁ、テスコラに参加してみました。(前置き長ッ)

今日は今までのおさらいとどんな感じで進めようかねー、という話をしたのですが
その最中でも色々な議論ができて楽しかった。
「機能」って難しいよね。@mkoszkさんがManiaXに書くわけですよね。

で、今日感じたのは、
・「要求」には「現在のリアルから求められるもの」と「外部から求められるもの」があるということ。
・テストを引き受けるときに「この製品のコンセプトはなに?企画書プリーズ」という僕は
 割と異端なのかもしれないということ。
 ※誰からも反応がなかったので、反論が無いのか、ポカーンとされたのか
  どっちかよくわからないのだけれども。


そんな感じス。

2011年7月29日金曜日

新調。

ども。コヤマンどぇす。

38歳じゃない!とクレームを言われました。
サーセンw

色々googleのサービスを使っているので、
やってみるかとブログを新調してみた。

ソフトウェアテスト
ソフトウェア品質
欠陥
人間
などに興味があります。

僕が考えたことなどを好き放題に書いてみて
叩かれたりなじられたりすることを想定している。
ま、負けないぞっwwww

三日坊主ですけど、どっかで何かやったとか記録できるといいな。
スライドとか載せられたらもっといい。
載せられるかどうかよくわからんので調べてみようと思っている(そこからかよ)。

とりあえず。よろしくお願いいたします。