読者です 読者をやめる 読者になる 読者になる

テスターのテストによる開発者のためのテスト

システム業界で思ったことをそのまま言葉にしよう

テストってなんだろう?第6回「テストは条件次第」

7つの原則 Foundation Leval JSTQB

あれから1週間。「なそ」です。

 

定期的な更新を心掛け、1週間というサイクルで再び投稿できたことを人類にとっては小さな投稿だが、「なそ」にとっては大きな投稿です。

 

だいたい2回目までは続くんです。三日坊主にすらなりきれない残念状態の「なそ」ですが、今回はやるぞー!

 

というわけで、残すところ7つの原則も2つ。今回は6つ目の「テストは条件次第」です。もう少し具体的に言えば、「前提条件としてプロジェクトが何を優先するか次第で、テストが異なる」ということです。

 

その答えはすべてのものが有限であるからです。例えばですが、QCDをメインに考えるとわかりやすいでしょうか? QCDはQuality(品質)、Cost(資金)、Delivery(納期)の3つですね。これも語り始めると時間がかかるので、スルーさせてもらいます。いつか書きたいものです。

 

Quality(品質)を優先すると、Cost(資金)、Delivery(納期)は大きくなります。

ここでステータスであるQuality(品質)を前回にしなければいけないのは、主に人の命を預かるシステムになります。医療をはじめとするシステムですね。Quality(品質)を優先するので、細部まで見て安全性を高めるのでCost(資金)は高くなり、Delivery(納期)は遅くなります。開発サイクルは長くなる傾向にあるといっても過言ではないでしょう。

 

では、Delivery(納期)が優先されるのはどういった場合でしょう?これはスマホアプリが該当します。多少のQuality(品質)を落としても早く出すことで市場を押さえることができます。またネットにつながる利点を活かして更新頻度を高め、少しずつQuality(品質)を高めていくことができますが、基本的にDelivery(納期)が優先されると思います。そうなるとテストできる範囲が狭くなるので、当然Quality(品質)は下がります。

しかし、Delivery(納期)が早くなる ≠ Cost(資金)が安いは同義ではないです。メンバーの生産性が高い場合結果的に安くなることはありますが、大人数で開発を行う場合、Cost(資金)は高くなるでしょう。

 

最後にCost(資金)を優先する場合は、そもそもテストするかなって感じがしないでもないですが、スモールスタートを行うことが多いです。機能の全部を開発せずに一部だけ開発して使ってみて少しずつ機能拡張していく。そうすると少ない機能を少しずつテストしていくので、先の2つの条件とはまた違ったテストが必要になると思います。

 

って、QCDメインで話が進んでるじゃないですか……

たとえにQCDを出した時点でこうなりますよね。いつかじゃなくて今日書くことになるとは!

 

「前提条件としてプロジェクトが何を優先するか次第で、テストが異なる」ということがわかっていただけたでしょうか?

 

最後に全部大事という強者な上司に出くわしたときはプロジェクトの失敗を覚悟して大いにぶつかっていくべきだと持論を述べておきます。(最終的には火を噴くはずなので、失敗覚悟でやると大いなる経験をすることができます)

 

今回は7つの原則の「テストは条件次第」でした。

次回は7つの原則の最後「バグゼロの落とし穴」です。お楽しみに~ノシ