Weple

ユーザーが見つける前に、先に見つけます

リリース前の品質チェック

登録・ログイン・決済など主要な導線をリリース前にまとめて点検します

バグをユーザーが代わりに見つけているなら、それはもう手遅れなバグです。

QA担当がいないチームの現実

機能を作り、自分で何度か触って、デプロイする。ほかのブラウザでどう見えるか、狭い画面で何が重なるか、入力が空のときにどうなるかを確認する時間はありません。だからユーザーが先に見つけ、そのうち報告してくれる人はごく一部です。

何をしますか

  • 主要導線のE2Eテスト作成

    登録、ログイン、決済、投稿のように、壊れてはいけない導線を、実際のブラウザがなぞる自動テストにします。

  • 組み合わせを変えて繰り返し実行

    同じ導線を、ブラウザと画面サイズの組み合わせを変えながら繰り返し回します。特定の組み合わせだけで壊れるものが、ここで見つかります。

  • クロスブラウザ確認

    Chrome、Safari、Firefoxで同じ導線が同じように動くかを見ます。ブラウザごとに違う挙動を見つけます。

  • モバイル画面の点検

    狭い画面で切れる、重なる、押せないボタンを探します。実際の画面の記録と一緒にお渡しします。

  • エッジケースの探索

    空の値、極端に長い入力、遅いネットワーク、二重クリック、ブラウザバックのように、実運用で壊れる条件をあえて試します。

バグレポート

再現手順、画面の記録、深刻度を添えてお送りします。読んだあとに聞き返す必要なく、そのまま直せる形に整理します。直すものがなければ、なかったと書きます。

こう始めます

  1. URLと主要導線を送る

    サービスのURLと、壊れてはいけない導線を教えてください。一覧がなければ一緒に整理します。

  2. テストの作成

    お預かりした主要導線を、実際のブラウザがなぞる自動テストにします。

  3. 全体の実行とレポート

    主要な導線にテストを用意し、組み合わせごとに回して、出たものをレポートにまとめます。

こんなところに向いています

  • QA担当がいないまま、リリースを控えている個人開発者
  • 機能は速く増えるのに、同じ不具合が繰り返し戻ってくる小規模チーム
  • 決済や会員登録のように、止まると売上が止まる導線を持つサービス

よくある質問

コードを渡す必要がありますか?
いいえ。公開されているURLに対して、ユーザーと同じようにブラウザから操作してテストします。リポジトリへのアクセス権は必要ありません。
ログインが必要な画面も対象になりますか?
なります。テスト専用のアカウントを1つご用意いただければ、ログイン後の導線まで見ます。
バグの修正もしてもらえますか?
この点検に含まれるのは、見つけてレポートにするところまでです。修正まで必要な場合は、1件単位の開発として別途お見積もりします。
どこまで見てもらえますか?
登録・ログイン・決済のような、壊れてはいけない主要導線を基準に、クロスブラウザ、モバイル画面、エッジケースまで見ます。

リリース前に、一度回してみてください

サービスのURLと、壊れてはいけない導線を教えていただければ、まず点検の範囲を整理してお渡しします。

サービス一覧を見る