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

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



ChatGPTを用いたTDD part.1 (TODO用意編)

ChatGPTを用いたTDD

作者こと私です。

本記事はソフトウェアテスト Advent Calendar 2023 4日目の記事ということで、今回はマンガではない話をします。

ChatGPTを使ってTDDを試してみます。

ネットを検索するとFizzBuzzなどばかりで面白みがないので、今回は多少使えそうなツールを作ることを目標とします。

 

今回はテストコードもchatGPTで作りますが、テストコードは自分で書いて、プロダクションコードをchatGPTに書いてもらうというようなTDDをを行うと、ChatGPTで意図した結果を得られるコードが書けそうでした。

この記事で書いたお題などは練習のお題としてお好きに使っていただいて構いません。

 

記事は本記事を含め計7本です。

ChatGPTを用いたTDD part.2 (最初の実装編)

ChatGPTを用いたTDD part.3 (TODO実装続き)

ChatGPTを用いたTDD part.4 (Mock編)

ChatGPTを用いたTDD part.5 (Integration test編)

ChatGPTを用いたTDD part.6 (最後の部品作り編)

[END]ChatGPTを用いたTDD part.7 (実行ファイル作成編)

最後の所感

作った成果物

作るもの

私は近頃仕事でtopコマンドの出力を眺めることが多いです。

topコマンドはシステムのCPU使用率やメモリを確認できるコマンドです。

1回の実行でその時の状況がわかります。

これを連続実行してCPUやメモリの変化を時間で追います。

以下は3回連続で実行させたものです。上にシステム全体のCPU使用率などが表示され、その下にプロセスごとの表示がされています。

(dockerでcentosを立ててtopコマンドを実行した結果)

私は全体傾向を追っていくことが多いです(取り扱っているモノがシステム全体のため)

今回は全体側のCPU使用率、メモリ使用率を以下のように時系列で表にするコードを書きます。

 

TDDの流れ

詳しい説明は他のブログに任せるとして以下のことを繰り返して進めます。

  1. TODOリストを書く
  2. TODOリストから一つ選んでテストを書く
  3. 全テストコードを実行させて加えたテストでレッド(エラー)を確認する
  4. 最短でグリーンになる実装を行う
  5. 全テストコードを実行させて加えたテストでグリーンを確認する
  6. リファクタリングする(詳細の実装、重複コードの除去など)
  7. 全テストコードを実行させて加えたテストを実行し結果を確認する
  8. 6~7を繰り返し、すべてグリーンになったら2へ戻る

TODOリストを作る

続きを読む

技書博9に参加してきました!

技書博9に参加してきました!

2023/11/25(土)に技書博9があり、久しぶりのイベントサークル参加をしてきました!

今回はフリーペーパー企画があり、マンガはそれで用意したものです。

金曜日に会社から帰ってきて

「フリーペーパー描いてない!」

ということに気づき、急いで話の内容を考えて、今まで描いた漫画のコマを使って夜なべして描きましたw

技書博は客層のほとんどが開発者のため、開発者に向けて描いています。

最後のコマが一番言いたいことです。

QA側からこのような提案をすることもありますが、開発者側から相談をしてくれるのも嬉しいものです。

 

ちなみに配布版は某警部の目は隠しています(笑)

 

当日

夜なべをしたので眠い目をこすりながら会場へ向かい、セット完了!

そこで大きな忘れ物に気づいたのです……。

 

「8巻がないーーー!!」

 

やらかしました。

まさかまさかの売り物を忘れてくるということをやらかしました!

フリーペーパーに「忘れ物に注意」みたいなことを書いておいて一番大事なものを忘れてきてるのでどうしようもないです。

見本用に2冊持ってきていたので、それを急遽売り物に。

で、開始直後に売り切れると(泣)

けどまぁ、ないものは仕方がないので、開き直って

「各内容は独立してるから大丈夫です!」

といった説明をさせてもらっていましたw

実際、巻をまたいで話はつながっていないし!

 

やっぱり睡眠不足はダメですよ。人類の敵です。

