はじめに

こんにちは!
キャスレーコンサルティングの筒井です。

エンジニア2年目になってから、責任のある仕事を任せてもらえるようになり、
よりユーザーの目線や品質のことを考えるようになりました。

本日は皆様と一緒に「品質」について、考えていきたいと思います!

いきなりですが、 皆様は普段、ソフトウェアの「品質」について考えることはありますか?
「品質」と聞いて、どんなことを思い浮かべますか?

皆様が普段、使用している無料のアプリケーションソフト等を思い浮かべてください。

使用する際や、選定する際、品質までこだわることは、あまりないのではないのでしょうか。
それは、品質が良いのは当たり前だからです。

そんな世の中だからこそ、いま、「品質」について考え直してみませんか?

内容としては基礎的ですが、
新人プログラマの方は一緒に学べる内容に、
ベテランエンジニアの方は改めて、おさらいできる様な内容となっています。

では、「品質」とは何なのか、どのように「品質」が良いかを確認するのか、を見ていきましょう。

1.品質とは

品質とは

ここでは、そもそも「品質」とは何か、ということをお話します。

一言に「品質」といっても、誰にとっての品質かによって重視される部分が変わります。
まずは、プログラマの観点
そして、エンドユーザーの観点

これを読んでくださっているほとんどの方は、プログラマにあたるのではないでしょうか。

私たちプログラマにとっての品質というのは、どんなものでしょうか。
・バグがないこと
・ソースコードがきれいで読みやすいこと
・保守しやすいこと
…などが挙げられます。

つまり、プログラマにとっての品質は、ソースコードの品質といえます。

一方、エンドユーザーにとっての品質はどんなものでしょう。

・不具合がないこと
・使いやすい、見やすいこと
・速いこと
などが、あるかと思います。

エンドユーザーにとっての品質は、アプリケーションソフトウェアの品質といえます。

ここでお伝えしたいことは、
品質は、立場によって意味が変わるということです。

ソースコードが読みやすいか、保守しやすいか、ということは
実際に使っているエンドユーザーにとっては、関係のないことなのです。

続いて、プロジェクトにおいて重要な要素である、QCDについてです。

QCDは、以下の3つの言葉の頭文字をとった言葉です。

  • Quality(品質)
  • Cost(費用)
  • Delivery(納期)

Quality First」という言葉があるように、この3つのなかでも特に重要なのがQualityです。

費用を安くしたいからといって、バグだらけのアプリを作ってはいけませんし、
納期を早めたいからといって、未完成のまま納品もしてはいけませんよね。
かといって高品質だからなんでも良い、というのはNGです。

QCDの3つを、バランスよく満たすことが重要です。

品質が悪いとダメな理由

ここでは、なぜ品質が悪いとだめなのか、品質が良くないとどこまで影響がでるか考えてみましょう。

例えば、A社がB社に対し顧客管理システムの導入を依頼したとします。
B社はシステムを完成・納品しましたが、そのシステムは正常に動かず、業務に支障が出てしまいました。

この時、B社が作った品質の悪いシステムによって、どんなところに影響が出てしまうでしょうか。

A社においては、システムエラーによって業務が進まなかったという点で影響があるのはもちろんのこと、
システムを開発したB社自身も、依頼通りのシステムを作れなかったことで信頼を失ってしまいます。

さらに、A社の業務が止まったことにより、その顧客にも影響が及びます。
結果として、A社においても顧客から「対応が遅い」というレッテルを貼られてしまうかもしれません。

つまり、開発会社と直接関わりのあるところだけではなく、
提供する先にも影響が及ぶ可能性があるのです。

たったひとつでさえ、品質の悪いシステムを作ることによって、ここまで影響が出てしまうんですね…。

バグとテストと品質

そもそも、「バグ」とはコンピュータプログラムの誤りや欠陥のことです。

つまり、「無いほうが良いモノ」ではありますが、一般的にバグがないことは証明できないのだそうです。
これは「悪魔の証明」と同じですね。
(※あること(存在すること)は証明できても、ないこと(存在しないこと)は証明できないということ)

そのため、テスト工程で「正常動作」を保証します。
あらゆる使い方をしても、「正常に動くこと」を確認していくのがテスト工程の意味です。

ここで重要なのは、テスト工程で品質を高めるのではない、ということです。
テストは品質の測定だけが目的のため、品質は事前に設計・製造段階で作り込んでおく必要があります。

テストで品質を上げよう!と思っても、残念ながらそんなことはできません!

2.ホワイトボックステスト

ホワイトボックステストとは

ではここから、 品質を測るための実際のテスト手法についてのお話をしていきます。

まず、ホワイトボックステストについてです。
ホワイトボックステストとは、プログラムの内部構造をテストする手法です。
設計書ではなく、プログラムそのものを見ながらテストを行っていきます。

ホワイトボックステストの代表的な例として、「テストカバレッジ」があります。
これはプログラムに対して、どれくらいの範囲をテストしたかを測るものです。
多くの場合は、ツールを用いて確認します。

