**************************************************************
_/_/_/_/_/_/_/  ソフトウェア業界　新航海術  _/_/_/_/_/_/_/_/_/
**************************************************************
第71号  2005/04/18
  ▼  まえがき
  ▼  [保存できないエディタ]　テストの大分類
  ▼  [保存できないエディタ]　ホワイトボックステスト
  ▼  [保存できないエディタ]　ブラックボックステスト
  ▼  [保存できないエディタ]　最終受け入れテスト
  ▼  [保存できないエディタ]　次回以降の予告


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  まえがき
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

こんにちは、蒲生嘉達（がもう よしさと）です。

第57号から「まぐまぐ！」での読者数が急に増えてきました。
第56号までは200名だったのに、今では338名です。
読者も「日本のソフトウェア請負開発は何かおかしい」という思いを
お持ちなのだと思います。

第57号を書いたときは3，4回のシリーズにするつもりでしたが、
請負契約や開発プロセスについては話題が尽きず、今回でシリーズ
15回目となります。

「5年後のシステム開発」シリーズから独立させて、「保存できない
エディタ」シリーズとしました。
まとめて読みたい方は下記URLを参照してください。
http://www.kei-it.com/sailing/back_editor.html



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　テストの大分類
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第70号では、「テストとテスト計画作成については、プロジェクト
全体がウォータフォール型であったとしても、漸増型で行うべきだ」
という「基本から学ぶソフトウェアテスト」の主張を紹介しましたが、
その詳細は書きませんでした。
前提として、テスト分類、ウォータフォール型でのテスト、漸増型
でのテストについての基礎知識が必要だからです。

本号ではテスト分類について取り上げます。


「基本から学ぶソフトウェアテスト」を読んで、意外だったことが幾つか
あります。
その一つは、日本の開発現場や情報処理試験でお馴染みの「単体テストと
結合テスト」「トップダウンテストとボトムアップテスト」というテーマが、
ほんの数行で片付けられているということです。

また、日本の請負契約で必ず契約書に記載される「検収」という概念が
全く記述されていないことも意外でした。


同書でのテストの大分類は下記のとおりです。

1.設計段階でのテスト
2.ホワイトボックステスト
3.回帰テスト
4.ブラックボックステスト

設計段階でのテストは主にレビューミーティングのこと、回帰テストは
バグ修正後の再テストのことです。
この両者、特に回帰テストが独立した大分類として扱われていることは
注目に値します。

また、日本で出版されている多くの書籍では、テストが「単体テスト→
結合テスト→システムテスト」という流れで説明されるのに対し、まず
大きくホワイトボックステストとブラックボックステストに分類している
ということも注目に値します。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　ホワイトボックステスト
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ホワイトボックステストとは、プログラムの処理方式を考慮し、
ソースコードを利用してテスト項目を抽出するテストです。

ホワイトボックステストはさらに幾つかに分類されていますが、
その中で主なものは次の３つです。
・インクリメンタルテスト
・パステスト（パスを網羅するテスト）
・静的テスト（ウォークスルー、コードレビュー）

インクリメンタルテストは、いわゆる単体テストと結合テストのことです。

> インクリメンタルテスト法では、最初に単体を独立にテストする。
> プロセスやプログラムの最小構成単位をテストすることを、
> モジュールテスト、ユニットテスト、単体テストと呼ぶ。
> 単体同士を組み合わせるテストは、統合テストと呼ぶ。

このインクリメンタルテストの手法として、トップダウンテストと
ボトムアップテストがあります。
最上位のモジュールからテストするのがトップダウンテストで、
最下位のモジュールからテストするのがボトムアップテストです。
それぞれ、長所、短所がありますが、どちらを選択すべきかについては
「基本から学ぶソフトウェアテスト」では、あっさりと「実際には、
モジュールを書いたらすぐにテストするのが一般的なので、時には
ボトムアップで、時にはトップダウンだと言える」と書かれています。

また、ホワイトボックステストは、プログラミング工程の一部です。
「多数のプログラマが、システムに自分のモジュールを組み入れる前後で、
日常的にモジュールのホワイトボックステストをしているから」です。 

日本の学者は、「ウォータフォール型開発プロセスでは、コーディング
が全て完了してから、テスト仕様書を作成し、それが完了してからでないと
テストに入れない」と説明していますが、それは間違いです。

ウォータフォール型でもホワイトボックステストはプログラミング
工程の中で行ってもよいのです。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　ブラックボックステスト
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ブラックボックステストとは、プログラムを中身が見えないブラック
ボックスとして扱うテストです。

ブラックボックステストはさらに６つに分類されていますが、主な
ものは次の３つです。

・ベータテスト
・検証
・最終受け入れテスト

ベータテストとは、ターゲット市場を代表する人々を選び、実際の
製品と同じ使い方をしてもらって、コメントを集めることです。

検証とは、設計ドキュメントや仕様書と照らし合わせてチェックする
ことです。検証はさらに、次の二つに分類されます。
・機能テスト：外部仕様書どおりに動くことの検証
・システムテスト：ユーザ要求書やシステム要求書どおりに動くことの検証

