Welcome to MSDN Blogs Sign in | Join | Help

InterConnect Blog

日本で生まれ、日本で開発している製品です
開発チームから情報をどんどん出していきます!
製品開発におけるテストの役割
 

こんにちは。

今回も、ソフトウェアのテストを行っているチームのマネージャー(責任者)よりお伝えします。

 

本人も慣れてきたようなので私の補足はありません。

私はこの中では「仕様を決める部隊」に属していますので、その辺も投稿しなければと焦っています。

 

----------------------------------------------------------------

こんにちは。

またまたテスティング担当です。

 

前回は開発のJargon(仲間内言葉、専門語、わけの分からない言葉...)を幾つかちりばめながら書かせてもらいましたがいかがでしたでしょうか?基本的には開発知識等まったくない方でもわかる内容を心がけています。しかしこちらの文章力のなさから、理解不能に至らしめた場合・・ ごめんなさいです。(是非その旨コメントを)

 

今回は、InterConnect開発プロジェクト全体におけるテストの流れと役割(テストプロセス)について書かせて下さい。

 

一般的に開発プロジェクトは、仕様策定>プログラミング>テスト といった流れがありますが、基本的にマイクロソフトのテストはその全てのフェーズにおいて仕様を決める部隊、そして実際にプログラミングする部隊と密に連携して作業を行っています。ですので、この流れの中でプログラミングが終わってから、さて仕様に添って動いているかなぁとテストを開始する訳ではないのです。

 

注意:勿論開発プロジェクトの規模・目的によって、開発そのもの・テストのやり方に違いがあるのは事実ですし、ここで書いているやり方が全ての開発プロジェクトに適用できるという趣旨ではありません。

 

さて仕様策定でのテストの役割とは何でしょうか?

それは作成途中の要求仕様が本当にユーザさんのニーズに添っているか、ニーズを満たしているか、足りない部分はないか、機能は作るけど、使い勝手が著しく悪い部分はないかといった、仕様を作り込む段階でのテストです。内部ではスペックレビュー、スペックインスペクションと呼ばれていて、正式なプロセスのひとつとして機能しています。

 

ではプログラミング段階のテストとは?

仕様に基づいて開発者が実際にプログラムを頑張って書いている段階では、こちらが直接作業に関わる事はありません。しかし、作業担当者のプログラミング作業が全て終わってからテストすると、結構色々問題が見つかる事があったりするのです。

 

例えば・・・

仕様に対する解釈が違っていて出来上がりが仕様と異なってしまう。

あるいは仕様そのものが書いてない場合(これ自体問題ですが、全てを厳密に100%網羅できない場合も実際あるわけで・・)、開発者が独自にプログラムを書いて実装するものの、その出来上がりが使いにくい・わかりにくい物になってしまう。

あるいは、厳しいスケジュール状況から仕様を全て満たすプログラムを書けず、結果として仕様の特定部分が抜け落ちてしまっている事が後日発覚・・など。

 

全てが開発者そのものに問題があるというわけではなくて、開発プロジェクト全体でフォローしないといけない課題も含んでいます。そこで考え出されたのが・・・ --> プログラミングの段階から仕様策定者・テスト担当者も一緒になって、評価をしていく。開発が全て終わっていないプログラムでも、ある程度機能が実装され・動くようになったら、テストをしていくといったやり方です。

 

実際はある大きめの機能毎に小さなグループを作り、そのグループは仕様策定者・プログラミング担当者・テスト担当者から構成されます。(それぞれの部隊から最低一人はそのグループに参加)そしてそのグループで仕様の討論をして、出来上がったプログラムの評価も一緒に行っていくのです。

 

実は・・・ 本社も同様なやり方を導入していて、このグループ単位での開発はFeature Crew開発と呼ばれています。ですので、多少ネタあかし?をすると、本社のこのプロセスを我々InterConnect開発チームにも適用したといった次第。しかし、そうはいっても、開発人数の規模も内容も違うものをそのまま導入しても運用にコストがかかり、期待した結果を得られないこともあります。ですので、そのやり方は導入したものの、我々開発チームにより適した内容へカスタマイズしていったのも事実なのです。(ここを強く強調?)

 

前回テストアプローチとして「進むための判断材料・基準を掲示していく」というスローガンの下、具体的な指標Criteria(基準)を満たしているか、テスト主導で行っていると書かせてもらいました。そしてそのCriteriaが、上で紹介した機能の小グループの活動に対しても適用されます。

 

Criteriaの構成要素はそれぞれのグループ毎で違う物もありますが、下記は一般的項目として挙げる事ができます。

+仕様を基に作成したチェックアイテム(テストケースのようなもの)がパスするか

+仕様で規定されているキーシナリオ(主な使い方)がきちんと実行できるか

+大きな課題は残っていないか(仕様の不整合や、解決されるべきバグが残ったままになっていないか)

 

簡単ではありますけど、テストの流れと役割を書かせもてもらいました。

次回はよりInterConnectに特化したテストの内容でも書かせてもらおうかな・・と思いますが、全然違う物となるかもしれませんので、その際はご容赦を。

 

 

 

Posted: Friday, July 14, 2006 2:55 PM by yoshiyuki.wada
Filed under:

Comments

No Comments

Leave a Comment

(required) 

(required) 

(optional)

(required) 

  
Enter Code Here: Required

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Page view tracker