いまさら聞けないテスト・品質の基礎についてまとめてみました！！

ソフトウェアのリリースには不可欠なソフトウェアテスト。IT業界で開発に関わっていれば、聞いたことがない人のほうが少ない言葉ではないでしょうか。

なんとなくは把握してるんですよね。なんとなく、多分テストってこんなことしてて、レポートが来たらバグを…「ああそれね、知ってる」「完全に理解したわ」そんなフンワリ感。

「知ってる知ってる大丈夫だって！」なんて思いつつ、具体的にツッコまれると「ええーっと…」って目が泳いじゃったりしませんか？

それでは、ソフトウェアテストや、「品質管理は具体的になに？」という点についてざっくりと、どんな業務なのかご説明しましょう。

ソフトウェアテストはなんのために必要？

ズバリ、端的にバグを探すためにやっています。ソフトウェアをリリースする時に大切なのは「バグのない製品」（後述しますが、バグがないはないです）を作ること。そのために必要なのがソフトウェアテストです。

ソフトウェアの品質は「期待されている機能をビジネスサイドにきちんと提供できている」かどうかで良し悪しが決まります。つまり、バグが多くて使えない機能だらけになれば、品質が悪いというワケです。そこで開発段階でのバグ探しをするのが「ソフトウェアテスト」という工程です。

・ソフトウェアテストって具体的になんなの？

ものすごくざっくりと簡単に言うと、様々なテストを繰り返してプログラムの中に潜んでいるバグを見つけ出す作業です。

デバッグの方はプログラミングと縁のない一般人でもよく耳にする単語ですが、そのデバッグをするための情報を洗い出すのがこのテストの役目。「知らないものを直すこと」は誰にもできないので、まずは「どこにどんな問題が起きているのか」を明らかにする必要があります。じゃあテスト自体はどういう事をしているかというと、とりあえず動かしてみて頭からしらみつぶし！というわけではありません。

テストの内容や方式はソフトウェアの要件によって異なるので、テストの前に綿密な計画が必要です。

・ソフトウェアテストってどんな種類がある？

工程によって、行われるテストにも種類があります。

開発の段階によって上流工程から下流工程まで複数の工程があるように、テストもいろんなパターンがあるんです。とりあえず動かしてみて絨毯爆撃でバグ探し！というわけではないんです。ちなみに実際に動かして行うテストは「動的テスト」、コードを検証する作業を「静的テスト」と呼びます。

ということで、各工程で行われる代表的なテストをざっくりと紹介しましょう。もちろん、この他にも様々なテストが行われますし、内容はケースバイケースです。

1） 単体テスト・結合テスト

細かな部分でバグが起きていないかを調べたり、単体では問題がなくても、データの入出力や通信などで問題が起きないかを確認します。

2） システムテスト・受け入れテスト

この段階まで来くるとバグがあるかどうかより、エンドユーザーが希望した通りのものに仕上がっているかの確認が、テストの役割になってきます。つまりここでたまに「違う、そうだけどそうじゃないんだなあ…」が見つかっちゃうことも…。

というわけで駆け足ですが、ソフトウェアテストによって問題がある部分を抽出し、デバッグしていくことで、ユーザーが満足する快適なソフトウェアが生まれるというわけです。大事な仕上げの工程ってことですね。

ソフトウェアの品質管理の意味と役割ってなんだ

テストの役割はざっくりですがわかってもらえたところで、ソフトウェアテストが影響する「品質管理」の役割についても少しお話しましょう。

ソフトウェアの品質管理はざっくりと言うと「ビジネスサイドの希望・計画とズレのないシステム」を完成させるため「ビジネスサイドの希望・計画と開発チームの認識のズレ」を修正し、管理していくものです。もっとざっくりいうと「サンプル写真を見て注文した料理を、お客様が期待する見た目と味に近づける作業」が品質管理です。

品質管理を怠ると、せっかく苦労して完成したシステムが希望に沿わないものになる可能性があります。というか、往々にして問題なく完成しても「ちょっと違うんだよなあ…」を経てバージョンアップを繰り返すハメになるのが世の常なのですが、品質管理ができていないと「え、違う、これぜんぜん違う！」になってしまうわけです。

違っても動けばまだしも、あまりにも低品質なソフトウェアはバグだらけで動かないことも多々あります。開発後期になるほど大きくなったズレを修正することが難しくなるので、非常に重要なものなんです。ソフトウェアの品質管理は様々な幅広い知識を必要とするため、専門の民間資格も存在しています。(例：JSTQB等)

実際に掛かるテストの期間と工程ってどうなってるの？

ソフトウェアテストは「単体テスト→結合テスト→システムテスト→受入テスト」の順に、段階を踏んで行われます。

① 始めは部品ごとに動きを確認

② 次はそれらを組み合わせた機能の単位で動きを確認

③ さらに次はシステム全体で動きを確認

という具合に、一度にテストする範囲を広げていきます。このように段階を踏むことで、テストが失敗したときに、どこにバグがあるのかを特定しやすくなります。