「基本から学ぶソフトウェアテスト」では、機能テストとシステムテスト
で実行するテストとして、仕様確認テスト、操作性テスト、境界条件テスト、 
性能テスト、日常業務テスト、負荷テスト、などの15種類を挙げています



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　最終受け入れテスト
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

最終受け入れテストとは、ブラックボックステストの一つで、
受託開発特有のテストです。発注側が納入時に行うテストです。

> 小規模プロジェクトなら、このテストは非公式に行うかもしれないが、
> 大部分のプロジェクトでは、テストの詳細を事前に書面にして合意する。
> 納入前に、最終受け入れテストに合格することを必ず確認しなければ
> ならない。徹底的にシステムをチェックする訳ではないので、
> 最終受け入れテストは、丸1日もかからないのだ普通だ。

日本の場合、発注元が富士通やNEC等のメーカなら、購買部門が
最終受け入れテストを行います。しかし、それは形骸化されていて、
ほとんどは書類審査のみで、時間的にも30分位です。
発注元がエンドユーザの場合は、それすらありません。

請負契約締結時に最終受け入れテストのテスト項目を契約で規定する
こともありませんし、最終受け入れテストの詳細を事前に書面にして
合意することもありません。

その代わり、日本の請負契約では、ほとんど例外なく、検収期間
(たいがいは1ヶ月)を設けています。
発注元は検収期間中に最終受け入れテストを行い、それに合格すれば、
数十日後(この日数を「支払いサイト」と呼びます)に代金を支払います。

「基本から学ぶソフトウェアテスト」に検収に当たるものが書かれて
いないことから推測すると、米国では最終受け入れテスト後の障害は
契約責任(日本での瑕疵担保責任)で処理されるのだと思われます。

日本でも改正下請代金支払遅延等防止法が平成16年4月1日より施行
されたことにより、支払日の算出の起点は検収完了日ではなく納品日に
なりました。

納品時の最終受け入れテストはどうあるべきなのか、検収とは何なのか
（検収時の障害対応と瑕疵担保責任はどう違うのか）、別の機会に
論じます。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　次回以降の予告
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=


次回以降は下記の項目について書いていきます。

・「全体がウォータフォールでもテストは漸増型で」の詳細。
・納品時の最終受け入れテストはどうあるべきなのか、検収とは何なのか。
・オーダーメイド開発の多い日本での漸増的開発はどのように考えたら
　よいのか？
・請負開発での重要なマイルストーンは「受け入れテスト項目の決定」。
・ウォータフォール型開発プロセスでの3つの契約の性格の違い。
・契約には違反していないが、製品として欠陥がある場合（第57号
　での例のような場合）の考え方。


次号は、4月25日発行予定です。

乞うご期待！！



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  本メルマガについて
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

本メルマガは2003年12月8日に創刊されました。
創刊号 http://www.kei-it.com/sailing/01-031208.html で述べたとおり、
本メルマガのコンセプトは「読みものとしても面白い慶の事業計画」であり、
目的は「事業計画の背後にある基本的な考え方を語ること」です。

したがって、第一の読者としては、慶の社員（正社員・契約社員）及び
慶と契約している個人事業主を想定しています。
彼らには慶社内のメーリングリストで配信しています。

また、多くのソフトウェア会社・技術者が直面している問題を扱っているので、
ソフトウェア会社の経営者、管理者、技術者にとっても参考になると思い、
第33号(2004年7月19日号)からは「まぐまぐ！」で一般の方々にも公開する
ことにしました。


本メルマガの内容に興味を持つであろう方をご存知なら、是非
本メルマガの存在を教えてあげてください。

（以下をそのまま転送するだけです。）
---------------------------------------------------
【お勧めメルマガ　ソフトウェア業界　新航海術】
⇒ http://www.mag2.com/m/0000136030.htm　または
 　http://www.kei-it.com/sailing/　
 　
---------------------------------------------------

このメルマガに対するご感想・ご質問はこちらにお寄せください。
　　　　　　　　　　　 office@kei-ha.co.jp
--------------------------------------------------
このメールマガジンは『まぐまぐ！』 http://www.mag2.com/ を利用して
発行しています。配信中止はこちら http://www.mag2.com/m/0000136030.htm
（但し、web@kei-ha.co.jp it@kei-it.com には直接配信しています。）

発行者Webサイト: http://www.kei-it.com/sailing/
（発行者Webサイトではバックナンバーの全文検索も可能です。）

--------------------------------------------------
発行：
株式会社 慶
　代表取締役  蒲生 嘉達
　y_gamou@kei-ha.co.jp
　Webシステム開発事業部　http://www.kei-ha.co.jp
　ITサービス事業部　http://www.kei-it.com
　人材コンサルティング事業部　http://www.k-bank.jp
　TEL：03-5951-8490  

☆　コピーや配布をされる時はご一報ください　☆