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