 |
||||||||||||||||
|
||||||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||||||
|
||||||||||||||||
| リスクを測定する | ||||||||||||||||
|
不具合にはリスクの大小があります。システムを停止に追い込むような大きいものから、重要な機能で損害が発生するもの、別の方法により回避可能なもの、ほとんど気づかれないような小さなものまで様々です。 プロダクトが稼動してからリスクが現実の損害となってしまうと、その対応コストは開発時のコストに比べて、とても大きなものになります。当然ですが、リリース前に確実にテストを行い、損害をもたらすような大きな不具合はできるだけ減らしておかなければなりません。逆に、あまり損害とならない問題はあえて修正しないという選択肢もあります。 基本的に、「損害対応にかかるコスト＞修正に掛かるコスト」であるならば修正を行い、「損害対応にかかるコスト＜修正に掛かるコスト」であれば修正を保留するか、見送ります。 修正しない判断を的確に行うことができれば、開発力を効率よく活かすことができるようになるでしょう。 ただし、開発・運用には様々なスタイルがありますので、ユーザの信頼を得るために採算のバランスを無視して品質を高めるケースもあり得ます。こういった考え方についてもチーム内で共有しておくことが重要です。 |
||||||||||||||||
| Web 2.0的プロダクトにおけるテストの流儀 | ||||||||||||||||
|
特に昨今のWebアプリケーション開発において、Web 2.0と呼ばれるプロダクトのテストについて少し述べたいと思います。 Webアプリケーションはパッケージソフトウェアと違いサーバで稼動しているので、万が一リリース後に不具合が発生しても「回収コスト」のような大きな損害は起こりにくい特性があります。なぜなら何か問題が生じた場合は、サーバのプログラムを書き換えてしまえば問題を解決できるからです。 それゆえに品質への意識が希薄になり、前のめりな納期設定やリリース後の追加実装を前提とした開発になりがちなのが現状です。 Web 2.0のプロダクトの特性は「永久にβ版」とも「完成度50%リリース」ともいわれており、テストの観点から見ると、いわば「肉を切らせて骨を絶つ」的アプローチを要求されます。 開発スピードにおいて後手に回るようでは意味がないという局面も多々存在しますので、テストフローも臨機応変かつ狡猾な立ち回りが要求されます。 また、スパイラルモデルでの開発はテストが繰り返し実施されるため、単純にテストを積み重ねていくと、その工数は膨大なものとなり、テスト担当者の負担が増加します。激しい競争に打ち勝つためには、開発者とテスト担当者のチームワークをしっかりと高めておくことが重要だと考えます。 チームワークを高めるためにウノウでは、BTS（バグトラッキングシステム）を用いた開発をしています。次にBTSについて解説します。 |
||||||||||||||||
| BTS（バグトラッキングシステム）を中心とした開発とテスト | ||||||||||||||||
|
ウノウでは案件やバグの管理にBTSを使用し、変更箇所のすべてをBTSのチケットとして記録しています。 テストフェーズでは、それらのチケットの情報を元にテスト作業が行われます。実装とテストが対になる形であらゆる作業のすべてをBTSに記録して開発者とテスト担当者の橋渡しすることで、その間のコミュニケーションロスを少なくすることが可能になります。 詳細な仕様書を作成しない場合などにおいても、BTSにやり取りを記しておけばその代替物としても機能します。BTSの具体的な使用法については、次回で取り上げます。  図1：BTS（バグトラッキングシステム）「Trac」 （画像をクリックすると別ウィンドウに拡大図を表示します） 次に、ウノウにおける実践事例を紹介します。 |
||||||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
-
-
連載
