若手のプログラム開発者やSEに是非読んで欲しい、テストのコツです。
今回は、長年業務アプリケーションの設計における開発のテストの実施や、導入後の障害発生などで経験した内容となっています。
業務アプリケーションをユーザーに提供する場合、必ず品質の良いものを提供しなければいけません。その際のテストケースを考えるコツです。
まずは画面パターンを網羅することです。
１．どのように画面が遷移するか把握することで、ユーザーが利用する業務を理解すること
２．実際に登録作業を行い、打ちづらいと感じるところは、使いにくいと認識すること。
自分で10回同じ内容を登録したときに、面倒だなと感じる箇所は、ユーザーは絶対に使いにくいはずで、結果的に受入テストの際に修正依頼が来ることがほとんどです。
またプロジェクトあるあるですが、開発者は数回程度しか登録せずに気づけておらず、あとから上位者やユーザーから指摘を受けるため、開発が手戻ったり、モチベーションに影響したりし、スケジュール遅延や関係悪化につながるきっかけになったします。
設計書段階ではなかなか拾えないバグのため、開発者の方の言い分も分かりますが、良いものを提供する1点においては、この打ちづらさを開発段階で拾えると品質が各段に上がります。（むしろ拾って欲しい！）
３．自分で操作を確認した機能は、ユーザーへ自信をもって提供できる、ユーザーからの指摘にも共感できるため、修正依頼の意図が汲み取りやすい。
３については、SE的な要素も含まれてきますが、ユーザーや設計者からの指摘は、少しでも減らしたいし、有効な指摘は開発としても参考になります。そのためには、機能をきちんと自分で動かすことが重要です。
次に、テストを行う際のデータの問題です。
システムの導入については、新規に起業する会社や、初めて導入する企業の場合よりも、既存システムからのシステム移行が多いと思います。その場合、既に業務をユーザーが実施しており、その実務を新システムでもきちんと行えるかが導入の際の一番の課題となります。
その際のコツは確実なデータの用意です。
確実なデータとは、開発した機能が正しいどうかを保証するデータ、GOALです。
１．過去データが存在する場合には、開発した機能で、同じように登録し、結果が同じになることを確認する
２．データ作成の元データから１つ１つが正確であることを証明していった結果のデータ
２の例として、担当する機能にもよりますが、トランザクションなどのより業務に近い機能をテストする場合には、よく他の担当が用意したマスタデータをそのまま利用することがあります。ですがこのマスタデータが間違っていると、本番では動きません。
開発フェーズでは、いろんな機能を複数の人が同時並行に開発しており、機能修正が日々行われています。
過去正しくても、最新では動かないデータだったりし、不具合の原因特定や、テストケース消化が進まないなどよくある障害です。
テストデータは正しいデータを使うこと＝確実なデータの用意が重要です。
テストにおける重要なコツは
確実に正しいことから確認する。揺らぐことのない根幹を作る。
その後、作った根幹から少しづつ確実な範囲を広げていくです。
あと、若手あるあるですが、テストデータを適当に作る人がいます。
ユーザーを仕事に関係のないキャラクタ名にしたり、卑猥なデータにしたり。。。
テストは、テスト結果（エビデンス）を残して証明することで、品質を担保するものです。
その際にキャプチャにおかしなデータが印字されていては納品物になりません。
テストデータは、誰が見ても問題の無い、内容にすること！
機能の開発方法によっては当てはまらないこともありますが、ユーザーが利用する機能の最終系は、絶対に、自分の機能が作ったデータを、自分の機能できちんと消せる（見えなくする）ことが出来ないと、本番稼働に耐えられません。テストの段階で、新規登録した後に修正、参照、削除が無い場合には、絶対に設計不良ですので確認を行いましょう。
修正したら、登録したはずの数字や表示が元の状態にならないなどが無いように。
ただし、権限などので、動かせる機能が変わる場合もありますので、きちんと機能の特徴を理解して、テストしてください。
あと信じられないよくある障害が、
データを真っさらにした状態から新規登録するとエラーになる
プログラムです。開発者は、開発する際に、データを事前に作成しがちで、まっさな状態でのテストを結構しません。いざ本番稼働の時に、新規登録が出来ない！！！という現場いに何度も出会ったことがあるので、これだけは絶対にテストして欲しいケースです！
全部を解説すると大変なので、以下少しでも参考になればと思うテストのコツです。
--------------------------------------------------
①．テストデータは、誰が見ても問題無い内容にすること！
⇒誰が、いつ、どこで見るか分からない。会社としての信用問題！
②．自分機能が作ったデータを、自分の機能できちんと消せる（見えなくする）こと
数字や、表示、が元の状態にならないといけない。
③．移行データについては、機能で表示して更新、削除が出来る事を確認する。
④．データを真っさらにし新規登録や照会機能を行った時にきちんと動作する事出来る事。
⑤．テストは機能から作ったデータで最後まで動作することが出来る事。
⑥．大量データを事前に作っておくために、データパターンを1セット作っておくこと。
⑦．エビデンスを取ること
⑧．データベースを事前に確認しておくこと。
⇒対象以外のデータにも更新していないことを確認。
⑨．データベースの値を確認すること。
⑩．削除データを含むテストを行い、件数からきちんと除外されていることを確認する。
⑪．ＳＱＬの実行を集計や参照などでデータベースの値を確認する場合には、まずCOUNTを取って件数を確認しておくこと。
⇒データが多すぎるとＳＱＬが返ってこず、無駄な時間になる。
⑫．排他制御のテストを行うこと。
⑬．機能のフィールドにマックス値を入れてテストを行う。
名称ならＷＷＷ、数値なら最大値。
⇒画面や帳票など表示が切れていないか。値を計算している箇所で落ちないか。
⑭．取り扱うＤＢ、ミドルウェアでの禁則文字の確認。
⇒文字化け、プログラム処理のエラーが発生しないかどうかを確認。
⑮．採番ルールの確認。最大値を振り切った時の処理がどうなっているか？
⇒ループしているか、それとも処理が止まってしまうか。
⑯．WEBの検証を行う場合にCOOKIEを消すことを忘れずに
--------------------------------------------------
本番稼働後に障害が発生してしまうと、誰も幸せになりません(笑)
上記の事例は、本当に体験した障害で、やっとけばよかったっと後から後悔するものばかりです。
テストは地味で面倒ですが、少しでも品質を上げるために参考にしていただければ幸いです。
ちなみに、確実に正確なことを証明する方法として、テストツールを作ることもお勧めです。個人的は、開発が倍になりますが、結果的に早い気がしますが、アジャイル開発が流行の昨今は、なかなか難しいのも事実です。繰り返しテストすることが想定した対策も心がけましょう。
次回は障害発生時の対応になります！
Comments