はじめに
PMとして仕事を始めて1年以上経ちましたが、案件を進めていく上で避けては通れない業務の一つに「テスト」があります。
一言で「テスト」と言っても、実はさまざまな種類のテストがあることをご存知でしょうか。
私は業務をしながらそれぞれのテストがどのようなものなのか覚えていきましたが、理解を深めるためにもここで一度まとめていきたいと思います。
目次
- そもそも「テスト」って何？
- テストの分類及び説明
- テストを「書く」ということ
- 終わりに
1. そもそも「テスト」って何？
テストという言葉自体を知らない人はいないですよね。
でも、IT業界の中での「テスト」って何をすることなのか、曖昧な方もいらっしゃるはず。（というか自分。）
まずはどのようなことをするのか確認しましょう。
テスト・評価の仕事は、エンジニアが開発したハードウェア・ソフトウェア・システムが正しく動作するかのテストをおこない、その結果を評価することです。ユーザー目線で検証を繰り返すことで、製品が世の中に出る前に不具合をなくし、システムの完成度を高めます。
引用元：JOBNET「テストってどんな仕事？派遣でもできるの？」 (テストってどんな仕事？派遣でもできるの？)
要するに、設計通りに作られているか、仕様通りに動作するかを確認する作業ということです。
後述しますが、自社だけでなく他社システムと連携しないといけないケースも多々あります。そのとき、お互いに望む結果が得られるかどうかを確認することがとても大切になります。
もしもテストしないで運用が始まり、バグが頻発したら。。。考えるだけでゾッとしますね。
2. テストの分類と説明
一言で「テスト」といっても実は色々な分類や種類があります。
網羅することは難しいですが、私が業務内で経験してきたことを中心にまとめていきます。
機能試験と非機能試験
大きく分けると、試験は２種類に分けることができます。
一つは機能試験もう一つは非機能試験です。
１つ目の機能試験とは、実装したアプリケーションが設計書通りにできているかを確認するものです。
ここで紹介する内容はとてもざっくりとした内容ですので興味がある方は、ググってみてください。
※( )内は略名：英語名を入れてます。
-
単体テスト（UT：Unit Test）
機能を単体で確認するものです。
実装した機能が期待通りに動いているか、表示がきちんとされているかなど実装した機能単体をチェックします。 -
結合テストA（ITA：Interface Test A）
システム内で作成した機能同士を結合して、期待通りの動作となるか確認します。
単体ではうまく動作していても、結合してみたらうまく動かないということもありうるので、影響しそうなところは確実にチェックが必要です。 -
結合テストB（ITB：Interface Test B）
結合テストAがあればBもあります。
Aとの違いは、結合先が外部システムとなるところです。自分たちとは異なるシステムに繋げるので、思わぬ結果が出ることもあります。
期待通りの結果が出ない時は、原因が自社で開発したシステムにあるのか、外部システムにあるのか調査が必要になることも多いです。
自社以外の方々と連携が必要ですので、実施時期のすり合わせや実装の認識合わせなど、やりとりが自然と多くなりますね。 -
システムテスト（ST：System Test）
結合テストが無事に終わったら、最後にシステム全体のテストをします。
想定される機能が滞りなく行われるか、業務の流れを一通りトレースして問題なく動作するか確認します。 -
※ユーザ受け入れテスト（UAT：User Acceptance Test）
これは開発側が行う試験ではないですが、知識としては必須と思われますので、載せておきます。
システムテストまで完了したら、実際に使用するユーザにシステムを触ってもらい、要件通りに動作するかを確認していただくテストとなります。
UATの結果、「やっぱりここはこうして！」と仕様変更の要望がくることもありますね。
主な機能試験の紹介は以上です。
２つ目の非機能試験とは、アプリケーション以外の部分（サーバの性能、セキュリティなど）がお客さんの要望通りになっているかを確認するものです。
その名の通り、機能以外のものを検証するということですね。
私が経験したテストは性能テストだけですが、紹介致します。
-
性能テスト
想定される上限に近いアクセスをかけ続けて、サーバの許容範囲を確認します。
想定よりもサーバ負荷が高い場合、プログラム上の問題なのか単にサーバのスペック不足なのか調査し然るべき対応を取らなくてはなりません。
想定するアクセスをかけ続けるのは手動では不可能ですので、性能試験用のアプリケーションを使います。
私は**Apache JMeter**というアプリケーションを使いました。
※性能試験と一言で言っても、目的に応じて呼び方が異なるようです。
こちらの参考サイトによると、私が行ったテストはロードテストになると思われます。
参考：Webシステムの性能テスト（パフォーマンステスト）とは？負荷テストなど目的に応じた3つの種類
他にも
- 保守性テスト
- 信頼性テスト
- 移植性テスト
など様々な非機能試験があるようです。
いつかはやることになると思いますが、今回は割愛致します。
参考：非機能テストについて
3. テストを「書く」ということ
動作するかどうかを検証するだけでも立派なテストなのですが、単体テストはともかく、結合テストやシステムテストなど複雑な試験をすることになった場合は、行き当たりばったりなテストですと、間違いなくもれが出ます。
また、同じ内容のテストをしてしまったり、網羅性が担保されなかったりするなど効率が悪くなってしまいますので、きちんとテストシナリオを書くことは重要です。
日々の業務の中で完璧にテストシナリオを書くことは難しいですが、適当にテストをする方が後々のダメージが大きいので、きちんとやっていこうと思います。
ほぼ自分への戒めとしてですが、以下にざっと手順を載せておきます。
- 設計書を元に検証する機能を洗い出す。
- 正常系と異常系のシナリオ（操作内容）を作る。
- シナリオに対して期待する動作を書く。
- 期待値通りに動作するか検証する。
4. 終わりに
テストについてまとめてみましたが、改めて見ると色々なテストを行なってきたことが実感できました。
テストって正直面倒ですし、単純作業の繰り返しになるパターンも多いので心が折れそうになることもあります。
しかし、きちんとテストをしないとバグの発見が遅れたり、要件と違う動作なのにお客さんに納品してしまったりと恐ろしいことが起こってしまう可能性がグッと上がります。
品質を高めてお客さんからの信用と信頼を保つためにも、テストは重要です。
粒度が荒くてテストやり直しを何度もしている私ですが、今後きちんと品質を担保できるようにとの自戒を込めて今回この記事を書きました。
この記事を読んでくださった方で、私と同じような立場の方々、これからテストを行う立場になるかも知れない方々、ぜひ共に頑張りましょう。