ホワイトボックステストのメリットとデメリット

【メリット】
・80%程度のカバレッジを達成することで、ブラックボックステストを効率よく実施できる
・ブラックボックステストではデッドコードの存在がわからないため、あまりにも酷いケースを排除できる
・単純なミスを排除できる

【デメリット】
・全てを網羅しようとすると時間がかかる
 →担当者や機能ごとに一部抜き出してテストする方法をとることがある
・カバーできない範囲がある
 ・プログラムのループ部分
 ・仕様全体のバグ
 ・データによって発生するバグ   …など
 (※これらはブラックボックステスト等で摘出する)

3.ブラックボックステスト

ブラックボックステストとは

次に、ブラックボックステストについてです。

ブラックボックステストはプログラムの内部構造を見ず、
プログラムをブラックボックスとみなしてテストを行います。

基本は、入出力と振る舞いについてのテストとなり、以下の4つに該当します。
①入力
②出力
③計算
④保存

基本的な入出力のテストには、以下の2つがあります。

  • 同値分割
  • 境界値分析

簡単な仕様のプログラムを例に、2つの手法でテストをしてみましょう。

【仕様】
2種類の試験A,Bがあり、それぞれ点数は0~100点の間である。
合計140点以上で合格で、どちらかが60点未満であれば不合格と表示する。

【プログラムの処理】
①どちらかが数値でなければ「エラー」
②どちらかが0~100の間でなければ「エラー」
③どちらかが0~59の間であれば「不合格」
④合計が140未満であれば「不合格」
⑤それ以外「合格」

①同値分割 でテストをすると、以下のような図となります。

②境界値分析 でテストをすると以下のような図となります。

二つの図の違いは何でしょうか。

あまり変わらないように見えますが、「」を見るか、「」を見るかが大きな違いとなります。

①では、「不合格」になる値をテストし、
②では、「不合格」か「合格」かの値をテストします。

プログラムの特性上、「境界付近」でバグが良く見つかります。
そのため、②の境界値分析のほうが効率よくバグを見つけ出すことができます。

ただし、注意するべきは「0」(ゼロ)です。
プログラム上、0が入力可能である場合、0は常に境界となります。
そのため、0は特殊な数値として扱うようにしましょう。

ブラックボックステストのメリットとデメリット

【メリット】
・仕様と見比べて、正しいかどうかを確認することができる
・画面上の見た目や使いやすさを確認することができる

【デメリット】
・仕様のみを見るため、イレギュラーなケースの確認が難しい
・テスト仕様書の作り方や操作方法など、テスト設計者の熟練度により、網羅できる範囲や工数にばらつきが出る
 …など

ホワイトボックステストとブラックボックステストの、2つのテスト手法をご紹介しましたが、
両方ともメリット・デメリットがありますし、もちろん、他のテスト手法もあります。

どちらを使った方が良いとは一概には言えませんので
何を確認したいか、その時の状況を見てうまく組み合わせることが大切です!

4.実際に気を付けるべきポイント

気を付けるべきポイント5選

テストの手法等は調べればいくらでもヒットするけれど、それでも品質に問題があることを検知出来ない!
ということは、よくあります。

そこで、実際の現場でどういったことに気を付けるべきかをご紹介します。

①もぐらたたきをしない
テストは考えてから実行するものです。
動かしてみて、たまたまバグが見つかった、はNGです。

②単なる組み合わせテストをしない
明確な目的をもってテストケースを作成しましょう。
例えば、入力なら境界値分析、複数入力ならディシジョンテーブル…など。
テストケースを増やすことに力を入れる、はNGです。

③アーキテクチャの問題を分ける
単機能で独立していれば発生しないバグは多くあります。
これはアーキテクチャの問題であり、多くの組み合わせをやってみる必要はありません。
(例:データダウンロード中の登録作業など)
これらはシステムの作り方の問題です。

④低品質の原因を想像する
どんなバグがあったか、よりも、なぜそのバグが発生したか、を想像しましょう。
開発の段階か、設計の段階か、そもそもの機能なのか、難易度なのか…を考え、
似たような箇所のテストケースを考えましょう。

⑤忙しく働く人を想像する
システムを使う人全てが、「普通」に使ってくれるとは限りません。
忙しい人がこのシステムを使ったら、2画面で操作をするかも…?
といったテストケースを想像しましょう。
開発側が想定しない使い方というのは、忙しい現場で発生します。

さいごに

お疲れ様でした。
品質についての考えは、最初と比べて変わりましたでしょうか。

変わった方、スバラシイ!
変わらなかった方、スバラシイ!

アプリケーションソフトを作る上で、品質は切っても切れない関係となり、付きまとう存在となります。(笑)

この記事を読んでくださった皆様にとって、何かプラスになれば良いなと思います。

以上です。
最後まで、ご覧頂きありがとうございました!

つつい
Zero-In つつい
新卒入社2年目のエンジニア。受託開発を担当中。