ソフトウェアテスト品質の基礎
Quality Management.
品質計画
Quality Planning
ソフトウェアの品質を考える場合、
まず目標とする品質をどのように達成するかを、
あらかじめ検討しておく必要があります。
- どんな内容のテストをどのように行うか？
- どのテストは省略しても良いか？
- テストの品質をあげるために、まずやるべきことはないか？
- (ex)ソースコードの命名規則の統一
- (ex)コードフォーマットの統一
- (ex)レビューの開始時期および修正時期
- テストスケジュールをどうするか？
- テストの実施回数はどうするか？
- テストにかかる品質コストはいくらかかるか？
例えば出力文字に対するテストは
ソフトウェアテストで行うより、目視で行った方が遥かに
簡単で時間もかからないかもしれません。
また、テストを実施する前に、
仕様レビューを行って、
テストより前にまずはプログラムロジック的に
問題がないことを確認する必要があるかもしれません。
しかしなんにせよ一番に問題になるのは、
テストにかかる時間(コスト)です。
長すぎればコストが異常にかかることになりますし、
短すぎれば後工程でバグが多発してコストが異常に
膨らむことになります。
この辺のことをあてずっぽうに
経験と勘でおこなってはいけません。
まず計画する、
ということが大事です。
そしてかかる時間とコストを見積もっておかなければ、
忙しさに流されて結局テストが満足に行われない、
作業負荷の平準化がうまくできず忙しさにムラが出る、
といったことになってしまいます。
ただし、
作ったスケジュールは変更されること
を前提に作ってください。
プロジェクトは常に変化しており、
テストがうまく行くこともあれば、
テストが失敗しかなり重大なバグを発見、
修正に多大な時間を要するときもあります。
さて、スケジュールを組むためには
自分のプロジェクトや、
なるべく近いプロジェクトの作成速度をトラッキングをして、
どのくらいの品質コストが実際にかかるか
を計算できるようにしておくことが品質計画の第一歩です。
工数が分からないとどれだけ
テストをどのように組み合わせてしていいかの加減が分かりません。
-
だいたいテストコード量[Line of Code]は元ネタの６〜７倍程度かかる。
- 作成時間は、３〜４程度かかる。
- 同程度の試験をgdb(Eclipseを使用)で行うと３倍程度かかる。
→ テストの修正があってようくメリットが出る
(出戻り試験工数が削減できる)。
といったデータをあらかじめ
過去の情報
として持っておくことが重要です。
かかる工数はプログラムの種類によって変動しますし
(追加してスレッド系のテストが必要とか、
負荷能力テストが必要とか)、
また『プロジェクトの難易度』や
『会社の品質方針』によって左右されます。
つまり会社やその組織／プロジェクト毎にかければ
良い最適値が変動するということです。
また、見積もりに関しては、
以下のような項目もデータを取ると良いと思います。
- Webページ1枚の作成にかかるコストおよび時間
- ソースコード1[LOC(Line of Code)]にかかるコストおよび時間
- Webページ1枚の作成にかかるコストおよび時間
- シーケンスチャートの横棒１本にかかるコストおよび時間
- フローチャートのブロック１個にかかるコストおよび時間
要するに取れるものはなんでもトラッキングしろ。
です。
これらの数値が分かれば、結果的に進捗が分かり、
今日どれだけやれば速く家に帰って
東方妖々夢
がやれるのかということが分かるわけです!! ＜ マテ
ともかく、
品質の80%はマネージメントによって決まります。
何をどうするか。コスト。品質……。
今一度考え直してみてください。
ソフトウェアテストの工数曲線に注意!!
Software tests should do Resource leveling heuristics.
ソフトウェアテストを行なうことにより、
後工程での品質はかなり改善することになりますが、
しかしソフトウェアテストにも工数がかかることも忘れてはいけません。
作業負荷的には結果的に以下のようになります。
ソフトウェアテストを実施する場合、
製造工程で工数が増えることは避けることはできません。
後工程で作業が減ることを信じて耐え忍んでください。
Software tests should do Resource leveling heuristics.
Resource leveling heuristics is the input of Schedule development.
Schedule development output is a Project schedule.
Unit test should be performed by coding phase and the Unit test phase.
Then, a next phase will become happy!
中盤からテストを導入するな!!
A software test must be not coding in a System test!
ちょっと語弊がありますが、
すでにテストが終わっているもの
に対してさらにソフトウェアテストを行うと工数が爆発します。
２重にテストするわけですからね。
例えば、ソフトウェアテストに慣れてきたので、
既にgdbでテストしてきたものや、
目視で確認していたものまでソフトウェアテスト化したら、
作業工数が倍以上になった。というのは悪い例の最たるケースです。
また、ソフトウェアテストを結合フェーズの
忙しいときに行うのもまずいです。
結合フェーズにおいては、
ただでさえ何かと工数が増える時期にあたりますので、
単に工数増としてテストが見えたりすると、
モラルの極端な低下として現れることがありえます。
If a software test is coded in a System test,
then programmers will die!
A project manager will surely be troubled.
品質保証／管理
Quallity Control and Assurance
実際に、ソフトウェアテストを行うと決めた後は、
実行フェーズにテストがちゃんと行われているかどうか確認する
作業が必要があります。
ある程度どんなテストを行うか決めておき
(NULL値、限界値、エラーケース、etc、……)、
そのテストが正しく行われていることを確認するわけです。
テストでリターンで即返りするような
テストだけしているようではまったく意味がありません。
- 仕様がその時点で決定していなくてテストできないなら、
テスト担当者はそこで自分で悩んでいても進みません。
さっさと決めるように動く必要があります。
これにより仕様(スコープ)がより明確になるという副作用も期待できます。
(テストの実施による仕様の詳細化)。
-
書き方が分からないなら、
分かる人にかき方の雛形を作らせるという手もあります。
-
特にどんな試験を徹底してやれば良いか、不明な場合は、
仕様作成者に聞いたり、レビューを実施して方針自体決める
必要すらあるかもしれません。
ソフトウェアテストは、
いわゆるアホにはできません
(プログラミング全体がそうですが)。
アホを出さないためには、
品質に対する組織全体でのノウハウの蓄積や、
展開、いわゆるチーム育成が非常に大切です。
品質コストは単に１プロジェクトで終わるものでなく、
プロジェクトを何回か実施することで回収できるものだ、
ということを理解してください。
ando@park.ruru.ne.jp
