MENU

【受入テスト】納品されたとき、発注した側は何を見ればいいのか

チェックリストの項目にチェックが順に入っていき、横に虫めがねが添えられたイラスト

お世話になっております!新入社員の道守みちるです!

「では、受入テストをお願いします」と言われて、画面を開いて、ボタンをいくつか押して、「動きますね!」と言いそうになったことがあります。

でも、その「動きますね」には、なんの保証もありません。わたしが押したのは、うまくいく道を三つ四つだけですから。

納品されたとき、発注した側は何を見ればいいんでしょうか。

この記事で扱うのは、だいたいこの3つです。📝

  • 「動く」と「使える」は、なぜ別なのか
  • 発注した側にしか確かめられないこと
  • 検収したあとの話は、どこから法律の領域になるのか
目次

「動きます」と「使えます」は、別のことでした🤔

作った側も、もちろんテストをしています。ボタンを押して想定どおりの結果が出るか、エラーが出ないか。そこは、発注した側が重ねて確かめても、あまり新しいことは見つからないのかもしれません。

一方で、自分たちの仕事がこれで回るかどうかは、自分たちにしか分かりません。月末だけに発生する作業や、例外的なケースの扱いは、使っている側の頭の中にしかないことが多いです。

【Point】受入テストは、作った側のテストをもう一度やることではなく、作った側には確かめようがないことを確かめることだと思います。

機能をひとつずつではなく、一日を通して見る

わたしが一番なるほどと思ったのは、機能の一覧を上から順に確かめていくやり方だと、「間」が見つからないということでした。

だから、こういう順番で見るのがいいのではないかと思っています。

  • 普段の一日を、最初から最後まで通しでやってみる
  • 月末や四半期など、頻度の低い作業をやってみる
  • 役割の違う人(入力する人、承認する人、見るだけの人)が、それぞれ自分のアカウントでやってみる
  • 今使っている本物のデータに近いものでやってみる

特に最後の、役割の違う人が自分のアカウントで試すというのは大事だと思います。管理者のアカウントだと、何をやっても通ってしまうことがあるからです。

うまくいかない道も、ひとつは踏んでみる

これは、やるのに少し勇気がいります。でも、実際の業務では普通に起きることばかりです。

  • 途中でブラウザを閉じてしまう
  • 送信ボタンを二度押してしまう
  • 数字の欄に文字を入れてしまう
  • 削除したものを、やっぱり戻したいと言われる
  • 権限のない人に、リンクを直接送ってしまう

全部を網羅するのは無理です。ただ、この手の「外れた道」をひとつも試さないまま検収すると、本番で初めて見ることになります。それがこわいと思いました。

見る観点具体的にやってみること
普段の仕事が回るか一日の流れを通しでやってみる
めったにやらない作業月末処理や、年に数回の作業を試す
役割ごとの見え方一般ユーザーのアカウントでログインして確かめる
間違えたときご送信、二重押し、入力ミスをわざとやってみる
別の人に見えては困るもの権限のないアカウントで、見えてはいけない画面を開いてみる
戻せるか間違えて登録したものを、どう直すのか確かめる
※ みちるが今の理解で整理したものです。システムの性質によって、見るべきところは変わります。

実は、テストより前に勝負がついています

受入テストを調べていて、もっとも地味で、もっとも重要そうなことに行き当たりました。

【最重要】「これは違う」と言うには、「こうだと決めてあったこと」が必要です。

決めていなかったことについては、「思っていたのと違う」としか言えません。そしてそれは、相手から見れば新しい要望です。ここでもめると、お互いに苦しいことになります。

だから、要件定義の段階で決めておくことが、最後にここで効いてくるということなんだなと思いました。相見積もりの話で書いた「同じ土俼に乗せる」のも、結局は同じことです。

検収のあとの話は、法律の領域に入ります

先に書いておきます。わたしは法律の専門家ではありません。以下は、公的なデータベースで条文を見てきた、という以上のことは言えません。

e-Gov 法令検索で民法を見ると、第五百六十二条に「買主の追完請求権」という見出しがあります。引き渡された目的物が種類、品質又は数量に関して契約の内容に適合しないものであるときは、買主は売主に対し、修補や代替物の引渡しなどによる履行の追完を請求することができる、という内容でした。

ここではっとしたのは、やはり「契約の内容に適合しない」という言い回しです。契約の内容がはっきりしていなければ、適合していないとも言いにくい。テストの前の話に、また戻ってきました。

なおこの条文は「売買」についてのものです。システム開発の契約がこれにどう関係するのかは、契約の形によります。そこは、専門家に確認してください。IPAが公開しているモデル取引・契約書は、各開発段階で担うべき責務の解説と契約書のひな型を提供しているとのことなので、相談する前に目を通しておくと良さそうです。

結局、何を見ればいいのか

【結論】バグ探しではなく、「これで明日から仕事が回るか」を見る。今のわたしに言えるのは、ここまでです。

何日かければ十分なのか、何件試せばいいのかは、規模も中身も違うので、わたしには分かりません。「気になるところは全部見ました」と言える状態になるまで、としか言えません。

ただひとつだけ、確信に近いことがあります。受入テストの期間を、あとから伸ばすのは、たぶんとても難しい。スケジュールも支払いも、そこを基準に組まれていますから。だとすると、「いつ、誰が、何を見るのか」を予定に入れておくのは、早ければ早いほどいいと思います。

……と書きながら、自分が次に同じ場面になったとき、ちゃんと強く言えるかどうかは別です。そこは、正直なところ自信がありません。

参考にした資料

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次