あとペンも忘れてきてたし。

 

お弁当

技書博9,スペース参加費がまさかの1000円でした。(普通は8000円程度)

それでこのお弁当がついてきた!!

絶対お弁当代だけで1000円超えてるだろ、とツッコみたくなりましたw

採算度外視弁当で!

ありがたい!おいしい!ヤバイ!語彙が消える!

他にも3種類あって、どれもゴージャスなお弁当。

どうやら技書博はサークル主への待遇がよいようです。

卓も半分ではなく1卓まるまるですからね。

……テスターちゃんはもう1卓ないと置けないというね。

 

戦利品

 

結構うろうろすることができましたので、ご挨拶がてら回っていました。

にゃむねこさんのところでは「仕様ですTシャツ」をゲットです。

少し暖かくなってからの登壇はこの仕様ですTシャツで登壇したい!

Thunder Clawさんのところでは「いやAndroidの実機でテストしてますよね!?」というツッコミを受けながら「Androidを実機でテストしろ!」の本を買っていましたw

品質公団さんのところでは「伺か」本!

いや絶対今の人は知らないでしょ、という本です。昔ハマってて懐かしくて買いました。(春奈のことをうっかりさくらと言って話していてごめんなさい)

ワニのトートバックはariakiさんのところ。ひっそりほしいものリストをプレゼントしたのですがそのお礼ということでありがたくもらってきました。サイズ的にお買い物バッグに……!(日本酒を入れてください、という指示はうけた)

 

売れ行き

うれしいことに多くの方々が買ってくださり

  • 1巻売り切れ(在庫もなし)
  • 2巻売り切れ(在庫もなし)
  • 3巻売り切れ(在庫もなし)
  •  新刊9巻売り切れ(正確にはあと2冊だけある)

このようになっています。

今日発注をかけて、2,3,9巻は来週の月曜日くらいには在庫復活予定です。

1巻はセリフを変えたい場所があるので少し構成検討中です。

テスターちゃんを書き始めたころは「最後の砦」が普通に言われていたのですが、今それを言うと周りからボコボコにされてしまう……!

 

135.プロダクトリスク・プロジェクトリスク その②

135.プロダクトリスク・プロジェクトリスク その②

プロダクトリスクは、作っているモノの品質に影響を与えるリスクです。

作業成果物がユーザーやステークホルダーのニーズを満たすことができない恐れ、といったところです。

JSTQB FL4.0では以下。

プロダクトリスクはプロダクトの品質特性(例えば、ISO 25010 品質モデルに記述がある)に関連するものである。プロダクトリスクの例としては、機能の不足や誤り、誤った計算、ランタイムエラー、貧弱なアーキテクチャー、非効率なアルゴリズム、不十分な応答時間、貧弱なユーザーエクスペリエンス、セキュリティの脆弱性などが挙げられる。

このように例が挙げられています。(プロダクトリスクとは何か、とはっきり書いていないのが気になるけど……)

 

プロダクトリスクはテストで確認できる

作者はこれが重要なことだと思ってるので、次回のマンガに書く予定です。

 

ネタについて

かずさんのポストがネタです!

これを見て「描きたい!!」と思ってしまったわけです(笑)

 

 

同人誌版テスターちゃん9巻『テストプロセス編』は2023年11月25日頒布!

テスターちゃん9巻の作業をして、無事脱稿しました!

『テストプロセス編』となっています。

 

頒布は第9回技術書同人誌博覧会で頒布します。

日時 : 2023/11/25 11:00 ~ 16:00

場所 : 大田区産業プラザPiO 大展示ホール

11月もアレコレ忙しく早め早めに動いていますw

 

イベント後にBOOTHで物理本/電子本の頒布も開始します~!

testerchan.booth.pm

 

まさかのホゲホゲリオン(前回ネタ)の続き

前回、プロダクトリスク・プロジェクトリスクの説明をした時に出したネタ『ホゲホゲリオン』。

 

testerchan.hatenadiary.com

 

この続きを見たいという要望がありましたので、うっかり描いてみました!

シャーペンでババババーと描いています。

