箸休め回『勉強するとどうなるの？』
こちらは以下のブログのマンガで簡単に説明バージョンです。
そういえばブログに載せた絵の本来の姿はこちらのようですね。
o1にテスト観点を出してもらった結果がエグい
o1(OpenAI o1)はGPTの冠が外れたLLMのモデルです。
o1は思考時間をとることにより、4oよりも高度な推論が可能となっているモデルです。
数学やコーディングのテストにおいて4oのスコアを大きく引き離しています。
そのo1-previewを用いてサンプルアプリのテスト観点を出してもらい、私が出したテスト観点と比較を行ってみました。
- 話を進める前にテストについて大事なこと
- 結論から
- お題と僕が出したテスト観点
- o1にテスト観点を出してもらう
- o1が出したテスト観点を確認
- 私が出したテスト観点と比較
- o1ではどういったテスト観点が出せなかったか
- 私はどういった観点が出せなかったか
- o1が出した観点でテスト項目を作ってもらった結果
- これらの結果からo1のテストの活用について
- o1を使ったこんなテスト作成の流れはどうだろう？
話を進める前にテストについて大事なこと
テストにおいて仕様通り動くかのチェックはとても大切です。
ですが、それだけではテストは足りません。
仕様には書いていない考慮漏れで問題が発生する、端末の画面サイズで問題が発生する、他のシステムと連携で問題が発生してしまうといったことがあります。
数年IT界隈にいる人でしたら、そういったところで本番障害に遭遇して苦労した経験があるかと思います。
仕様通り動くかのチェックは最低限のテスト活動であり、加えて仕様外に目を向け「発想」する必要があります。
テストとは、エラーをみつけるつもりでプログラムを実行する過程である
by Glenford J. Myers (ソフトウェア・テストの技法 第2版)
なぜこの話をしたかというと、これから話すo1の結果に関係があるからです。
結論から
- 結果
- o1活用の考え
- o1にベースとなるテスト観点を出してもらって、人間が暗黙知、経験からテスト観点を追加しテストを作っていく
- 仕様確認である動作チェック部分はo1で作ってしまいスモークテストとする。並行して人間が不足観点部分のテストを作る（o1と人間の分業）
箸休め回『境い目』
箸休め回『境い目』
テスターちゃん２巻の締め切りが10/31で必死に頑張っている作者です。
今は章と章の間の箸休めがないところが多いので一生懸命描いている最中です。
さて、今回は境い目の話です。
作者はここのところハードウェア系の人になっています。
ハードウェア（組み込み系）だとマンガに描いたように特定の境い目ひとつでON/OFFを切り替えてしまうと大変なことになってしまいます。
例えば温度が40度になったらON/OFFにする機械があったとします。
その機械が熱をもって40度になったらどうなるでしょうか？
40度まで温度が上がったら電源がOFFになります。
電源がOFFになるので当然機械の温度は下がります。
そうすると39.9度になるので電源がONになります。
電源がONになるので当然機械の温度が上がります。
そうすると40.0度になるので電源がOFFになります。
ウサコが言うように、これをひたすら繰り返してしまうことになるのです。
なので、こういった場合は40度で電源がOFF、35度で電源がONになるといったようにふたつの境い目を設けます。
このことをヒステリシスというそうです。
ヒステリシス！
— あきやま🏀 (@akiyama924) 2024年10月14日
さては、りんちゃんは組み込み系だな？、
SESSAME(組み込みソフトウェア管理者・技術者育成研究会)の用語集では以下の様に記載されています。
【ヒステリシス(Hysteresis) / シュミット・トリガ(Schmitt Trigger)】《HW》
入力信号、電圧に対して上限下限別々の値のスレッショルドレベルを持つことをヒステリシスといい、上限値、下限値の差をヒステリシス電圧という。
この上限値、下限値のスレッショルドレベルより入力が大きくなるか、小さくなるかを変化のトリガーとするFF(フリップフロップ)をシュミットトリガという
https://www.sessame.jp/knowledge/terms_main_files/terms-ha.html
最後のお題は時間がある時にでも考えてみましょう！
///////////////////////////////////////////////////////
さて、お題について。
人で考えると某マンガに引っ張られそうなので、上に引き続き機械の電源ON/OFFで考えてみます(笑)
とりあえず38度の時を１回確認して終わり、だとテスト不足です。
前提条件が大切になります。
電源がONになっているとき、つまり40度に到達していないときは38度の時は電源ONが期待結果です。
ですが電源がOFFになっているとき、つまり40度まで到達してから温度が下がってきて38度になったときは電源OFFが期待結果です。
同じ38度という温度でも期待結果が前提条件によってふるまいが変わります。
さらに機械によっては、40度に到達しておらず電源ONの状態で38度の時にコンセントやバッテリーを抜き差しする（根本から電気の供給を切ってしまってリセットする）と、電源がONになるのかOFFのままか、といったことも考えたりします。
「勉強する必要あるんですか？今のままでよくないですか？」の質問のレス
「勉強する必要あるんですか？今のままでよくないですか？」
このような質問があったりしたので、「勉強する必要ある？」という動画を作ってみました。
作者の考えもブログの下部に記載しています。
作ったスライド
動画
「仕事まわっているし良くないですか？」は、知識がないため別の方法や問題に気づかない状態
動画の最初にこの話をしています。（他の内容が気になりましたら動画にてです）
「残業もたくさんあるけど、毎回なんとかリリースはできてるし、これでいいか」
という状態だったとしましょう。
本当は今まで通りの結果を得るために、もっと簡単な方法があるかもしれません。
実は問題が発生し始めているかもしれません。
ですが知識がそもそも頭の中にないため、それに気づくことさえできない状態である可能性が高いです。
例えてみます。
"コピー機"を知らなかったとしましょう。
「この資料の複製を作ってくれ」
と言われました。なので一生懸命写生して
「みんなで分担して2時間で終わった！」
こうなりそうです。
そして次頼まれたときも
「前もみんなで分担してすぐ終わったし、残業にはなっちゃうけど今から頑張ってみんなで写生しよう！」
こうなりそうです。
だってこの人は"コピー機"を知らないのですから。
知識（引き出し）がないのでそんな方法があることは発想できません。
思いつくきっかけすらないのです。
知識があると「今まで見えていなかったものが見えてくる」と言い換えられそうです。
「全数組み合わせで500項目もある！？ "ペアワイズ法"を使って項目減らすことができるのに……」
「毎日手動でリグレッションテストを回してるの！？ "自動テストツール"を使えばいいのに……」
「ここのテスト、全部サーバー側のロジック確認なんだから全部アプリを操作して確認しなくても"APIテスト"で戻り値を確認すればいいんじゃないかな……」
ダブルクォーテーション部分は先の例でいう"コピー機"にあたる部分です。
さて、例に挙げたコピー機で話を進めましょう。
これで周りの人も全員"コピー機"を知らなければ幸せかもしれません。
「あぁ、写すの大変だよね。手伝おうか」
そういってくれるに違いありません。
ただきっと
「書類の複製作業が毎回重いんだよなぁ。どうにかならんものか……」
そう思っていることでしょう。
ただ作業者以外の人が"コピー機"を知っていたらどうでしょう？
「書類の複製作業には5人で6日かかります！」
作業する人は"コピー機"を知らないので写生するとするとこうなるでしょう。
けど知っている人は「ええ！？」と思いそうです。
コピー機を使わないのかな……そう思うかもしれません。
「コピー機を使ったりはしないのです……？」
というかもしれません。
けどここで
「コ…コピ……？ いやいやいや無理っ無理です！！ そのコ……コピー機？とやらの使い方は全然わからないですし、今まで複製作業は写生することで回っていたんです。上手くいっているのだからそれでいいじゃないですか」
このような感じでしょうか。
勉強をすると「今まで見えなかったものが見える」ようになります。
"コピー機"の存在に気づいて使い方を学んで、業務プロセスが改善され、今まで残業まみれだったものが定時以内に終わるようになるかもしれません。
勉強は大変なので無理強い（むりじい）はしません。
あなたがやりたいと思ったときに勉強するのが一番です。
そのご褒美は。
知識によって視界が開けて新しい世界を見ることができるでしょう。
テスト分析、テスト設計練習用の仕様とアプリを作ったので共有
こんにちは。今はテスターちゃん書籍２巻作成に追われる作者です。
今回はテスト分析、テスト設計の研修/練習で使うための仕様とアプリを作成したので共有します。
会社の研修や練習でご自由に使っていただいてOKです。
仕様
開発したアプリ
https://jam0824.github.io/warikan/
github
目的
仕様書からそのままテストケースを作ると、仕様に書かれた動作をなぞるだけのテストになってしまいます。けれど仕様に全てのことが書かれていることはありません。
例えば最小値については書かれているけれど最大値は書いていない。例外処理については書かれていないことがあります。
今回用意した仕様は、よくあるメインとなる部分だけが書かれた仕様です。
この仕様に書かれたことだけのテストでは全くテストは足りません。
企画者に質問をしてより具体的にする（仕様の抜け漏れを伝えることで問題の作り込みを防ぐ）、行間を読む、といった必要があります。
この仕様とアプリを使って、テスト分析、テスト設計の練習をしてみましょう。
実際に動くアプリも用意したので、テスト実行の練習もできます。
仕様書に書いていないその他の仕様
以下は仕様書に書いていない仕様です。
研修などの実施者は質問に回答するためにお使いください。
- 対応ブラウザはChrome,Edge,Firefox,Android chrome, iOS safari
- 対応OSはWindows8以上、macOS12以上、Android8以上、iOS14以上
- サーバーとのやり取りはなし。クライアント側での処理のみ。
- リロードすると値はリセットされる
- エラーはポップアップで表示
- 整数以外の文字列が入力に入っていた場合は「整数以外の文字が含まれる箇所があります。」を表示
- 合計金額が空だった場合は「合計金額が空です。」を表示
- 合計金額が999999より多かった場合は「合計金額が999,999円以上です。」を表示
- 割り勘をしたい人数が空だった場合は「割り勘をしたい人数が空です。」を表示
- 割り勘をしたい人数が0だった場合は「割り勘をしたい人数が1人未満です。」を表示
- 割り勘をしたい人数が99より多かった場合は「割り勘をしたい人数が99人を超えています。」を表示
- 金額を固定したい人数が99より多かった場合は「金額を固定したい人数が99人を超えています」を表示
- 固定する金額が999999より多かった場合は「固定する金額が999,999円を超えています。」を表示
- 割り勘の金額が1円を下回った場合は「割り勘の金額が1円未満です。」を表示
- エラー発生時は「一人の金額」「不足金額」の表示は0円にする
- 計算された一人の金額は小数切り捨て
パワーポイントのデータ
画像のデータ
2023クリスマススペシャル「バグバッシュ大会」【全部】
2023クリスマススペシャル「バグバッシュ大会」
ソフトウェアテストAdvent calendar 2023 の24日目のマンガです。
ちまちまと描いていましたが、ようやく完成です。
ゆっくりでも完成できればいいのです(笑)
以下のマンガと、今回描いたノリエ・きゅんチームのまとめとなります。
2023クリスマススペシャル「バグバッシュ大会」その１ - テスターちゃん【4コマ漫画】
2023クリスマススペシャル「バグバッシュ大会」その２ - テスターちゃん【4コマ漫画】
バグバッシュ
一般的に、チームの様々な役割の人が限られた時間の中で手動テストを行いバグを探し出す手法です。
手動の探索的テストのために普段から我々が利用するアプローチとして、バグバッシュがある。エンジニアのチームと関連人員（マネージャー、プロダクトマネージャー、テストエンジニア、その製品に親しんでいる者全員）が「会議」の予定を設定するが、そのセッションでは、関係者全員が製品を手動でテストするのだ。
よく発表される事例で見かけるのは、マンガの様にイベントとしての実施ですね。
メリットとしては以下のようなことがあります。
- 多角的な観点からのバグ探しができる
- 関係者同士が知識を共有して相互に学びあうことができる
- アイディアの共有により改善のきっかけになる
- エンゲージメントの向上（チームワークの強化、コミュニケーションの促進）
イベントとしてのバグバッシュ
作者はイベントとしてのバグバッシュをまだ行ったことがありません。
ですので実施したことが語られているブログを紹介します。
楽しそうなので、そのうち作者もイベントをやってみたいと思っています(笑)
作者が行ったバグバッシュ
作者がどういったバグバッシュを行ったかを記載しておきます。
その時取り扱っていたものは「音声認識」です。
話した言葉を認識（音声→テキストに変換）して、該当機能を実行します。
完璧に音声→テキストに変換できればいいのですが、声や言い方によってはうまくいかない場合があります。
例えば「天気」と言っているのに「ペンキ」と変換されてしまう人がいる……といったことがあります。
AIの再学習で解決するのはコストが高く、「ルール」で変換をすることが多々あります。先の例では「今日のペンキは？」というテキストになっていたら「ペンキ→天気」と変換してしまうような手法です。
大勢で試してその時に発生した誤変換を一気に処理したかったが開催目的となります（バグバッシュとは違う気もしてきたけど…）
行ったこととしては
- 時間は1時間
- 参加者はテスター、開発者、企画者（8人くらいだったはず）
- そのときリリースしようとしている機能に対して実施
このような感じです。
広い会議室でみんながひたすら声を出していました(笑)
誤変換されて機能が実行ができないときはその場で報告して、開発者がその場で即時修正していきます。
これによって、テスターだけでは出せない問題（声質、言い方など）が一気に出せましたし、それ以外にもテストケースを用いたテストでは出なかった機能的なバグも見つけることができました。
他、「そういえばこの場合はこう言うよね」と今まで気づいてたけど特に言うほどでもない問題を共有してもらえる、誤爆で面白い返事があるとみんなで爆笑するなど和気あいあいと実施させてもらいました。
ただ、開発者はお一人が修正専門にはなってしまってはいました。（そりゃそうなりますよね……）
きゅんちゃん姉のセリフの翻訳
きゅんちゃん、またこったにマンガばし買って～
↓
きゅんちゃん、またこんなにマンガばっかり買って～
「おこづかい足りる？あげよっか？」も本当は津軽弁で書こうと思いましたがさすがに伝わらないのでやめました。
「じぇんこあんな？ けらが？」
です。
きゅんちゃん姉の設定
名前：並岡六華（なみおかりっか）
きゅんちゃん（並岡九華）のお姉ちゃん。
青森の役場に勤めている。
ワープロソフト一太郎を自在に操り、役所のみんなから頼りにされている。
それが気に入らないのか、お局様方に嫌味を言われるが本人はそれが嫌味だということにはまったく気づかず楽しくお仕事をしている。
自分では訛っていない方だと思っているが、どこからどう聞いても津軽弁である。
とはいえ周りはみんなもっと訛っているので特に問題はない。
九華（きゅんちゃん）には昔からとにかく甘い。
九華も就職したのに、会うとついついおこづかいをあげてしまう。
家では寒くなると大体ドテラ（はんてん）を羽織っている。
ぞあっ
パロが好きなのと、絵の練習のためにこういうコマをついつい描いてしまいます。
ちなみにトリコ３巻の絵です。
この辺です。
自分のマンガのキャラをAIに学習させてみた[Stable diffusion+LoRA]
僕は絵を描くことが好きだけど、マンガで大量に絵を描くときはメンドイと思うことがあります。
今マンガを描いていてそんな気持ちがわいて「そうだ、AIに自分のキャラを覚えさせて出力させよう」と考えました。
試してみた結果を書こうと思います。
- 今は簡単に絵を学習させるようなサービスはない(2024/5/2現在)
- 構築方法は割愛
- 学習データは使ってもいいです
- そんなことはいいから結果は！？
- ControlNet + LoRAも試してみた
- まとめ
- 僕は絵を描くことが好きなのか、最終成果物が欲しいのか？
今は簡単に絵を学習させるようなサービスはない(2024/5/2現在)
以前、絵柄を学習・出力させるサービスが一瞬出ました。
案の定絵師の間から大クレームが出てクローズしました。
絵師の間では、トレースした絵を自分の絵として発表する人が問題視されています。
そこに絵柄を覚えさせて出力するサービスの登場です。
自分の絵ではなく、人の絵を勝手に覚えさせて出力させてしまう人は出てきてしまうでしょう。
そのようなわけで気軽に試せるツールは残念ながらありません。自分の絵を覚えさせるにしても自分で環境構築・学習を行う必要があります。
僕はLoRA(Low-Rank Adaptation)という手法を使いました。
これは既存のモデルのパラメータに、別途学習したパラメータを追加することで新しいタスクやデータに対応させます。
モデル全部を再学習させるわけではなく、既存のモデルはそのままで、それに新しいパラメータをくっつけることで新しい知識をゲットさせるやり方です。
オプション装備と言えばわかりやすいかもしれません(笑)
構築方法は割愛
詳しい構築方法は記載しません。
sd-scriptsを使用しました。
windowsですと途中tritonがwindowsに対応していないので詰みます。
windowsの方は wsl -d ubuntu といったようにwslを使う必要があります。
また様々なブログに書かれている方法でも結構エラーが発生します。
エラーを調べてどのライブラリが足りないか、バージョンの依存関係など調べてpip installしていきましょう。
学習については以下のような設定で行いました。
学習回数は20回。lossは0.06ほどでこれ以上学習させてもこれくらいでした。
学習データは使ってもいいです
学習データは「テスターちゃん」に出てくるりんちゃんです。
以下のリポジトリにTrainingData.zipを置きますのでどなた様も使っても問題ありません。（エッチな絵はダメ）
GitHub - jam0824/LoRATrainingData: LoRA用の学習データです
タグデータは作るのが面倒だったのでイメージtoテキストのAIで出力させたものをそのまま入れてます。また全てに"rinchan"タグを入れています。
↓吹き出しや背景を消した画像が入っています。
そんなことはいいから結果は！？
結果としては
特定のキャラを出すのはやっぱり難しい。手直しして使う必要あり。
モブキャラを描いてもらうには良さそう
です。
結構イイ感じではあるのですよ。
けどちょっときらら系になるといいますか幼くなるといますか……。
出力を並べてみます。
ControlNet + LoRAも試してみた
ControlNetとは、ポーズや構図を画像で指定する技術です。
それとLoRAでよりイメージしたものに近い絵を出そうと試みました。
こちらは……
下絵には使えそうだけど、これでいけるかというと難しい
でした。
以下のような下絵段階の絵を指定してみました。
出力させるとこうなりました。
イイ感じではあるけど、そのままきれいな線になってくれたら嬉しかったんだけどなーといったところです。
まとめ
自分の絵を学習させて出力させるのは、おおよそそれっぽい絵が出てくることがわかりました。
ただ、オリジナリティがある特定キャラを安定して出すのは今のところ難しそうに見えます。
飾り気がなくてシンプルなキャラならいけそう、または毎度変わってもいいようなキャラ――つまりモブキャラに活用するのは良さそうです。
また、最終的なキャラとして使わずとも、ネーム段階である程度あたりをつけるのにつかっても良さそうです。
僕は絵を描くことが好きなのか、最終成果物が欲しいのか？
AIで絵を出力していて思ったこと。
僕は絵を描きたいんだっけ？
最終成果物（出来上がった絵）が欲しいんだっけ？
マンガであれば、僕の場合は「初心者のみんなにソフトウェアテストの知識を面白おかしくわかりやすく届けたい！」という想いがあります。
それを表現するための絵は僕が描いてもAIが描いても最終的に上のことが届けられていたらヨシとなります。
ならば「出来上がった絵が欲しい」がコスパ/タイパ的には良いです。
実際、この実験を行った目的はそうです。
けどそう考えて、AIで出力された絵を切り貼りしているシーンを想像したとき「僕は面白くないな」と感じました。
僕は「みんなが知識が得られたらそれだけで幸せ」といった聖人君主ではなく、自分自身も楽しみたいわけです。
僕は絵を描くたびに
「今回は可愛く描けた！」
とか
「前よりうまくなってんじゃん～」
なんて毎度まさに自画自賛しています(笑)
自分の手で少しずつ形ができていくのも好きだし、自分が頭の中でイメージしていることがその通り絵に描き表せたときはとても嬉しい。自分の成長を感じたときなんてニマニマしています。
そんな「お絵描き活動」が僕は好きなんだと思います。
だからと言ってすべてをすべて自分で描くのが好きかというと今度は「メンドイ」が首をもたげてくるわけです。
僕はわがままなのです(笑)
なので最終的には
「自分で描きたいところは描く。そうでもないところはAIでいっか」
と自分の中で決着しました(笑)
バグを故障/欠陥/エラーとわけて何がうれしいの？
テスト業界ではバグ、つまり問題のことを故障/欠陥/エラーとわけて呼んだりします。
このことが話題に上がっていたので話を書いてみます。
- 言葉の意味
- エラーにより欠陥が埋め込まれ、欠陥が実行されて故障として現れる
- そんなに言葉をわけてなにか嬉しいの？
- 言葉(名前)は共通理解が大事
- じゃあテスターちゃんの人は社内で故障/欠陥/エラーとわけて話してるんですか？
言葉の意味
それぞれの言葉の意味からです。
故障
コンポーネントやシステムが定義された範囲内で要求する機能を実行しないこと。
JSTQBの用語集からです。難しい言葉が並んでいますね(笑)
簡単に説明すると、アプリを動かした結果、プロフィールが表示されないとかメッセージが送信できないといった「発生した問題(出来事)」を指しています。
ちなみに期待結果との相違を不正(アノマリー)と言ったりしますが今回は置いておきましょう。余計にややこしくなりそうです(笑)
欠陥
作業成果物に存在する、要件または仕様を満たさない不備または欠点。
欠陥は、例えばプログラムで (x < 10)と書くところを(x < 9)と書いてしまったとか、エラーの時の処理を書き忘れたといったような「埋め込まれている問題」を指しています。
その問題の部分(欠陥がある部分)が実行されるまでは表に出てこない――つまり故障という出来事として現れることはありません。
エラー
間違った結果を生み出す人間の行為。
この言葉がテスト業界の人と開発の人で使い方が一番異なる言葉な気がします。
ここは説明そのままです。例えば業務知識が不足していたので間違った設計をしてしまった、前の人が「ヨシ！」と言ってたので僕も「ヨシ」としてしまった、などでしょうか。
開発の人が「エラーが発生してる」といった場合は「僕は寝不足で寝不足で間違ったことをしています」と自己申告をしているのではなく、「故障が発生した」になりそうです。
エラーにより欠陥が埋め込まれ、欠陥が実行されて故障として現れる
まとめると上記のような流れになります。
プロセスがいい加減だった結果、うっかりプログラムを書き損じてしまって、実行したら動かなかった。
こんな感じでしょうか。
欠陥と故障は原因(欠陥)と結果(故障)の関係であり、エラーと欠陥も原因(エラー)と結果(結果)の関係にあります。
また、１つの欠陥から複数の故障が起こる場合もあります。
例えば、様々な場所から呼び出される共通のプログラムで書き損じがあった場合です。
この場合、テストをすると
「機能Aのレスポンスが来ない！」
「機能Bはnullって表示されている！」
このような問題（出来事）を観測できます。故障ですね。
それぞれの出来事について我々はバグ票(この場合故障票と呼ぶの？呼ばない)を記載します。
そして、共通するプログラムを修正するとどちらの故障も発生しなくなります。
別々の出来事(故障)が、共通の欠陥から発生することがあるということです。
同様に、1つのエラーから複数の欠陥が埋め込まれる場合もあります。
そんなに言葉をわけてなにか嬉しいの？
ふわっとした概念に「名前」を付けることによって扱いやすくなります。
名前を付けることで形を持つといったところでしょうか。古くから我々は、様々なことに名前を付けて扱えるようにしてきました。
では、今はひっくるめて「バグ」と言ってみましょうか。
例えば。
レスポンスが悪化する「バグ」があります。
ユーザーからも「バグ」の問い合わせが複数あります。CSからどう対応したらいいか聞かれています。
けれどこの「バグ」の原因となるプログラムの「バグ」がわかりません。
はやくこの「バグ」に対応しなければなりません。
そこで我々テスターはこの「バグ」に対応するために、CS/開発/企画含め緊急の「バグ対応ミーティング」を開くことにした。
さて。
この状況では、レスポンスが悪化する出来事――「故障」が発生しています。
ユーザーからも問い合わせがあって、CS側としては「ユーザーに返答する、故障への対応の方法」を求められています。
ただ開発で調べたけれどレスポンス悪化という「故障」がどこの「欠陥」によって引き起こされているかわかりません。
その状態で、我々テスターは緊急のミーティングを開くのですが、この緊急ミーティングは「何に対応したい」ミーティングでしょうか。
欠陥をどう直すか？いやいやその前に欠陥を見つけるためにどういったテストをすればいいか？
というよりは、まずは「今発生している出来事（故障）」に対応したいのです。
そのために、例えば開発側ではスケールアウト(サーバーの台数を増やす）といったサーバーサイドの対応でしのげるのか、テスター側ではスリープにすれば直る？wifiをつなぎ直せばいい？といったクライアント側での回避策（ワークアラウンド）で対処できるのか、それとも直近の変更をリバート（元に戻す）のか……といった故障への対応方針が優先されます。
このように「名前」を付けてあげることで「何を指しているか」がわかりやすくなり対応しやすくなります。
言葉(名前)は共通理解が大事
エンジニア的に言うと、言葉は通信プロトコル(通信するための約束事)です。
異なると「何を指しているかがわかる」という利点が失われます。
そこでテスト界隈では基本的にはJSTQBをベースとしていることが多いです。
これによって、共通の理解で話ができます。
https://jstqb.jp/syllabus.html
じゃあテスターちゃんの人は社内で故障/欠陥/エラーとわけて話してるんですか？
話してません。
僕はバグ、またはissue(イシュー)と言っています。テスター以外には伝わらないからです。
先ほど書いた通り言葉は共通理解が大事なのです。
例えば開発の人と話すときに「エラーを防ぐプロセスを考えたい」といった場合は意図が伝わりそうでしょうか？
それよりなら「うっかりミスを防ぐプロセスを考えたい」と言ったほうが伝わりそうですね。
ですがこれがテスターだけのミーティングではどうでしょうか？
こちらなら問題なく意図が伝わりそうです。
通信プロトコルは、受け取る相手によって変更する必要があります。
受け取る相手が、こちらの意図を正しく理解できるように、相手に合わせた言葉選びをする必要があるということです。
DockerでPlaywrightを実行/確認するコードの配布【仮想ディスプレイもレポートも見れるよ版】
作者です。
dockerでPlaywrightを実行するDockerfileを書いたので配布します。
dockerを起動すればもうPlaywrightのテスト実行可能です。
あと久しぶりにyoutubeでどう使うかも実演付きで説明してみましたので、そちらもよろしければ見てみてください。
ネットを見ていたら、dockerでPlaywrightをヘッドレス（実行中の様子が見えない状態）で実行する記事はあるのですが、docker内部で自動テストが実行されている様子が見えるようにするにはどうしたらいいか、が書かれた場所が作者が探す限りでは見つからなかったので、それをできるようにしてみました。
通常dockerでplaywrightを実行するときは「できあがったテスト」を実運用する場合なので動いている様子を見る必要がない、といったところはあるかと思います。
ただdockerには「手軽に、かつ自分の環境を汚さないで開発環境を作る」ことにも使われたりします。
あとは簡単にメンバーの自動テスト環境を整えるというようなことにも使えます。
今回のコードはそれがメイン……と言いつつ、ぶっちゃけ作者が「説明ないし作ってみよ～」といったところではありますｗ
テスト結果レポートを見るのもシンプルな形で実現しています。
使い方については、githubに全て説明を書いているのでそれをご参照ください。
次回youtubeは「じゃあこのdockerfileで何してるのさ？」という技術の話をしようかなーと考えています。
いや、マンガの続き描けよという話ですよねｗ
