テスト仕様書
フリーランスになって、在宅でのデスクワークがメインとなりました。
椅子に座りっぱなしは、良くないですね。
腰が痛くなり、肩が凝り始めました^^;
筆者がお試し中のいくつかの対策を皆様に共有いたします。
まずは、チェアー、コクヨの「イングライフ」という製品を購入しました。(かなり高価^^;)
バランスボールに腰かけているように座面が、グニュグニュ動き、腰の硬直が緩和されます。
次に、マウスをトラックボールに変えました。
親指を動かすだけなので、肩が凝りません。(操作に慣れるまで時間がかかりますが)
そして、猫背矯正ベルト。
星飛雄馬が装着していた「大リーグボール養成ギブス」みたいなベルトです(笑)
作業中に背筋が丸まらないで伸びたままに維持されるので、姿勢を正す効果があります。
ところで、上記の椅子、トラックボール、ベルトは、腰痛、肩こり対策の決定打とはなりません。
やはり、意識して運動することに勝るものはないと思っています。
天気の良い日は、近所をブラブラ散歩、腹筋・背筋を10回ずつ
これらを習慣にしたほうが効果は、ありそうです^^
皆さん、運動は、大事です!

テスト仕様書とは
今回は、テスト仕様書の作成業務を請け負うことによって得た知見をまとめてみます。
筆者は、ユーザー企業の情報システム部門に所属していました。
主に、dbSheetClientで業務システムを開発していました。
全社にわたる大規模な業務システムは、数件で、特定部署に限定されたシステムがメインでした。
そのような事情から、テスト(バグ出し)は、専ら業務に精通した優秀なユーザーに任せていました。
彼らは、プログラムの不備を的確に洗い出し指摘してくれました。
というわけで、この業務を請け負うまで、テスト仕様書というドキュメントの存在を知りませんでした^^;
テスト仕様書は、システム開発の品質を確保するための重要なプロセスの一つであるテスト工程を担保する書類です。
テスト仕様書とは、システムやソフトウェアの機能が期待通りに動作するかを確認するためのテストケース、テスト手順、期待される結果などを記載したドキュメントです。
しかし、規模が小さなシステムを内製化する場合、必ずしも、テスト仕様書を作成する必要はないと思います。
それぞれの状況に合わせて、判断すれば良いと思います。
役割と重要性
テスト仕様書は、テスト担当者がテストを効率的に実施するための「地図」のような役割を果たします。
仕様書が存在することで、誰がテストを実施しても同じ手順で検証を行うことが可能になり、結果のブレを防ぐことができます。
また、テスト仕様書には、各テストケースの詳細手順を記載するため、未経験のテスターでも、確実にテストを実施できます。
さらに、テスト仕様書は、開発工程で想定したシナリオや仕様に基づいているため、システムが本来の要件を満たしているかどうかを確認するためのチェックリストとしても機能します。
これにより、仕様の誤解や機能不足を早期に発見でき、開発後の修正工数を削減する効果も期待できます。
発見された仕様の誤解や機能不足は、基本設計書に反映させます。
そのため、テスト仕様書と基本設計書は、セットで作成することをオススメします。
主な構成
一般的なテスト仕様書は、次のような項目で構成されています。
テスト概要
テストの目的や対象システム、テスト範囲などを記載します。
テストシナリオ
各機能に対してどのようなテストを行うか、具体的なケースを定義します。
例:締め日に請求書を作成する(その1)
テスト手順
テストケースごとの実行手順を詳細に記載します。
例:左メニューより「請求書作成」をクリック、画面上部「年月指定」ボタンをクリック
期待結果
各テストケースにおける期待される結果を示します。これにより、結果の評価がしやすくなります。
例:年月を選択する画面が表示される
結果記録
実行結果と判定(合格/不合格)を記録するスペースを設けます。
不合格となった結果も残せる様式がオススメです。
作成のポイント
明確なテストケースの設定
テストケースは、開発された機能が仕様に合致しているかを確認するためのものです。
そのため、テストケースは明確かつ詳細であることが求められます。
必要であれば、ユーザーストーリーや要件定義書をもとにシナリオを洗い出し、実際の利用場面を想定したテストケースを作成すると良いでしょう。
再現性の確保
テスト仕様書は、誰が実行しても同じ結果を得られるように記述されていることが重要です。
そのためには、各テスト手順を具体的に記載し、設定値や操作手順などが再現可能な形で記述されていることが求められます。
期待結果の明確化
期待結果を明確に定義することで、テスト結果の判定が容易になります。
「期待する結果が何か」を曖昧にしてしまうと、テスト担当者が独自の判断で結果を評価してしまう可能性があるため、具体的な数値や状態を記載することが大切です。
※エビデンスとして、スクリーンショットを残します。
変更に強い仕様書
システム開発は変更が発生しやすいため、仕様書も変更に対応しやすい形式で作成されることが望ましいです。
例えば、各テストケースに識別番号を振り、変更や追加があった際に該当箇所のみ更新できるようにしておくと管理が楽になります。
活用と継続的改善
テスト仕様書は、単なるドキュメントではなく、テストの進捗管理や品質向上のためのツールとしても活用できます。
テスト工程で記録された結果(課題や不具合)は、同種のシステムや次回テスト仕様書作成に反映できます。
また、アジャイル開発では、機能のアップデートや不具合の改修が次々と発生するため、テスト仕様書は、継続的品質向上のために貴重な文書となります。

皆さん本日もお疲れ様でした!
おやすみなさい(挙手)
ディスカッション
コメント一覧
まだ、コメントがありません