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

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



115.テスターの一日 その⑥

f:id:m_training:20211004064504p:plain

115.テスターの一日 その⑥

  • 115.テスターの一日 その⑥
    •  
    • 探索的テスト
    • セッションベースドの探索的テスト
    • メンバーの得意不得意によって指示を変える
    • 戦術っぽい話を思いついたままに書いてみる
    • 「バグ登録はいつやればいいの」問題
    • 「探索的テストで出したバグは再現が…」問題
    • 「探索的テストのログを取りたい」問題
    • 1分でわかるテスターちゃんができるまで!

 

探索的テスト

作者はテスト経験のほとんどがテスト部隊で、探索的テストも基本的にはチームプレイでやることのほうが多かったです。

探索的テストの全体設計をする人がいて、その人の指揮に合わせて進めるという形。

探索的テストをチームプレイで行うときはセッションベースドの探索的テストが管理がしやすく進めやすいです。

デメリットとして、指揮する人がテスト全体の状況が見えていない、状況から次の打ち手を考えられないと明後日の方向に連れていかれます。

無駄な行動をすることになったりするので注意が必要です。

 

セッションベースドの探索的テスト

セッションベースドの探索的テストは時間で区切られたセッション、そのセッションでのミッション(目的)を設定して行う探索的テストです。

1回のセッションが終わったらデブリーフィング――終了後の相談を行って、次のセッションでの方針を決めます。

なので「学習→設計→実行→FBから次の行動を決める」という探索的テストの行動にさらに大きな枠「1回のセッションの実行→FBから次のセッションの方針を決める」のサイクルがあるわけです。

 

作者は1回のセッション時間は40分で設定していました。

よく理由を聞かれますが、web/appの現場の経験上です。

30分だと短いのですよ。やりたいことができずに終わったりします。

1時間だと飽きちゃうメンバー、同じことを繰り返しているメンバーが増えてきます。

その辺を見ながら調整をしていったら40分に落ち着いたといったところです。

 

この時間も、探索する規模によっては短くしたり長くしたり調整は入ります。

 

メンバーの得意不得意によって指示を変える

これは通常のマネジメントでも同じですね。

続きを読む

114.テスターの一日 その⑤

f:id:m_training:20210927064142p:plain

114.テスターの一日 その⑤

こんにちは。作者です。

お昼休み、ということで箸休め回になりました(笑)

ちなみにテスターちゃんの世界ではパンデミックは発生していません!

 

作者もお昼は外食派でした。

最初の頃は色んな所に行くのですが、だんだん行く場所が固定化してくるんですよねー。

作者はというと、もっぱら会社の近くの中華料理屋で担々麺を食べてましたw

 

今は在宅業務なので、昼は普通に家で自炊です。

自炊にしてわかったことは昼食代が全然かからないこと!

都心で昼ご飯に行くと一食1000円~1200円とかそんなところ。

なかなかな金額。

それが自炊だと恐らく使っても500円ほど。

この差は大きい……!

 

テスターちゃんができるまで

テスターちゃんができるまでの動画を1分でw

タイムラプスという機能を使って録画してみました。

www.youtube.com

113.テスターの一日 その④

f:id:m_training:20210920212918p:plain

113.テスターの一日 その④

バグ登録時のフロー

バグを登録するときの流れは組織によってまちまちだと思います。

ここで紹介するのはきゅんちゃんたちのチームはということで。

 

テストリーダーに全部の情報が集まる形です。

不正(アノマリー/期待と異なる結果)があった場合はチャットでリーダーに報告します。

口頭で済ましてしまうと他のメンバーに情報が伝わらなかったりします。

そうなると重複した報告が出てきてしまいます。

そしてリーダー側で、情報が不足してないかの確認(他の端末は見た?など)や、報告された情報が重複されてないかや、勘違い(偽陽性)などではないかの判断を行います。

で、わかった情報からバグ修正の優先度をつけて登録指示です。

メンバーはバグを登録したら、テストケースにバグ票のURLを紐づけて、登録報告です。

新人さんの場合は、登録完了の報告後にリーダーがバグ票のチェックを行ったりします。

 

まとめるとこんな感じです。

  1. チャットでバグ報告
  2. リーダー側でフィルタリング(重複、アノマリー、情報不足の確認)、優先度付け
  3. バグ登録
  4. バグ登録後報告&テストケースとのトレーサビリティ確立(紐づけ)
  5. (リーダー側でバグ票確認)
続きを読む

112.テスターの一日 その③

f:id:m_training:20210913061037p:plain

112.テスターの一日 その③

確認テスト

確認テストは、修正されたバグが再現しないことを確認するテストです。

テストの項目書から出たバグであれば、結果をFailにしてバグ票のURLなどが紐づけられているはず。

その項目の結果を更新しましょう。

ちゃんと項目が更新されてないと大変になるのがリーダーです。

リーダーはみんなの一日の業務が終わった後なんかに、テストの項目がきちんと記載されているかを見返したりしています。