よければご覧ください。

……いやぁ、僕は悪ノリしちゃうのがよくないんだろうなぁ。

 

 

---------------------

 

 

---------------------

 

 

--------------------

 

 

--------------------

 

 

最後に、こんな感じのネームを描いていたということで。

 

 

134.プロダクトリスク・プロジェクトリスク

134.プロダクトリスク・プロジェクトリスク

今回から「プロダクトリスク・プロジェクトリスク」の説明です。

最初はテスト計画を考えていたのですが、テスト計画の話を知る前にある程度知っておいた方がいいことが多数あることに気付いたわけでした。

その一つがリスクだったというわけです。

その他にもテストレベルやテストタイプなどなど挙げるととても多そうですが、そこそこに説明していこうと思いますw

 

リスク

リスクという言葉はなんとなくはみなさんに伝わる言葉かと思います。

定義的なものを引っ張ってくるならば……。

 

ISTQBの用語集的には以下です。

将来、否定的な結果を生む要素。

https://glossary.istqb.org/ja_JP/term/risk-2

 

『熊とワルツを』という本では以下です。

リスク[名] 

1. 将来起こりうる出来事で、望まない結果を生むもの。

2. 望まない結果そのもの。

引用: 熊とワルツを リスクを愉しむプロジェクト管理 著:トム・デマルコ/ティモシー・リスター

1番目がISTQBと一緒で原因を指していて、2番目が結果ですね。

 

JSTQBではリスクをプロダクトリスク、プロジェクトリスクにわけて説明をしているので、その辺のお話を展開していこうと思っています。

 

 

 

 

 

 

作者近況報告

近況報告

作者こと僕のことを書くことも少なかったですし、近況報告をしてみます。

 

テスターちゃんについて

モチベーション下降中でおやすみしていますmm

このブログでも書きますが、現在作者は無職です。

テスターちゃんは、一緒にQAをしている方々の困りごとを直に見て、その辺の事柄について描いたりしていました。

ターゲットが目に見えていて、その人たちに伝えるというモチベーションがあったのだと思います。

それが今は無職でその辺のトリガーがなくなってるかもしれないといったところです。

 

あと「何かやらなきゃ!」症候群になってたのですが「休めるときは休めばいいじゃん」と言われまして。

今は全力でのんびりしていますw

また9月からはお仕事をしますので描き始めるかと思います。

 

前職の話

前職は、AI系のスタートアップの会社に勤めていました。

そこでは流行る前のGPT-3をいち早く取り入れたアプリのQAを行っていました。

AI系のQAの知見は2023年5月にMIXIさんで行われたQuesで講演しています。


speakerdeck.com

その他、自動テストのSaaSの利用について残念ながら会社を通すことに失敗して、ひたすらPythonでUI自動テストを書いたりAPIテストを書いたり、コードをかけるテストエンジニアさんに来ていただいてコードを書いてもらってコードレビューをしていたりしました。

そんな中、世知辛い世の中の流れでアレがナニでお察しくださいで希望退職募集開始となりました。

そこで手を挙げたことで、ニート生活に突入です。

前職でのQA活動は全然僕の満足いくものではなく、悔いを残しての退職でした。

 

ニート生活の話

今年に入ってからずっとニートですw

ただ、にわかニート?で、5月末まではやること盛りだくさんで忙しかったです。

様々な活動に手を出しているそこのあなた。会社を辞めたからといって「なんにもしなくていいぞー!」とはならず、これまでため込んだタスク処理に追われますからね……!

閑話休題

6月からようやく体が空いたので自由と思ったのですが、急に体が空くと「どうしよう」となりまして、ササっと就職の話を進めてしまいました。

5月末にMIXIさんで講演した時にカジュアル面談(というか困りごとのヒアリング)をしてそのまま面接を進める→入社の運びとなりました。

ガッツリ面接してください、とお願いしたのと先方のもろもろの都合で6月いっぱいかかったかなと。

ちなみに僕は就職先選びでエージェントも通さないですし、複数社も受けないです。

