非開発者によるソフトウェアテスト:読めないものを検証する

レビューでは見つからないものを、非開発者のテストはどう捕まえるか

コード不要の4つのチェック

• 実行して、リロードする。 「画面が更新された」と「保存された」を切り分けます。費用対効果が最も高いチェックです。

• 別人として実行する。 2つ目のアカウントを使えば、権限まわりの思い込みはすぐ表に出ます。

• わざと間違える。 不正な値を送信し、アプリが黙って失敗するのではなく、明確にそう伝えるかを確認します。

• 何もない状態で実行する。 空の状態は最後に作られ、最もテストされません。

修正につながる報告の書き方

技術用語は一切要らず、3文で足ります。何をしたか(順番どおりに)。何を期待したか。代わりに何が起きたか。「フォームに入力して保存を押した、一覧に項目が出ると思った、リロードするまで一覧は空だった」——これだけで不具合の位置を直接指し示し、解釈の余地を残しません。

そしてこれ自体がひとつのチェックです。一度書き留めておけば、以降のあらゆる変更のあとに実行できます。

報告しても誰も動いてくれないとき

この役割で最もよくある不満は、本物の問題を見つけたのに放置されることです。たいていの原因は信じてもらえないことではなく、報告に着手できるだけの情報が含まれていないことです。

その差を埋めるのは3点です。どのアカウントの、どの環境かを書くこと。特定の種類のユーザーだけで起きる不具合は、別の不具合だからです。毎回起きるのか、たまに起きるのかを書くこと。断続的な事象と常に起きる事象は原因がまったく異なり、どちらかがわかるだけで1時間節約できます。そして期待した挙動を明示すること。半分のケースでは、意見の相違はコードではなく要件についてだったと判明し、それは早い段階で表に出す価値があります。

どれも技術用語を必要としません。これが、仕分けされるだけの報告と、実際に直る報告との差です。

チェックを自分より長生きさせる

非開発者によるテストの限界は、常に技能ではなく、一人の人間が再確認できる量でした。フローを平易な言葉で記述し、それを自動で実行させれば、誰かがフレームワークを習得しなくても、その天井は外れます。

ターミナルは一切必要ありません。TestSpriteのダッシュボードでプロジェクトを作成し、チェック内容を平易な言葉で記述して、アプリを指定するだけです。チームの開発者が同じことをコマンドラインから行いたい場合は、 CLI リポジトリにあります。

経路は2つあり、選択は実質「パイプラインを誰が持つか」で決まります。ダッシュボードから GitHub App を接続する方法はリポジトリへの変更が一切不要で、ビルドがすでに発行しているデプロイに反応します。 GitHub Actions のステップを追加する方法は、チェックをリポジトリ内に置くので、ビルドの他の部分と同じようにレビューを受けられます。

TestSpriteはあなたのチェックをどう恒久的な資産に変えるか

同僚に説明するのと同じようにフローを記述すれば、TestSpriteがそれをアプリに対して実行します。テストコードもフレームワークもターミナルも不要です。ダッシュボードでプロジェクトを作り、製品を指定し、例の3文を書く——何をしたか、何を期待したか、その後に何が成り立っているべきか。

以降は変更のたびに実行されます。この記事の4つのチェックは、手で繰り返すものではなくなり、あなたが別の仕事をしている間も機能し続ける記録になります。

価値は具体的です。何が起きるべきかというあなたの知識が、あなたの頭の中だけに留まらなくなる。それが、その貢献を他の全員から見えるようにし、あなたが次の仕事に移ったあとも残るものにします。