ちなみに、実はテストに必要な期間はなんと開発期間の4割から、多い時には8割を超えることもあります。ソースコードを書いている時間より、テストでバグを探して修正している方が長い！なんて珍しいことではないんです。

なにしろテスト工程では、ただバグを見つければ終わりというものではなく、見つかったバグをデバッグして、再度テストをしながらバグがないか確認する時間が必要です。「え、バグ修正したのにまだテストすんの？」いえいえ、修正したからこそ再度テストが必要なんです。

最初のテストでは修正前のバグのせいで見つからなかった他のバグが発見されたり、修正が他に影響して新しいバグを生み出していることもあります。

この工程にかかる時間の見積もりが甘いと「作り終わったと思ったのに、テスト工程が詰まって炎上してる！！」とか「バグが…バグが多すぎて、デバッグの終りが見えない…」なんてことになって、テスト期間が開発全体の進捗に影響が波及してしまうこともしばしば…。

「とりあえず目立ったバグもないし、納期もギリギリだし、テストを切り上げよう！」と納期優先でテスト期間を圧縮すると、システム全体が不安定でバグが多いままリリースされてしまうことも。

当然リリース後に修正対応することになるので、留まるも地獄、進むも地獄。テスト期間はすごく長くなることもある事を前提に、開発期間を見積もっておきましょう！ここを圧縮するなんてとんでもない！

とはいえ、テストも計画が重要なんです。

どんなテストを、どれくらいのコストをかけて行うのか。この点をしっかり計画として立てておかないと、ソフトウェアテストはあっという間に炎上進行に早変わりしてしまいます。

プロジェクトによって、実施するべきテストは都度異なりますし、掛けるべきコストも変わります。テストのための要件をしっかりと洗い出して、必要な内容と適切なタイミングの計画を立ててから実行しないと、せっかくテストをしたのに期待したパフォーマンスを発揮できていない、致命的なバグを見つけられなかった…なんてことにもなってしまうんです。

「テスト計画」から始まり、「テスト分析」→「テスト設計」→「テスト実装」→「テスト実行」→「テスト完了」と、テスト期間中を通して「モニタリングとコントロール」というプロセスがあります。この計画段階で、人的、時間的、環境的、予算的などのさまざまなリソースを配分し、スケジュールを計画します。前の項目でも説明したとおり、テストは開発期間の4割から8割を占めているので、ここを疎かにすると大変なことになるのは一目瞭然ですよね。

ソフトウェアテストの7原則ってなんだ

ソフトウェアテストの7原則と呼ばれるものがあります。ソフトウェアテストの考えとして最も重要であり、さまざまなテストに対して共通の項目と言える考え方です。今回はざっくりと7つの項目をご紹介しましょう。

1） テストは「欠陥があること」しか示せない

テストをして欠陥があることは示せても、ないという証明にはなりません。テスト結果でなにも起きなかったとしても、偶然漏れていただけかもしれないので、「欠陥がない」わけではないのです。

2） 全数テストは不可能

全数テストは、入力される可能性がある全てのパターンを試すテストの方法です。しかし、入力条件のすべての組み合わせを試験するには、パターンが膨大になりすぎて、極小規模なソフトウェアや単純な機能試験以外ではほぼ不可能です。

3） 初期テスト

設計のバグは設計中に発見して修正できれば大きな問題になりませんが、完成してから見つけて修正しようとすると、大きなコストがかかります。そのために、静的テストで設計バグを早期に潰した方が良いです。

4）欠陥の偏在

テストの焦点を絞る時は、過去の欠陥分析やテスト結果を元にポイントを絞るとより効率的です。というのも、不具合は全体に均等に散らばっているのではなく、特定のモジュールを中心に集中的に発生していることが多いためです。

5） 殺虫剤のパラドックス

殺虫剤に耐性を持った害虫が出てくるように、同じテストを繰り返していると新しい欠陥が見つからなくなることがあります。もう大丈夫かな？と思っても、新しいテストケースを実施するとバグが出てくることがあるので、計画的に違うテストケースを試す必要があります。

6）テストは条件次第

そのソフトウェアがどんな条件で使用されるのかによって、テストケースは毎回変わります。どこに重きをおいてテストをする必要があるのか、条件によって大きく異なります。

7）「バグゼロ」の落とし穴

バグが一つもなくなったとしても、高品質なシステムというわけではないのです。品質の基準は「エンドユーザーが希望した仕様」にどれだけ沿っているか、性能や信頼性によっても評価されます。バグがないからといって性能が低ければ、結局は期待はずれになってしまいます。

まとめ

どうでしょうか、かなり駆け足でソフトウェアテストの紹介をしましたが、なんとなくふんわりだったテストのイメージが変わったでしょうか？テストは開発に比べると軽く見られることもありますが、実はものすごく重要なポジションです。完成度が高く安定したシステム開発には無くてはならないものなんです。

オフショア開発が増えた昨今では、ソフトウェアテストもオフショアで行われており、弊社ベトナムオフィスでもテストエンジニアが大活躍してますよ！