直近4回の転職では1社だけ受けて、その1社に合格→入社で進めています。

自分が行きたいと思った会社にしか行きたくないですし……。

全てお給料も100万円単位でアップさせてます。

そういう会社を選んでいます。

このやり方は後程ブログを書こうと思っています。

(あとたぶん10月にあるイベントで話します)

 

7月になってから本格的に体が空きました。

就職も決まっているので部屋選びなどなどです。

Xを見てた人は僕がずっとペットと住める部屋探しをしていたつぶやきを見ていたかもしれませんw

あと、体が空く前は「ヒマになったらアレとコレをやって……」と考えていたのですが、いざ体が空くとなぜか何もやりたくない病に!!

アレです。ゴールデンウィークの時の気持ち。

マンガもいっぱい書き進めようと思ったのにモチベーションが……。

それでも何かやらなきゃ!時間がもったいない!

そんな気持ちになって、まるで何かに追われている気分でした。

けど妹から

「休むときは休めばいいのに」

とごく当たり前のことを言われました。

「そりゃそうか。なんでこんなに生き急いでいるんだろう」となった結果、ゲームとマンガとプラモとモノづくりをしてましたw

 

そしたら今日になっていましたw

 

東京に引っ越しました

前職はフルリモートの会社だったので青森に住んでいました。

今入社した会社もフルリモートがオッケーなのですが、東京に住みたくなったので引っ越しましたw

僕はコロナに入ってからずーっとリモート生活だったのですが、フルリモートはかなり強い自制心がないと無理だと悟りました。

僕の部屋なんて、基本オモチャに囲まれてますからね……。

 

テスターちゃん合同会社を解散しました

会社経営もしていました。

合同会社というのは誰かと経営していたという意味ではなく、その昔でいう有限会社です。

御多分に漏れず経営が火の車となりまして、決めていた予算を使い切ったために解散を決めました。

会社は設立は簡単なのですが、解散はとてもとても大変でした。。。

さらにお金トラブルにも見舞われ><

Xを見ていた人なら、僕が一時期ずーーーっと役所だ法務局だとつぶやいていたのをみうていたかもしれませんw

 

会社経営もとてもいい勉強になりました。

お金や税金には強くなったと思います。

一人社長はやることがとても多く、できるなら事務をやってくださる方を雇ったり、委託するのがよさそうです。

あとは……freeeがなければ絶対決算なんてできなかった……。

税金やお金周り……この辺は取り立て以外は向こうさんからは来ないので自分でいかないと損しますよ、と教訓だけ書き残しておきますねw

 

2023年11月25日に技書博に出展します

最後です。

東京に戻ってきたので、またイベント参加しようと思って申し込みしました。

またマンガをバリバリ描いていこうと思います!!

お楽しみに!

 

 

ドッグフーディング

ドッグフーディング

追記 (2023/7/11)

ドッグフーディングという言葉について作者と同じ使い方をする人がいる一方で、違う使い方もあるとのことでした。(細かい説明はtwitter紹介のあとに記載してます)

 

 

 

 

ドッグフーディングが紹介されている「闘うプログラマー」では、WindowsNTを開発する際に、実際にプロダクトを使いながら開発を進めることを「ドッグフード」と呼んでいます。

カトラーがスケジュールをふりかざして、「自分たちがつくったドッグフードを食べる」よう指示した。カトラーは、半分は男らしさをみせるために、半分は常識的な判断から、「ドッグフード」を食べることを重視していた。つまり、「自分でつくったプログラムをつかう」べきなのだ。ドッグフードを食べていれば、NTの欠陥や不十分さから目をそむけることができなくなる。プログラマーは、自分の担当部分に没頭している間にも、NTの欠陥にぶつかる。プログラマーのコンピューターをNTで制御するようにすれば、NTのでき具合でプログラマーの仕事の環境が決まる。当初は、ドッグフード程度の味でしかないのであれば、ますますこれを食べるべきだ。プログラマーは、早急に品質をあげなければならないと実感し、すぐにコードのエラーを修正し、もっと信頼性の高いコードを書くようになるだろう。