その時にFailの項目を見つけると

「ここの状況どうなってるんだっけ……」

と見返します。

それで

「ああっ、修正されてるけどFailのままじゃん!更新状況直さないと……」

というわけで約束された残業が待っていたりするわけです。

(もっとつらいのがバグが報告されているのにPassがついている項目。。。)

続きを読む

111.テスターの一日 その②

f:id:m_training:20210906064414p:plain

111.テスターの一日 その②

こんにちは。作者です。

組織によって「ウチはスクラムで開発もテストもワンチームだよ!」というところもあれば「開発とテストは別組織」という場所もあるかと思います。

作者は開発とテストが別組織の経験の方が圧倒的に多いので、そちらのパターンで描いていこうと思います。

 

あと、これから紹介していく「テスターの一日」は飽くまで一例!

「他社ではこんな感じやってるところがあるのかー」くらいの気持ちで読んでくださればです。

朝会はこんな感じ

きゅんちゃんたちの組織ではJiraのカンバンボードを見ながら、その場でスタンディングミーティングをしていることをイメージしています。

続きを読む

テスターの一日 その①

f:id:m_training:20210830064410p:plain

テスターの一日 その①

さて、今回から「テスターの一日」について描いていこうと思います。

作者が経験したweb系、ゲーム系のテスト実行者の流れを合わせた形で描いていくつもりです。

経験した現場の流れとしては大体同じ感じでしたのでw

 

あと「リーダーの一日が知りたい!」「マネージャーの一日が知りたい!」といったご要望ももらっていたりしますw

 

毎週更新をがんばりたい

近頃は副業?も落ち着いたので、テスターちゃん更新を頑張っていきたいところです。

めざせ同人誌8巻!

同人誌10巻まで出せたらおそらく書籍2巻を出せる分のページ数が貯まるはず。

めざせ書籍2巻!

 

【たった69行】自分が話した言葉をリアルタイム(?)でVOICEROIDに話してもらうプログラムを書いてみた

はい、作者です。今日はテスターちゃんの話ではありませんw

表題の通り、自分が話した言葉をまぁリアルタイム…もといワンテンポ遅れでVOICEROIDに話してもらうプログラムを書いてみました。

動画を見ていただくのが早そうです。

githubにコードをおいています。

全ファイルのプログラム合計でたった69行!

これで作れるのは世の中の進歩のおかげ……。

今日はそのプログラムの説明をしたいと思います。

 

webを操作するためにseleniumと、Windowsアプリを操作するためにappiumを使っています。

これらはテスト自動化でよく使われるものです。

これも超最低限の構成で、webから要素を取得したり、ウィンドウズのアプリに文字列張り付けてボタンを押したりさせてます。

テスト自動化を勉強している人は、webの操作/windowsアプリの操作の最小限の構成がわかるかもしれません。

あとコードがわかれば応用も聞くので、音声認識を使ったアレコレも作れるかもしれません。

自分が話した言葉を音声認識させて保存させるような議事録取り的なものとか。

イベントでtwitterやzoomに来た最新チャットを読み上げるとか。

zoomにきた最新チャットをコメントスクリーンに回すとか。

様々考えられそうですね。

www.youtube.com

github.com

 

同じことがゆかりねっと様でも可能です。

プログラムなんてどうでもよくてツールだけ使いたい!という方はそちらがお勧めです。

続きを読む

109.わかりやすい

f:id:m_training:20210816202756p:plain

 

109.わかりやすい

久しぶりの更新の作者です。

久しぶりの更新なのに箸休め回からの更新です。

2021年6月に発売した同人誌版7巻を作るときにページ数の関係と締め切りのタイミングで箸休め回がなかったわけです。

testerchan.booth.pm

 

実はテスターちゃんには規則的な流れがあります。

本編(テスト系の話)→箸休め回

になっています。

話と話の区切りの意図の他に、キャラの掛け合いをしたいなーといったところ。

ただの説明マンガではなく、ちゃんと「マンガ」として楽しめる要素を入れたいわけですねw

 

作者は割と副業をがんばっている

さて、作者7月は何やってたの?という話です。

続きを読む

108.リグレッションテスト その⑥

f:id:m_training:20210614064509p:plain

108.リグレッションテスト その⑥

リグレッションテストの最後の回です。

開発の方と話をすると

「修正したとこが動くの確認できれば大丈夫」

と返事をいただくことは多いです。

確かに他に問題がない場合の方が多いです。

とはいえ、他に目を向けたときに動きがおかしくなっていて

「あーそこも直さなきゃいけないんだった」

なんて場面に出会ったことも少なくはありません。

ユニットテストやE2E自動テストが回っていて修正忘れに気付くこともありますが、修正範囲にそういった仕組みが作られてないときもあります。

「確認テスト」(修正の確認)だけで本当に良いのか「リグレッションテスト」(周囲の影響のテスト)も別途実行した方がよいかは一旦足を止めて考えてみましょう。

続きを読む