「ソフトウェアテストをお任せください」と書くと、依頼者は完成したソフトを操作してもらう場面を想像するかもしれません。しかし、何をどの条件で確かめるかを考える仕事と、その内容に沿って実際に試す仕事は異なります。片方だけ頼みたい人にも、両方を相談したい人にも、同じサービス名だけでは依頼の違いが伝わりません。
試験・検証を受託する会社のサイトでは、試す前に作る確認内容の資料と、試した後に残す結果の記録を別に示しましょう。何を渡すと相談が始まり、最後に何を受け取るかを対応させると、担当する仕事を説明しやすくなります。この記事では、架空の業務画面を例に、資料の見せ方、受託範囲の表、掲載文と相談文を考えます。
試す仕事には、何を試すか考える仕事もある
テスト設計は、確認する内容や条件、行う操作、想定する結果などを整理する仕事です。テスト実行は、その確認内容に沿って対象を動かし、行ったことと実際の結果を記録する仕事です。サイトでは専門語だけを並べず、「確認内容を作る」「実際に試して記録する」と補います。
例えば、社内で使う架空の「業務画面A」について、案内表示の切り替わりを確認したい場面を考えます。どの状態で、どの表示になるはずかが決まっていなければ、操作して画面が変わったという記録だけでは、期待どおりかを読み取れません。試す前の資料と、試した後の記録が必要になる理由を、同じ場面で見せると分かりやすくなります。
吹田市南金田のテクノプランの公開案内では、ソフトウェアテストについて、設計のみ、実施のみの依頼も受けることを紹介しています。地域の会社を探す人にも、所在地や技術分野に加え、今ある資料からどの仕事を頼めるかが分かる説明が役立ちます。
設計と実行をまとめて受ける場合も、二つの仕事を同じ一行に隠す必要はありません。誰が確認内容を作り、どの時点で依頼者と読み合わせ、実行側へ渡すのかを説明します。社内の担当者が同じでも、作る物と確かめることは分けて伝えられます。
確認内容と、操作して分かったことを別の見本にする
設計の見本では、何を確かめたいか、その確認を行う条件、どの結果を期待するかが読み取れるようにします。細かな試験技法や実際の操作手順を公開することよりも、依頼者が何を読み合わせる資料なのかを示すことが目的です。
業務画面Aの説明なら、「利用する条件によって案内が変わることを確認する」という確認内容と、「条件ごとに、仕様で決めた案内になる」という期待を分けて書けます。これは架空の説明です。実際にその画面を操作した結果や、正しく動くと確かめた実績を表すものではありません。
実行後の見本には、対象とした版や環境、試した範囲、実際に見られたこと、まだ試していないことを対応させます。何をする予定だったかという資料だけを、実施済みの結果として見せないようにします。「確認項目がある」と「その項目を試した」も別の状態です。
大阪市阿倍野区の日誠も、ソフトウェアテストサービスの案内で、設計、実行、結果報告を分けて示しています。自社のページでも、工程名の一覧から、依頼者が読む資料と受け取る記録へ説明を進められます。各社が案内する品質や効果を、共通の保証として使うものではありません。
資料がある依頼と、確認内容から考える依頼を分ける
「実行だけ頼みたい」と言われたときも、資料が存在することだけで、すぐ試せると決まるわけではありません。確認項目が今回の対象に合っているか、期待する結果が読み取れるか、使える環境があるかなど、着手前に確かめることがあります。サイトには、資料を読み合わせる段階を含めて案内します。
反対に、確認内容がまだない相談なら、対象の用途や決まっている仕様、心配している場面から話せる入口にします。資料不足を一律に受託不可とする必要はありませんが、何も分からなくても全範囲を試せるとは書きません。分からない内容を、誰がどこまで調べて決めるかも仕事の範囲です。
| 相談したい仕事 | 最初に読み合わせること | 受け取る物として示す内容 |
|---|---|---|
| 設計だけ | 対象の用途、仕様、確認したい場面 | 確認内容・条件・期待する結果を整理した資料 |
| 実行だけ | 既存の確認資料、対象とする版・環境、実施範囲 | 実施した範囲と結果、未実施の内容が分かる記録 |
| 設計と実行 | 資料を作る範囲と、実行前に確認する時点 | 確認内容の資料と、その内容に対応した実行結果 |
この表は、すべての会社が三通りを受けるという意味ではありません。自社で受ける行を選び、設計資料の形式、結果に含める記録、依頼者が確認する内容を実際の体制に合わせます。見本と一緒に読むことで、「一式」の中に何が入るかを説明できます。
結果には、試した範囲と残った確認を添える
結果の見本に「問題なし」とだけ大きく書くと、試していない機能や別の環境まで確認したように見える場合があります。どの対象を、どの条件で、どこまで試した記録かを、結果の近くで読み取れるようにします。確認した範囲と、ソフト全体の品質は同じではありません。
実行できなかった内容があるなら、その理由と残る確認を記録する仕事も説明します。環境が使えなかった、前提となる状態を用意できなかった、期待する結果が未確定だった、という状態を、合格や不具合なしに置き換えません。結果一覧の空欄が何を意味するかも、見本の中で補います。
業務画面Aの例でも、ある条件で表示を確認したことから、ほかの条件や別の版まで確認済みとはできません。記事や営業資料では、不具合の件数を架空の実績として作るより、確認内容と記録をたどれる見せ方にします。報告を受けた依頼者が、次に何を確認するか話せることが大切です。
不具合の報告と、直す仕事を分けて案内する
テストで気になる動きを見つけて記録することと、原因を調べてプログラムを直すことは別の仕事です。検証を頼むと修正まで当然に含まれると思われないように、報告後の担当と相談先を示します。自社で開発や修正も受けるなら、その範囲を別に説明します。
修正後にもう一度確かめる仕事も、最初の実行と区別して案内します。修正内容を受け取れば自動的にすべて再確認するのか、対象を相談して追加するのかは、会社や依頼によって異なります。担当者が口頭で補っている範囲を、サイトにも短く残しましょう。
確認したい内容を整理するテスト設計と、資料に沿って対象を動かし結果を記録するテスト実行を、分けてご相談いただけます。現在の資料と確認したい場面を伺い、作成する物、実施範囲、結果報告の内容をご案内します。見つかった問題の修正や、修正後の再確認は、担当と依頼範囲を別に確認します。
これは設計と実行を受ける会社向けの掲載文例です。受けない仕事は含めず、報告書の見本や、依頼者と確認する段階への案内を添えます。資格名、対応する道具、人数の紹介だけで終えず、何を任せられる会社かへつなげます。
今ある資料と、確かめたい場面から相談できるようにする
問い合わせ欄では、専門的な試験の種類をすべて選んでもらうより、今ある資料と心配している場面を話せるようにします。「確認資料はあるが実施する人が足りない」「仕様の説明から確認項目を作りたい」という違いが分かれば、最初の読み合わせにつながります。
業務用ソフトの案内表示について、公開前に確かめたいと考えています。仕様の説明はありますが、確認項目の資料はまだありません。確認内容を作るところと、実際に試して結果を報告するところを、分けて相談できますか。まず必要な資料と進め方を伺いたいです。
最初の相談文に、実際の利用者情報、認証情報、開発コードを入れる必要はありません。資料や環境を共有する段階になったら、担当者が案内する方法へつなぎます。相談用の見本も架空の内容を使い、公開した画面を自社の検証実績と誤認させないようにします。
公開前は、設計だけ頼みたい人と、実行だけ頼みたい人の二通りでページをたどります。渡す資料、受け取る物、報告後の修正の扱いが分かるでしょうか。工程名を増やす前に、営業時に聞き直していることが説明されているかを確かめます。
検証の仕事と成果物がつながる会社サイトへ
まず一つのサービスで、試す前の資料と、試した後の記録を並べてみてください。設計・実行・報告のどこを自社が担当し、依頼者がどこで確認するかが見えると、受託する仕事を具体的に説明できます。
みやあじよでは、事業者が確認した受託範囲をもとに、成果物の見本、工程の説明、担当の境目、相談への案内をつなぐサイト制作をご相談いただけます。検証サービスの伝え方を見直したい方は、吹田市のホームページ制作をご覧ください。
