投稿者名:yasu

前置き 下記のようなシチュエーションのテストを行いたいとなりました。 ユーザAが任意のデータの編集画面を開く⇒ユーザBが同一データの編集画面を開き更新する⇒ユーザAがデータを更新する 上記を自分は「排他制御のテスト」と呼

今回はタイトルの内容について纏めようと思います。 前置き WEBシステムでよく見かける登録・編集・詳細画面のようなページ構成での、保存時の試験の粒度として １．保存後の画面を見て登録データの正誤を判断する２．DBを見て登

今回は、特殊な試験仕様書テンプレートを紹介します。 まず始めに、このブログでよく用いる弊社標準の試験仕様書は、下記のような特徴があります。 大中小項目の区分と前提条件/操作手順/確認内容を記載する欄があり、行ごとに結果記

タイトルの通り、今回は試験仕様書の記載粒度（粗さ / 細かさ）についてです。 前提の話として試験仕様書は、確認内容(操作手順) / 期待結果 / 結果欄で構成されている表で、「確認したいことを行って、期待結果通りになって

背景 以前、ある求人サイトの試験業務をしていました。管理者のみアクセスできる管理画面と一般ユーザーがアクセス可能なフロント画面で構成されていて 管理者が管理画面にて求人データを作成 作成したデータがフロント画面に表示され

先日のテスト業務で、以下のような機能について試験を行う機会がありました。 4つのフロントサイトがあり、それらを管理する管理画面がある 以降このページではサイト1,2,3,4と表現する お知らせ機能があり、管理画面にてお知

先日のテスト業務で、以下のような仕様の検索機能について試験を行う機会がありました。 フリーワード検索 全角または半角スペース区切りで複数キーワード検索とする 検索対象とする項目は4項目 いずれかの項目に対象キーワードが存

QAエンジニアやテストエンジニアのトレンドを追ったり知識を得たりするため、youtubeなどに公開されている動画を定期的に確認、視聴していこうとしています。 今月はJaSST nanoというイベントのアーカイブより Ja

前回に引き続き、試験仕様書を作成しているときに注意していることについて執筆してみようと思います。 前回のおさらい 分岐を含む一連の操作を確認するとき、矛盾が発生しないようにする 本題 今回は試験内容記載のやり方についてで