2012/11/30

テストに関していろいろ感じてきた

“JaSSTソフトウェアテストシンポジウム-JaSST'12 Tokai” http://bit.ly/Sypa4y
に参加してきました。

なんというか印象としては、エンタープライズ系よりも組み込み系の方が多めで、業務としてテストを専門で実施している方々向けで、同値・境界値テスト、デシジョンテーブル、テスト設計コンテストなど、普段からテストをちゃんとしている人がもっとちゃんとやろうという感じを受けました。

そもそも私の場合は、テストを専門的にやったこともなければ真剣に考えたこともないので、かなり衝撃的でした。

あまりにレベルが違ったので、基調講演をされた日本HPの湯本さんの2006年の以下の記事を読みながら、自らの経験のかなり「まずい状況」を振り返ってみようと思いました。
振り返って、何がまずいのか認識しておきたいと。

引用:「プロジェクトが火を噴いてきたからテストに人を追加投入しよう」という考え方ではうまくいきません。“基礎から学ぶソフトウエア・テスト - 基礎から学ぶソフトウエア・テスト
ITpro” http://nkbp.jp/SyouvV




この図はよくあるV字モデル。
各テスト行程は、私の経験上「まともにやれてない行程」であり、ちょっとこれまでの経験というか感覚を振り返ってみたいと思います。

1.静的テスト…
プロジェクトが製造フェーズになるとコードレビューを実施する。ある程度紙に印刷して持ち寄って、処理系で陥りがちな罠や言語仕様上の注意点などはプロジェクトメンバーに周知させる。そして各種メトリクス測定を実施。巨大なクラス、メソッドは早めに摘みとっておく。(おー、ここまではこれまでの経験上、案外できている気がする!)

2.単体テスト…
2-1.モジュールレベルの単体テスト
う・・・やったこと無いぞ。。。
ちゃんとモジュール化しましょう!なプロジェクトに遭遇したことがほとんど無い。
大抵の場合、大まかな外部設計だけしておいて、内部設計を(工数削減とかの理由で)省略して製造フェーズに入ってしまう経験が大半だ。すると、およそコーディングレベルに落ちていない、一枚岩の巨大な外部設計をもとに一枚岩の巨大なモジュールが出来上がる。
モジュール化する内部設計フェーズが無いため、モジュールレベルの仕様書は無く、したがって単体テストをしようにも、対象のモジュールが存在しない。

しかし、こんな経験ばかりでは無いことも思い出した。
RFPに「開発メソドロジ自体を納品してほしい。自社(発注側)開発における理想の開発環境の前提としたい」といったような内容があるプロジェクトがあった。単体テストについては、ユーティリティ系は主にJUnitを使い、業務系はDBUnitを使い、テストデータとテストプログラムをひっくるめて自動化に努めた。
単体テストおよび再帰テストが可能な数少ないシステムだった。

2-2.MVCレベルの単体テスト
これまたほとんど経験が無い。
これは、Eclipseに代表されるような統合開発環境の弊害を感じる。
一台のパソコン上でEclipse+Tomcat等を立ち上げれば最初からGUIと結合した動作確認ができてしまう。
この場合、画面が呼び出すスタブおよびモデルを呼び出すドライバを用意する必要が無い。
そうすると例えば、全パターンの画面操作で意図したメッセージがモデルに送信されるか?というテストをやる場合、スタブが無いためMVCでいうところのVとMまで連動させなければならない。
例えば、あらゆる画面からのメッセージに応じて正しいDB操作がされるか?というテストをやる場合、ドライバが無いため画面を操作しなければならない。

これでは、人が(MVCが連動している状態の)システムを操作することでテストを実施することになってしまい、もはやMだけ、Vだけ、Cだけのテストをする余地がない。

よって、モジュールレベル・MVCレベルのいずれの単体テストも実施しないプロジェクト経験がほとんどだ。

しかし、これも一度だけしっかりやった経験がある。
コンポーネント設計にこだわった発注側の意向で、MVCを完全に分離。JUnitなんて無い時代だったが、統合開発環境内にスタブ&ドライバを作り、自分でアサーションを書いて意図しない動きだったら”エラー!!”みたいな文字列を画面に出してデグレの発見に努めていた記憶がある。

とにかく単体テストについてはまともな思い出がない・・・しかし、どのプロジェクトでも単体テストと単体テスト仕様書といった言葉はWBSにあがっていた気がしている。システムの作りとして単体テスト不可能なのにどうして単体テストが出来るのか?

それは、作る仕様書にある。先に述べたように大抵の場合、大まかな外部設計レベルの仕様書を作るにとどまるため、Vモデルにしたときに対応する単体テストがこれにあたってしまうためだ。納品される単体テスト仕様書のレベルは、大まかな外部設計のレベルになっていればよい。さらに、工数削減のために外部設計書の横にチェック項目をもうけてテスト仕様書兼結果報告書として納品してしまう場合もある。
こうなってくると、単体テストとは、大まかな設計書からプログラマが読み取った一部の大まかな仕様にだいたい沿う動きをしているかどうか?というテストになる。

3.結合テスト…
前述の単体テストで述べたように、モジュール分割もMVC分割もほとんどされることがなかったために、それらを結合させるテストも経験がほとんど無い。

4.システムテスト…
ユーザー利用時と同じ環境、業務の流れで実施するテスト。これはいずれのプロジェクトでもかなりのリソースを割り当てて実施してきた。しかし、大抵の場合、これ以前のテストフェーズが殆どできていない(フェーズとしてはやってきているが、PC上でシステムテストと同じレベルのALL結合状態でやっている なんちゃってテストである)為に、不具合が噴出してしまう。当然のことながら単体、結合テストで発見されるべきバグが当たり前のように出てしまう。

発生する不具合、仕様変更対応のために、コードに手を入れる。しかしそのコードに対して再帰テストをするためのテスト仕様書やテストコードは存在しない。
よって、再帰テストはあきらめて、モジュール化されていない数千ステップの一枚岩に対してなんとなくのテストを実施する。
そうして、最初に誰かがコーディングした一枚岩の中に、数ヶ月〜年単位で「多くの人間がなんとなくテストしただけの修正」が蓄積されていく。
そのうち一枚岩がだれのものでもなくなり、品質保証が出来なくなる。

まとめ
上記で書いたことは、ひとりで感じていても変わらない。
プロジェクトメンバーみんなで同じ言葉、同じ定義で会話できないといけない。
今日のシンポジウムでSWEBOKやJSTQBをいうものがあるのを知った。
共通定義で会話できる前提としてよいかもしれない。



0 件のコメント: