
TOP/ ソリューション/ 品質保証・ソフトウェアテスト/ テスト自動化 導入・運用支援
改修のあと、壊れていないかをすぐ確かめられる状態に。
自動テストは、作った後の手入れが続かずに止まりがちです。
範囲の決め方から実装、運用と修正までを支援します。
Mistakes
うまくいかない原因は、技術よりも始める前の想定にあることが多くあります。
よくある期待 | 実際に起きること | 先にやること |
|---|---|---|
「テストは全部自動化できる」 | 毎回同じ手順で確かめるものだけ。画面の表示や、初めて触る機能は人が確かめる | 自動と人の範囲を先に線引きする |
「AIが作るから、人の手間はほぼゼロになる」 | 作る手間は減るが、確認と修正の手間は残る | 「見る人・直す人」を体制に入れる |
「仕様書がなくても、今の画面から作れる」 | 今の動きが「正解」になり、不具合があっても合格になる | 正しい動きを判断できる人・資料を用意する |
「効果が出そうなので、一気に全機能へ広げる」 | 誰も管理できずに放置され、元が取れない | 1つの業務で試し、効果を測ってから広げる |
「導入すれば、バグが減る」 | 主な役割は、前は動いていた所が壊れていないかを速く確かめること | 目的を「変更を安心して早く出せること」に置く |
Fit
右側が多い場合は、手で確かめるほうが安いこともあり、そうお伝えします(→「マニュアルテスト支援」)。
Steps
各ステップの終わりに、続けるかを一緒に判断します。費用に見合わなければ止めることもあります。
STEP 1
アセスメント
自動化する範囲を決める
やること
今のテストを棚卸しし、自動と人の範囲を線引きする。保守の手間も入れて、元が取れるかを見積もる
アウトプット
自動化する範囲の案、費用対効果の見積もり
進めるか、やめるか
STEP 2
試行
1つの業務で試す
やること
効果が出やすい業務を1つ選んで自動テストを作り、減った時間を測る
アウトプット
試作した自動テスト、効果の測定結果
広げるか、やり方を変えるか
STEP 3
本導入
範囲を広げて、毎回自動で動かす
やること
対象を広げ、修正のたびに自動で動く仕組みにつなぐ
アウトプット
自動テスト一式、動かし方・直し方の手順書
誰が直し続けるか(社内か、コウェルか)
STEP 4
運用・保守
直し続ける
やること
画面や仕様の変更に合わせて直す。失敗時は、本当の不具合かテスト側の問題かを切り分けて報告する
アウトプット
定期的な報告(実行結果、見つかった不具合、直した所)
社内に引き継ぐか、続けて任せるか
Rescue
すべてを作り直す必要はありません。今あるテストを1本ずつ確認し、3つに分けます。
仕分け | どんなテストか | 例 |
|---|---|---|
直す | まだ役に立つもの。壊れた所を直して使う | ログインの確認。部品名が変わっただけなので、そこを直す |
捨てる | 直す手間に見合わないもの | 終了したキャンペーン画面の確認。削除する |
作り直す | 確かめる中身がずれているもの | 決済の確認。支払い方法が増えたので、内容から作り直す |
残したものは、 次からは社内でも直し続けられる形(手順書・直し方の決まり)にしてお渡しします。
作った担当者やコードを読める人がいなくても始められます。
Scope
対象 | 中身 | コウェルの関わり方 |
|---|---|---|
画面を通した確認 | 人が画面を操作する流れを、自動でたどる | 中心となる対象 |
システム間のつなぎ目(API)の確認 | 画面を通さず、データのやりとりを確かめる | 対象 |
部品ごとの確認(単体テスト) | 開発者がプログラムと一緒に書く確認 | 対象外(開発者の担当。研修は「QAイネーブルメント」で) |
いちばん効果が出やすいのは、 改修のたびにくり返す回帰テスト(直したついでに、前は動いていた所が壊れていないかの確認)です。
Strength
自動にしない確認まで、同じ会社で引き受ける
自動化に向かない確認は、コウェルのテストチームがそのまま担当します。人が確かめる部分と自動の部分の分担を、1社で組み立てられます。
開発会社として、テストのコードも保守しやすく書く
コウェルはシステム開発やEC構築も手がける開発会社です。自動テストのコードも、製品のコードと同じ目線で、直しやすい構造に書いてレビューします。
2か月で回帰テストの自動化を立ち上げた実績
2週間ごとにリリースするリモート会議システムで、自動化の基盤と回帰テストの体制を2か月で立ち上げました。
Case

リモート会議システム
2週間スプリントで開発する中、手動中心の回帰テストがスプリント終盤に集中し、リリース遅延の原因になっていた事例。

D2C支援プラットフォーマー
販促キャンペーン・在庫引当・外部決済API・OMS/WMS連携など、複数の領域が密につながったECシステムのテストを担った事例。

電機メーカー
10年以上の改修でコードが複雑化し、設計書や仕様書もない「仕様のブラックボックス化」したアプリの品質改善に取り組んだ事例。
FAQ
多くの場合、今のツール(Selenium・Playwright など)のまま進められます。合わない場合は、変える理由と費用もご提案します。
中身で大きく変わるため、一律の数字はお伝えしていません。STEP 1で範囲と効果を見積もってから、ご判断いただけます。
なくなりません。画面の表示や、初めて作った機能の確認は人が行います。
今ある自動テストを読み解き、「直す・捨てる・作り直す」に仕分けるところから始めます。
目指します。手順書と直し方の決まりをお渡しし、必要に応じて引き継ぎや研修も行います。
自動化する範囲のご相談から承ります
自動化に向く範囲と、費用に見合うかの見立てをお伝えします。
Copyright © 2025 CO-WELL Co., LTD. All rights reserved.