ソフトウェアテスト Archive

ガッツです。ガッツという名前に慣れないので今度変えるかもしれませんが宜しくお願いしますm(_ _)m

今自分がやっていこうと思っているテスト駆動開発について、TDDとはどんなものかを考え、実践の結果など、今後この場を使って報告などしていければと思っています。
まず最初はTDDについて少し調べ思ったことを。今後実践についても報告していきます。

---

テスト駆動開発（Test Driven Development）

テスト駆動開発はテスト手法ではなく、開発手法と考える。 プログラミング後にテストを行なう事が開発の多くであると思いますが、それに対してテストファーストという言い方もある。

TDDの信条

• レッド - 動作しないテストを少し作成。たいてい最初はコンパイルできない。
• グリーン - テストをすぐに動作させる。そのためにはどんなコードでもかまわない。
• リファクタリング - テスト動作のための重複を全て取り除く。

---

基本的にスピード感を持って作業を進める事が重要で、一気に大量のテストを作成するのではなく、ひとつひとつ確実に進め、不安を少しずつ減らしていくというような感じなのでしょうか。
多くの人の話を一気に全部聞こうと思っても、聖徳太子じゃあるまいし、なかなか無理な話だろうって事なのですかね。

なので、レッド・グリーン・リファクタリングのリズムの回転を速く、レッドの時には基本的にテストは追加しないで、ひとつのレッドに集中する。そしてどんなコードでもいいのでまずグリーンにする。 やっぱりグリーンになる時は気持ちが良いので、ある意味では何回もグリーンになる快感が味わえるといった最高の手法なのでは・・・。

ですが、テストが通る状態（グリーンの状態）にするためにはどんなコードでもいいとあり、その後リファクタリングする事が確実なわけなので、どのようにこのリズムを刻んでいけるかが今現在で「スピード感」を出せる部分なのかが疑問なところです。

次回は、まず実践という事でサンプルプログラムを使ってさらに流れをつかんでいきたいと思います。

こんにちはmattyです。
ここ数日暑いですね、、もう半袖です。

いま参加しているプロジェクトがテストフェーズに入り、連日テストをしています。
そこで今回は以前読んで興味深かったテストに関する心構えTipsを2つほどご紹介したいと思います。

テスト担当者の心理的な成熟度

1つ目はテストの目的をどう考えているか「テスト担当者の心理的な成熟度」についてです。
(現代のソフトウェアテストを確立した3人の先駆者のうちの1人のBoris Beizer氏による定義)
以下その5つの段階です。

フェーズ0	テストとデバッグに差はない。デバッグの支援以外に、テストに特別の目的はない。
フェーズ1	テストの目的はソフトウェアが正常に機能することを示すことである。
フェーズ2	テストの目的はソフトウェアが正常に機能しないことを示すことである。
フェーズ3	テストの目的は何かを証明することではなく、ソフトウェア動かないことで生じるリスクをある許容値まで下げることである。
フェーズ4	テストは行動ではない。テストとは、大きな労力を払わずともリスクの低いソフトウェアを生み出せる、精神的な規律である。

フェーズ4になるとテストフェーズでどうテストに挑むかなどではなく、設計するときも、プログラミングするときにも、いつ如何なるときも、リスク軽減するにはどうしたらいいか常に考えるということですね。 テスト担当者だけでなく、プロジェクトに関わる人全員にいえますね。

ソフトウェアテストの原則

2つ目は「ソフトウェアテストの一般原則」というものです。以下テスト技術者資格制度Foundation Level シラバス 日本語版より引用。

原則1：テストは欠陥があることしか示せない
テストにより、欠陥があることはわかるが、欠陥がないことは示せない。テストにより、ソフトウェアに残る未摘出欠陥の数を減らせるが、欠陥が摘出出来ない状態でも、正しさの証明とはならない。

原則2：全数テストは不可能
すべてをテストすること（入力条件の全組み合わせ）は、ごく単純なソフトウェア以外では非現実的である。完全テストの代わりに、リスクや優先順位によりテストの焦点を絞る。

原則3：初期テスト
テストはソフトウェア・システム開発のライフサイクルのなるべく早い時期に開始し、あらかじめ定義した目的に集中すべきである。

原則4：欠陥の偏在
リリース前のテストで見つかる欠陥や運用の処理不正の大部分は、ある特定の少数のモジュールに集中する。

原則5：殺虫剤のパラドクス
同じテストを何度も繰り返すと、最終的にはそのテストでは新しいバグを見つけられなくなる。この「殺虫剤のパラドックス」を回避するため、テストケースを定期的に見直して、改定する必要があるし、ソフトウェアやシステムのいろいろな部分に対しテストを実行して多数の欠陥を摘出できるよう、これまでと違うテストケースが必要となる。

原則6：テストは条件次第
条件が異なれば、テストの方法も変わる。例えば、高信頼性が必要な24 時間稼動するシステムのテストは、e コマースのテストとは異なる。

原則7：「バグゼロ」の落とし穴
欠陥を見つけて修正しても、構築したシステムが使えなかったり、ユーザの要件や期待を満足しなければ役に立たない。

テストをする上で心得ておくべき内容ですね。
以上、2つのTips(?)でした。
私もこれらを再認識して、またテストに勤しみたいと思います。
それではまた。