テスターちゃん【4コマ漫画】

ソフトウェアテストの用語、やり方などを4コマ漫画でわかりやすく説明する(予定の)ブログです。脱線も多いです。



新連載「なにそれ?あなたの知らないテストの言葉」

ベリサーブさんのHQWで「なにそれ?あなたの知らないテストの言葉」の連載を始めました!

www.veriserve.co.jp

この連載のコンセプトはテスターちゃんと真逆です。

テスターちゃんは新人さんのためにテストについてわかりやすく説明するマンガです。

ですが新連載は、テスト歴が長い人向けに、そういった人も良く知らないような言葉を紹介するマンガです。また記事も同時に書いています。記事の内容もあまり気を遣わず難しい言葉もそのままに書きたいように書いています(笑)

第1回はFuzz testingです。脆弱性発見に使われるテスト技法です。気になる人は記事に飛んでいただけると(さらにいいねしてくれると!)嬉しいです(笑)

 

「エッセイコミック風」に挑戦してみたかった

テスターちゃんを好いてくれる人も多いのですが、絵柄がイヤという人もそこそこいらっしゃいます。

そこで、もう少し間口が広い絵柄に挑戦したかったということがあります。

それがエッセイコミック風の絵です。

こういった絵はシンプルで一見簡単そうなのですが、絵の記号化(表したいことをよりシンプルに端的に表現する)が進んでいるので難しかったりします。

 

キャラクターはテスターちゃんのキャラ(からちょっと改変)

テスターちゃん読者ならわかるのですが、出ているキャラはテスターちゃんのキャラクターです。

ただし実は大きな変更があります!

テスターちゃんではりんちゃんは実は皆守凛太朗、つまり男の子なのですね。

キャラを考えたときに多様性といったところも取り入れた次第で……。

しかし時代が進むと中々表に出しにくいと言いますか、センシティブな話題になっていき……最近ではその話題を出さないようにしていました。

新連載側では名前は「りんさん」にしています。

 

テスターちゃんで先生役のりんちゃんが苦労している話

テスターちゃんではりんちゃんは頼れる先輩で、どんなことでもそつなくこなしているように描いています。

新連載側では、そんなリーダーでも苦労しているんだよ、というようなことを表現したく思っていました。

結果、りんちゃんが困っている様子、変顔をしている様子が多くなってしまいました(笑)

 

博士的な人が出てきて説明する展開は避けたい

テスターちゃんではりんちゃんが出てきて説明する、リーザ主任が出てきて説明するといった展開が多かったです。

新連載側ではりんちゃんがリーダーで主役です。

リーダーが困った時に、そんなに都合よく博士的な人が出てきて説明してくれることはほとんどありません。現実的ではありません。

エッセイコミック風ですから、できるだけリアリティを求めたい気持ちはあります。

実際にリーダーの人が謎の言葉を尋ねられた時にどう解決していくか、の表現です。

ですので博士的な人が出てくるご都合展開は控えたいと考えています。

……いや、展開に困ったらでてくるだろうけど(笑)

 

テスターちゃんの続きはどうするの?

もはや皆さん覚えていないと思いますが、プロダクトリスク、プロジェクトリスクの話で止まっています。

こちらも進めていきたいと考えていますが……モチベが上がってからです!

ごめんなさい><

今は新連載側を描きたくて……!

 

既に2話まで書き終わって提出済み

既に2話まで描き終わって提出済みです。

ちなみに2話はMutation testingです。

さらに3話も決めていてMetamorphic testingです。

Metamorphic testingについてはJaSST'22 Shikokuで講演していたりします。

88Pからです

speakerdeck.com

 

4話以降のネタはまだ考えていませんので、ネタ大募集中です!

 

テスターちゃん電子ランキング4位と6位&3月から新連載はじまります

お久しぶりです。作者です。

テスターちゃん書籍2巻が出てしばらく経ちましたが……

なんと4位にランクインしていました! わーわー!

うれしい!

Xのポストを見ると、どうやら6位はテスターちゃん書籍1巻のようです。