出典:『闘うプログラマー[新装版] ビル・ゲイツの野望を担った男たち』Gパスカルザカリー著 山岡洋一役

 

これらのことから、ドッグフーディングの大枠としては

「自分たちのプログラムや製品を自分たちで使い、改善に活かすこと」

と言えそうです。

そこから適用方法として

  • 日常的に使いながらプロダクトの改善に活かすのか(日常使いし改善しながら開発進行)
  • 特定のタイミングで使ってプロダクトの改善に活かすのか

という違いがありそうです。

 

これは、どちらが正解でどちらが間違っているではなく、現場によって実施方法が異なると言えます。

ドッグフーディングしよう」と話が上がってきたら「どのように実施しますか?」とみんなで認識合わせをしっかりとする必要がありそうです。

 

ちなみにマンガは一方の使い方を「これ!」と言ってしまうのも燃えそうなので、同人誌や本にはこの話の掲載は控えます。

ちょっと変更して「こういう適用方法があるよ」という紹介にすればよさそうだけど、悩みどころ。

 

----

 

 

ドッグフーディングは、自分たちが作ったアプリやサービスを主にリリース前に実際にユーザーとして使ってみることです。

ドッグフード販売会社の社員が、開発したドッグフードを実際に食べて製品の良し悪しを確認していたことが由来とのことです。

 

自社のモノを実際に使ってみることを言うのでやり方は無数にあります。

ですので、作者が経験した方法を記載しておきます。

自社の肝いりアプリ/サービスのリリース前の最終段階で、全社員に「使ってみてください~」で使ってもらって、アンケートで情報収集する、といった形でした。

メリットとしては、多種多様な実際の利用環境と利用タイミングで、社員の数だけある実際の使い方で使ってもらうことで、想定通り使ってもらえるのか、改善点や問題点は何かわかることです。

デメリットというか注意点としては……意外とみんなやってくれずにアンケートが集まらないことです(^-^;

他の社員も当然手伝ってくれるはず、と考えていると痛い目に遭います。

この場合は、例えばご褒美をつけるとか(この場合、次からご褒美がないとやってくれなくなる可能性も…)、上長に言って上層部が集まるMTGに議題を持って行ってもらって、各組織長からメンバーに「できるだけやってね」と言ってもらうような「政治」を行うことが考えられます。

 

大きな問題が見つかることも

続きを読む

133.ランチ

133.ランチ

2回目の箸休め回です。

さりげに前回の続きですw

ブコメの波動を感じるようなお話、本編(テストの説明)を描いてると描けないですからね~✨

 

さて。

次は単発で「ドッグフーディング」といった言葉の回にしようかと思っています。

というかそろそろ同人誌9巻をまとめないと。

 

 

132.物価高

132.物価高

箸休め回です。

テストプロセスのシリーズで多少ダレてしまった(作者が)ところがあるので、数回は箸休め回をはさんで感覚を取り戻そうかなーと思っています。

 

さて、インフレが世間で言われてきていますね。

インフレには2種類あるとのことで紹介しておきます。

作者は専門ではないので紹介程度です。気になる方は調べてみると面白いかもしれません。

 

ディマンドプルインフレ

よく社会の勉強の時に出てきた「需要が増えれば価格が上がる」インフレです。

100円の商品だったとして、欲しい人がいっぱいいれば110円でも売れる、といったところです。原価が90円だったとして、110円で売れるようになったのなら20円の儲けになります。

適度であればよいですが、コントロールができないとよろしくないインフレだと言われています。

今のアメリカのインフレはディマンドプルだと言われています。

 

コストプッシュインフレ

その名の通り、コストによってけん引されるインフレです。

原価が上がってしまったから値段を上げなければならないという状態です。

100円の商品だったとして、今まで90円で作ってたものがコストが上がって100円でしか作れない、となったら価格を110円にするしかないといったところです。原価が100円になっているので110円で売っても前と変わらず10円の儲けです。

今の日本のインフレはこちらです。

 

半額のお弁当の買い方

続きを読む