みなさんはカスタムAppのテスト、どのように実施されていますでしょうか。

今回は、普段弊社で行っているカスタムAppのテストについてご紹介したいと思います。

テストについて

Claris FileMaker のカスタムAppに限らず、システムを開発する工程にテストは欠かせません。

そんなテストですが、対象となるシステム、開発チーム、会社…によりさまざまな形式が存在します。

弊社のテスト

通常弊社では、カスタムAppを作成した開発者がセルフテストした後、別のメンバーがテストをおこなうという方式です。その際テスト資料にそってテストを実施します。

テスト資料は時と場合によりますが、基本的にはカスタムAppを作成した開発者が作成します。

もちろんその資料には、基となる要件定義書や仕様書というものが存在します。

では実際のテスト方法やテスト資料などをご紹介いたします。

テスト紹介

テストの流れです。

1. 開発者がテスト依頼を出す（テスト開始のおおよそ1週間前までに）
2. 誰がテストするかを決める
3. テスト資料準備、テスト前説明などを行う
4. テスト実施と結果のフィードバック
5. 修正
6. 不具合がなくなるまで ４と５を繰り返す

テストのスケジュールは、納品日から概ねの予想はつけられるのですが、あらかじめテスト依頼を出してもらうことで確実にスケジュール調整が行われ、うっかり予定を入れ損ね慌ててテストをする、ということはありません。

テストの準備ができると、実施者は開発者からテスト内容の説明を受けます。

テスト資料には、テストするファイル名、サーバー名、アカウント情報、Claris FileMaker のバージョン、そしてテスト項目があります。形式はエクセルファイル又は Claris FileMaker ファイルが主です。

念のため、テスト開始時にはカスタムAppの納期も再度確認しておきます。

テストは資料に応じて進めるので、資料により難易度や質がかわります。

システムを良く知らなくても進められる場合もありますし、その反対もあります。

手順を考えることやテストデータを準備することも必要な場合もあります。

では実際にテスト資料を見ていきましょう。

テスト資料紹介

２つとも、左側に対応内容や要件が記載してあります。右側にはテスト内容、手順が記載してあります。

これは Claris FileMaker のカスタムAppテストに限らず一般的なシステムテスト資料ではないでしょうか。手順や入力するデータを細かく指定する、しないの差異はあるかもしれません。もし細かく指定する必要があるテストの場合は「1パターンは手順や入力データを指定する、それとは別にテスターの考えたデータでテストしてもらう」というのが良いのではないかと思っています。

資料にないテスト

テスト全般で注意しなければいけない点として、「テスト資料にないテスト」があげられます。

例えば、タブ順の確認、インプットメソッド、レイアウトなどあえてテスト資料にはのらない項目もテストが必要です。特に新規開発のカスタムAppの場合は、この資料にのらないテストが重要になってきます。

テスト後のフィードバック

テストが終わると開発者に結果を記載したテスト資料を渡します。基本はテスト資料に記載された確認内容に対する結果を渡しますが、「テスト資料通りの動作が実現するけれど、その時こんなことも起こりました。これは想定通りですか」などの確認事項も記載します。

テスト時に感じた違和感は、放置することなく開発者に伝えることが大切です。わたしの経験ではありますが、ちょっとした違和感を見過ごした結果、不具合につながっていたことが後になって発覚したことがありました。「あの時見過ごさなければ・・」とならないように、テスト結果の資料にはこまめにメモを残し、開発者にフィードバックするようにしましょう。

「書いてあるテスト内容だけをテストする」、これは時間の都合上やむを得ないかもしれません。ちょっとした改修案件などはそれでも良いかもしれません。ただどんなテストでもテスト項目と項目の書いていない間を読み取る視点、これはテストを行う上で是非持ちたい、持っていただきたいと思います。

困り処、工夫処

パターンはある程度決まっているとはいえ、開発者からは様々な様式のテスト資料が渡されます。

その中で困り処としてあげられるのは、テストの方向が合っているかわからなくなることです。

目的、着地点が不明確なまま「作業」としてテストを行っていくと、ときどきわからなくなります。

そのような時は、テスト資料や報告書、要件定義書などを読み返し、自分の認識を確認しなおします。それでも分からない場合は開発者に質問をします。忙しそうな開発者を思うと気が引けることもありますが

テスト資料がいかようにでも受け取れる記載だった場合、お互いのためにも、ひいてはお客様のためにも、そう思えば質問することは悪くありません。

また工夫処としては、テスト記録のためにも画面キャプチャやテストデータを残しておくことでしょうか。

当たり前と言われそうですが、つい忘れてしまうことがあります。何もかも残す必要はないですが、後で詳細を聞かれることが予想されるテスト結果の場合、再現させるためにもデータは残した方が良いです。その際は使用したデータを書き留めるのは結構大変なのでキャプチャをとってテスト資料に貼り付けるようにしています。量が多い時はキャプチャにナンバリングしてテスト手順と結びつけておきます。

まとめ

弊社のカスタムAppのテストについて紹介をしてまいりました。弊社ではあたり前に感じていることも読んでいただいた方の中には疑問や違和感などを覚えた方もいらっしゃるかもしれません。

システム開発に携わる方にとって切っても切れないのがテストです。テストは品質保証につながる大切なものです。やり方や管理など悩まれている方もいらっしゃると思います。

自分自身も日々悩みながらテストに携わっています。何かもっと良い方法があれば共有いただきたいと思うこの頃であります。

私は最近テスト関連のデータ蓄積をはじめました。結果やかかった時間、納品後の不具合にまつわるデータです。このデータがいつか品質保証、お客様満足度につながる材料になれば良いと思っています。

そしてこのブログが少しでもお役に立てますように。