2巻と一緒に1巻も買ってくださっているみたいですね! わーわー!

最高!

 

テスターちゃんは個人もさることながら実は会社さんで買っていただけることが結構あるのですよ。

ソフトウェアテスト教育の補助教材という位置づけです。

新人さんが入ってきたときに「これに目を通しておいて」で、基礎的な部分を知ることができる、つまり初期教育を部分的に肩代わりできたりします。

もともとは前の職場で「テストの話が難しすぎてわからないから、もっと簡単にわかるのない?」からはじまったマンガですので、ちょうどよいのかもしれませんw

 

ちなみに、僕が勤める会社でもオススメ書籍コーナーにあって「うわー!」となりましたw

 

3月14日から新連載はじまります!

「ぜんぜんテスターちゃん更新してないじゃないか!」

というお声が聞こえてきそうです(^-^;

今はテスターちゃんとは別で、新連載の企画をいただきましてそちらを行っています。

もちろんテスト系のマンガです!

初心者向け……とは逆ですw

 

3/14にリリース予定ですので、もしご興味があれば読んでもらえると作者は飛んで喜びますw

 

……さっそく連載2話目から「し、締め切りを延ばしていただきたく……」と連絡しています(^-^;

だって、その、ずっと出張があってその……(いいわけ

 

クリスマススペシャル『テストチャーターの作り方』

 

クリスマススペシャル『テストチャーターの作り方』

この記事はソフトウェアテスト Advent Calendar 2024の24日目の記事です。

今回は探索的テストの時に使うテストチャーターの作り方のお話です。

 

フリースタイルの探索的テストはマネジメントも実行も難しい

何かバグを見つけたいから全体的に探索的テストする、ということはテストを行っている皆さんは経験があるかと思います。

作者もよく実施します。

この探索的テスト実施によって「あ、そんな問題があったんだ!」ということが色々と見つかります。

ですが、マンガに描いたように何に対して探索的テストの目が通っているか、何に対して探索的テストの目が通っていないかなど、実施範囲の把握が難しくなってきます。

また、メンバーにお任せスタイルだと探索的テストの実施個所に偏りも発生します。メインの機能は深掘りされているけど、少しマイナーな機能は影響範囲にもかかわらずほとんど探索的テストの目が通っていないなどです。

不慣れなメンバーですと「全体的に何か探して」と言われてもどうしていいかわからずに動けなくなってしまいます。

 

テストチャーターを作る

「全体的に見て何かを探したい」を深掘りして分解するともう少しマネジメントしやすい形になります。

この「全体的に……」の理由は「なんか不安だから」がほとんどかと思います。

その不安をもう少し考えていくとこんなことが見えてきます。

「~とかなったらイヤだな」

「こういうことがあったらどうしよう」

これがあなたが想定するリスクです。リスクの識別です。

これができたなら、その列挙したリスクをひとつずつ狙って確認していきましょう。

そのリスクを狙うためのドキュメントがテストチャーターです。

 

テストチャーターのテンプレート

マンガにも書きましたがこんなテンプレートがあります。

 

Explore <Target>

Using <Tools>

To discover <Risk/Information>

by "Explore It!"

<リスク/情報>を発見するために、<ツール>を使って、<ターゲット>を探索する

 

テストチャーターによって、何を発見するためにどこを探索するかがハッキリします。その探索的テストで何をすればいいか、何がゴールかがわかるわけですね。

ちなみに「ツールを使って」になっていますが、これは別に外部ツールを必ず使えという意味ではありません。

何かしらのデータセットを使って、とか、意地悪漢字を使って、など何かしら用いるものを指定します。

マンガでも本当は「情報を使って……」と書きたかったのですが、発見する情報と被ってしまうので「データ/ツールを使って」という形で描いています。

 

他にも以下のようなチャーターがあります。(作者的には一番最後が好み)

My mission is to test <Risk> for <Coverage>

by Tips for Writing Better Charters for Exploratory Testing Sessions - EuroSTAR - Michael D.Kelly

私のミッションは<対象>で<リスク>をテストすることだ

※この方の話の内容的にCoverageは僕たちが思い描くカバレッジではなく、対象や範囲の意味を指していそうです。

 

Look at <Target>

To test for <Test Idea>

by Web API テスト技法

<テストアイディア>をテストするために、<ターゲット>に着目する。

 

とはいえ「想定していない何かを発見したい」もある

こういったことを書くと

「リスクが思い浮かばないからチャーターを使った探索的テストができない!」

となる人もいるかと思います。

蛇足かとも思いましたがマンガの4ページ目にその辺を描きました。

「機能Aに着目して何かしら探す!」といった、ひとまず何か対象に着目して漁ろう、といった形です。

もちろん対象は機能だけではなく、シナリオでも良いです。

フォーカスするターゲットを決めるだけでも、「全体的に何か探す!」よりも実施したカバレッジもわかりますしマネジメントしやすくなります。

 

セッションベースドテストマネジメント

セッションベースドの探索的テストの作者がイメージする流れは以下です。

探索的テストのサイクルが、1回のセッションの中と、セッション間でのサイクルの二重のサイクルになっているイメージです。

 

まずはテストチャーターを用意します。

(例:入力エラーをテストするために、入力ボックスに着目する。時間:15分)

そして時間を区切って(作者は40分とすることが多め)、テストチャーターに沿って探索的テストを実施します。

探索的テストの実施が終わると、様々見えてくることがあります。

(例:入力エラーは問題ないけど表示崩れがいっぱいあるぞ!)

それをデブリーフィングで共有、分析と学習を行い、次のテストチャーターに活かします。

(例:表示崩れをテストするために、出力表示箇所に着目する。時間:30分)

この時、新しいテストチャーターを用意するのか、「テストチャーターのリストを作ってるから次のチャーターをやろう」のように事前に用意したチャーターを実行するかはその時々です。

 

 

箸休め『日々を楽しむコツ』

箸休め『日々を楽しむコツ』

仕事では「目的は何か?」を意識することはとても大切です。

そこがフワッとしてしまうと、やっていることがブレブレになってしまうからです。

けれど、プライベートなことまで目的を考え始めてしまうと大変です。

プライベートのことまでそんなことを考えている人はいるの?と思うかもしれませんが成長を意識している人ほど多いように感じています。

コスパ・タイパを考え始めたら注意

当たり前のことですが、好きなことは好きなようにやればいいのです。

けれど時間やコスパ・タイパのことを意識しだすとそうなりません。

作者の場合です。

僕は絵を描くことが好きです。昔はジョジョの落書きを描いたりして楽しんでいました。

描きたいから描いていました。

ただ描いて、自分で見て「今回は上手く描けた!わーい!」とやっていました。

けれどマンガを描き始めてからは考えが変わってしまいました。

「この落書きを時間をかけて描いたところで何にもならないよな」

「描くのに1時間はかかるし……その時間があるならマンガを描いたほうがいいのでは?」

その落書きを描く目的がないので意味がない。そんなところです。

他にも以下のようなことがありました。

「映画で2時間とられるなら、その時間でもっといろんなことができるのでは?」

「プラモデルを作るのは楽しいけど、それ作って何か意味あるの?」

「ゲームで時間を溶かして自分は何を得られた?」

「アニメを見る意味とは?」

 

まえに実家にいたときに妹に言われたことがあります。

「休みの日くらい生産性を考えないで楽しんだら?」

我慢して「大人」になるとやりたいことがない状態になってしまう

「やりたい!」と思ったことについてアレコレ考えてやらないでいると、「やりたい」と思う気持ちがしぼんでいつしか「やりたい」とも思わなくなってきます。学習です。

「ただただ楽しむ」

この思考・行動が抑制されてきます。

こうなってくると「やろうかな……」と思ったところでこんなことが起きます。

「映画を見ている時間があるなら、その時間でもっといろんなことができるのでは?」

そう思って映画を見るのをやめるのですが、結局その時間にやりたいことが浮かばないので何もしない……そんな状態が発生してきます。

 

メリットもなくタイパも悪い。けどやりたいと思ったことを育てることは大事

好きなことは好きなようにやればいいのです。

その行動が何かの成長につながるかとか、タイパだとか考える必要はありません。

「映画を見たいと思ったから見てみる」

「プラモを作ろうと思ったら作ってみる」

「気になるアニメがあるから見る」

これでいいんです。

それが日々を楽しむコツです。

 

 

 

 

 

 

 

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-previewでは62.7% (42件/全67件)のテスト観点を出せた (全体 = 僕の出した観点とo1が出した観点のマージ後の合計)
    • o1-previewでは機能テストにおいては仕様に書かれた内容までである
    • o1-previewではユーザビリティ、セキュリティ、互換性などの~lity系の観点を出せる
  • o1活用の考え
    • o1にベースとなるテスト観点を出してもらって、人間が暗黙知、経験からテスト観点を追加しテストを作っていく
    • 仕様確認である動作チェック部分はo1で作ってしまいスモークテストとする。並行して人間が不足観点部分のテストを作る(o1と人間の分業)
続きを読む

YouTube動画「私はこうやってマインドマップでテストすることを出す!」

YouTube動画「私はこうやってマインドマップでテストすることを出す!」

作者は会社でよく「マインドマップを使ってテストすることを出そう」という講義をします。

そうすると「どうやって出すか実際に見せてください!」と言われることがあります。 今回の動画ではサンプルアプリの仕様を使って実際に僕がマインドマップを描いていく様子を見ながら、何を考えて描いたかを説明します。

サンプルアプリは前に書いたアプリです。

testerchan.hatenadiary.com

動画

www.youtube.com

 

動画で使ったスライド

speakerdeck.com

 

実際に描いたマインドマップ

Mindmeisterのリンク

箸休め回『境い目』

箸休め回『境い目』

テスターちゃん2巻の締め切りが10/31で必死に頑張っている作者です。

今は章と章の間の箸休めがないところが多いので一生懸命描いている最中です。

 

さて、今回は境い目の話です。

作者はここのところハードウェア系の人になっています。

ハードウェア(組み込み系)だとマンガに描いたように特定の境い目ひとつでON/OFFを切り替えてしまうと大変なことになってしまいます。

例えば温度が40度になったらON/OFFにする機械があったとします。

その機械が熱をもって40度になったらどうなるでしょうか?

40度まで温度が上がったら電源がOFFになります。

電源がOFFになるので当然機械の温度は下がります。

そうすると39.9度になるので電源がONになります。

電源がONになるので当然機械の温度が上がります。

そうすると40.0度になるので電源がOFFになります。

ウサコが言うように、これをひたすら繰り返してしまうことになるのです。

なので、こういった場合は40度で電源がOFF、35度で電源がONになるといったようにふたつの境い目を設けます。

このことをヒステリシスというそうです。

 

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のままか、といったことも考えたりします。

 

 

「勉強する必要あるんですか?今のままでよくないですか?」の質問のレス

「勉強する必要あるんですか?今のままでよくないですか?」

このような質問があったりしたので、「勉強する必要ある?」という動画を作ってみました。

作者の考えもブログの下部に記載しています。

作ったスライド

speakerdeck.com

動画

www.youtube.com

 

「仕事まわっているし良くないですか?」は、知識がないため別の方法や問題に気づかない状態

動画の最初にこの話をしています。(他の内容が気になりましたら動画にてです)

「残業もたくさんあるけど、毎回なんとかリリースはできてるし、これでいいか」

という状態だったとしましょう。

本当は今まで通りの結果を得るために、もっと簡単な方法があるかもしれません。

実は問題が発生し始めているかもしれません。

ですが知識がそもそも頭の中にないため、それに気づくことさえできない状態である可能性が高いです。

例えてみます。

"コピー機"を知らなかったとしましょう。

「この資料の複製を作ってくれ」

と言われました。なので一生懸命写生して

「みんなで分担して2時間で終わった!」

こうなりそうです。

そして次頼まれたときも

「前もみんなで分担してすぐ終わったし、残業にはなっちゃうけど今から頑張ってみんなで写生しよう!」

こうなりそうです。

だってこの人は"コピー機"を知らないのですから。

知識(引き出し)がないのでそんな方法があることは発想できません。

思いつくきっかけすらないのです。

 

知識があると「今まで見えていなかったものが見えてくる」と言い換えられそうです。

「全数組み合わせで500項目もある!? "ペアワイズ法"を使って項目減らすことができるのに……」

「毎日手動でリグレッションテストを回してるの!? "自動テストツール"を使えばいいのに……」

「ここのテスト、全部サーバー側のロジック確認なんだから全部アプリを操作して確認しなくても"APIテスト"で戻り値を確認すればいいんじゃないかな……」

ダブルクォーテーション部分は先の例でいう"コピー機"にあたる部分です。

 

さて、例に挙げたコピー機で話を進めましょう。

これで周りの人も全員"コピー機"を知らなければ幸せかもしれません。

「あぁ、写すの大変だよね。手伝おうか」

そういってくれるに違いありません。

ただきっと

「書類の複製作業が毎回重いんだよなぁ。どうにかならんものか……」

そう思っていることでしょう。

 

ただ作業者以外の人が"コピー機"を知っていたらどうでしょう?

「書類の複製作業には5人で6日かかります!」

作業する人は"コピー機"を知らないので写生するとするとこうなるでしょう。

けど知っている人は「ええ!?」と思いそうです。

コピー機を使わないのかな……そう思うかもしれません。

コピー機を使ったりはしないのです……?」

というかもしれません。

けどここで

「コ…コピ……? いやいやいや無理っ無理です!! そのコ……コピー機?とやらの使い方は全然わからないですし、今まで複製作業は写生することで回っていたんです。上手くいっているのだからそれでいいじゃないですか」

このような感じでしょうか。

 

勉強をすると「今まで見えなかったものが見える」ようになります。

"コピー機"の存在に気づいて使い方を学んで、業務プロセスが改善され、今まで残業まみれだったものが定時以内に終わるようになるかもしれません。

 

勉強は大変なので無理強い(むりじい)はしません。

あなたがやりたいと思ったときに勉強するのが一番です。

そのご褒美は。

知識によって視界が開けて新しい世界を見ることができるでしょう。

 

 

 

 

 

 

 

 

 

 

テスト分析、テスト設計練習用の仕様とアプリを作ったので共有

こんにちは。今はテスターちゃん書籍2巻作成に追われる作者です。

 

今回はテスト分析、テスト設計の研修/練習で使うための仕様とアプリを作成したので共有します。

会社の研修や練習でご自由に使っていただいてOKです。

仕様

speakerdeck.com

 

開発したアプリ

https://jam0824.github.io/warikan/

 

github

github.com

 

目的

仕様書からそのままテストケースを作ると、仕様に書かれた動作をなぞるだけのテストになってしまいます。けれど仕様に全てのことが書かれていることはありません。

例えば最小値については書かれているけれど最大値は書いていない。例外処理については書かれていないことがあります。

今回用意した仕様は、よくあるメインとなる部分だけが書かれた仕様です。

この仕様に書かれたことだけのテストでは全くテストは足りません。

企画者に質問をしてより具体的にする(仕様の抜け漏れを伝えることで問題の作り込みを防ぐ)、行間を読む、といった必要があります。

この仕様とアプリを使って、テスト分析、テスト設計の練習をしてみましょう。

実際に動くアプリも用意したので、テスト実行の練習もできます。

 

仕様書に書いていないその他の仕様

以下は仕様書に書いていない仕様です。

研修などの実施者は質問に回答するためにお使いください。

  • 対応ブラウザは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円にする
  • 計算された一人の金額は小数切り捨て

 

パワーポイントのデータ

docs.google.com

画像のデータ