システムってどうやってテストしてるの?

 

今回はシステムテストのお話です!


 

皆様はシステムをガッツリテストした経験はありますでしょうか?

 

経験のない方は、システムテストって単純に動作を見るだけで「念のため」みたいなイメージがあるかもしれません。

 

いやいや・・そんな甘くないのです。


 

これ、IT業界でよくある問題なのですが「テストお願いします」みたいな感じでざっくり指示は来ても、具体的にどう進めるか定義されないまま進んでしまうケースが結構多いんですね。

 

これやっちゃうと、整理されないまま話が進み > 混乱> ドツボにハマりひどい目にあったりするんです。

 

そんなときに備えて、システムテストの基本を理解しておきましょう!


先に話しておきますと、エンジニアじゃない人がテストをした方が、問題を見つけやすいテストもあるのです。

 

なので、今回の記事はエンジニア以外の方も理解しておくのがお勧め!


 

テストは誰がやるといいの?

 

システムテストって、実際にシステムを作ったエンジニアがやるイメージありませんか?

 

もちろん彼らもテストはします。でも作った人はプログラム側の視点から動作を見るのが精いっぱいなため、ユーザー視点でのテストまでやってられないケースが殆どです。

 

更に言うと、プログラマーはすさまじい数のロジックを組んでるので、どんなに優秀なエンジニアでも、想定外の動作がどうしても発生してしまうのです。

 

これをみんなバグって呼んでますよね。


なので、システムテストは、実際に作った人がやらない方がいいんです。

 

参考までに私の経験を話すと、テスト第1回目は小さいシステムでも100個以上のバグは普通にでます。

 

これは起きて当然の事なので、誰が悪いとか能力の話ではありません。



 

どういう流れでテストするの?

 

システムによって粒度が変わるのですが、基礎となるのは以下の3つです。

 

  • 単体テスト
  • 結合テスト
  • 受入れテスト(UAT)


 

単体テスト・結合テスト

 

まず単体テストと結合テストがどういうものか説明をします。

 

システムってざっくりこんな感じで、複数の機能がセットになっていて、個別の機能を連携させて動かしています。


 

まず「機能」を単体で1つ1つテストするのが単体テスト。


 

そして単体テスト後、複数の機能が連携して動くかどうかをテストするのが「結合テスト」なのです!



このテストは、仕様を理解しているシステムエンジニアや、システムの運用担当がやります。

 

規模が大きいプロジェクトだと、テストをしてそのまま修正まで出来る「テストエンジニア」というポジションの人を使ったりします。

 

受入れテスト(UAT)

 

受入れテストは実際にサービスを使う人・売る人が製品として出して良いかを判定するテストです。

 

今度はシステムの目線ではなく、想定される業務フローに合致したものになっているかを確認します。


簡単に言うとロールプレイングに近い感じです。

 

このテストは想定された業務フローを理解している必要があるので、実際利用するユーザーであったり、クラウドベンダーだったらサービスを売る人であったり、利用者に近い人にお願いするのが一般的です。

 

ちなみにUATは「User Acceptance Test」の略。

 

Acceptance(検収)という言葉の通り、受託開発では検収をもらうためのテスト。

 

検収をもらって→納品完了→入金となるので、これをクリアしないとお金がもらえないのです。


 

テストの流れ

 

テスト用のツールを使う場合も多いのですが、このようなリストを作りテストを行います。

 

実際はもう少し細かくする場合もありますし、項目が多い場合は単体・結合・UATのシートを分けます。

 

そして問題を発見したら「チケット」という修正依頼書のようなものをテスター側が作成します。

 

このチケットを使って修正依頼・タスク管理・完了確認を行うのです。


 

ちなみにチケット管理は外部の管理ツールを使う事が多いです。

※よく使われてるのが、Redmine、Jira、Asanaなど。なければエクセルとか。

 

このやり取りを、問題がなくなるまで検証環境で何度も繰り返すイメージですね。

 

テスト期間中のみ、テスト担当と開発側で毎日ミーティングを行うのも有効な手段です!

 

毎日ミーティングはテストと改修のやりとりで発生する認識齟齬を防止できるぞ!

 

テスト結果はエビデンスとして必要

 

テスト結果で利用した資料は作業完了後のエビデンスとなります。

 

後で問題が発生したとき、テストした時点ではどうだったのか?の証明になりますし、逆にテストが足りなくて問題があった場合は、再発防止策の参考にする事もできます。

 

自社ではなく、他社にシステムを納品する場合は、テスト結果の資料提出が必須なところも多いので、いずれにせよ資料を作っておくと良いかもしれません!

 


 

最後に

 

この考え方を理解しておけば、ある日突然現場にぶっこまれても、テストシナリオが作れるので知っておくと便利です!

 

それとテストを実施するときですが、2人以上で同じ項目を別々にテストすると、本当にこれが起きやすいので注意してください。

 


 

2人体制でお勧めなのが、以下のようにAさんがテスト項目を読み上げ、Bさんが実際に操作して、2人で同時に確認してOKなら、Aさんがチェック表にOKをつける方法。



 

私はこのやり方が一番確実で効率が良いと感じました。

 

この方法ならリモートワークでも、テレビ会議で画面共有をしながら出来ます!


フォロー待ってます!
シェア大歓迎!

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です