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

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



118.テスターの一日 その⑨

f:id:m_training:20211122063235p:plain

118.テスターの一日 その⑨

「テスターの一日」のお話は今回で終わりです。

作者のテスター時代の流れの話や、テスターとして入社された方に教えていたようなことを散りばめてみました。

背景として、最近新しく作ったテスト組織をマネジメントすることになったことがあります。

そこで、テストの実行速度をあげたいとか、報告のときに何を気をつけたほうがいいかとか、ちょっとした話題もちょこちょこ出たりしたんですね。

そういったtips的なことを描いてもみなさんのお役に立つのかなーなんてことを考えて描いた次第です。

 

次回は箸休め回を挟んで、恒例のアドベントカレンダーでクリスマススペシャルと題して何かを描こうと思っています。

何を描くかは今の段階ではまだ考えていないけど!

 

そろそろ……

マンガも貯まってきたので、テスターちゃん同人誌版8巻を作ろうと思います。

おそらく技術書同人誌博覧会(2022/2月?)にあわせて作ろうかと考えています。

 

続きを読む

117. テスターの一日 その⑧

f:id:m_training:20211109125213p:plain

117. テスターの一日 その⑧

YWT (ふりかえりの方法)

YWT(わいだぶりゅてぃー)は、

  • やったこと
  • わかったこと
  • 次にやること

でふりかえり、次に経験を活かすやり方です。

 

まずは「こういうことあったなぁ」と考えながら、やったことを書き出します。

そしてそれらを思い出しながら「そういえばこんなことわかったっけ」とか「これいい感じだった」とか「こういう風にやればちょっと速かったんじゃない?」といった、わかったことを書き出します。

それらから「じゃあ次はこういうことをしよう!」と出していくわけですね。

経験のふりかえりに良い、といったところです。

続きを読む

第11回「まつ流テストの目的別・探索的テストの戦術」を公開【テスターちゃんねる】

テスターちゃんねる第11回「まつ流テストの目的別・探索的テストの戦術」という動画をアップしました!
システムテストの段階で「こういう場合にはこういう探索的テストをやってるよ」という紹介をする動画となっていますー!
参考になりましたら幸いです!

再生リストはこちらから!

テスターちゃんねる - YouTube

第10回「セッションベースドの探索的テストのやり方」を公開【テスターちゃんねる】

テスターちゃんねる第10回「セッションベースドの探索的テストのやり方」を公開しました!
13分の動画です。今回は1本にまとめました~!
あとBGMもうっすらつけてみてます

www.youtube.com

 

再生リストはこちらから!

テスターちゃんねる - YouTube

116.テスターの一日 その⑦

f:id:m_training:20211018061610p:plain

116.テスターの一日 その⑦

  • 116.テスターの一日 その⑦
    • 案件の情報共有ミーティング
    • そのミーティングで作者がすること
    • 企画側の観点と開発側の観点とテスト側の観点は違う
    • 「たぶん大丈夫だと思います」
    • テスターちゃんができるまで!

案件の情報共有ミーティング

作者は会社では横断的にテストの社内コンサルしたり、テスト計画作成をしたりしています。

その時最初に行うミーティングがコレ。

プロダクトに関わるメンバーで集まります。

プロダクトの概要を聞いて、その後に気になっていることや不安なことを聞きます。

つまりリスクだと思っている部分です。

これ「リスクだと感じている部分は?」と聞くより「気になってること、不安なことありますか?」の方がちょっとしたことまで話が出やすかったりします(体感だけど)

このリスクがプロダクトリスクなら、その部分をテストすることでリスク軽減することができます。

テスト分析(何をテストするか考える)時の良い材料収集の場となるわけです。

 

こういった場があると、プロダクトに関わるメンバーがあらかじめ気をつけたほうがよさそうなところが共有されるため、その部分について「だから言ったのに」なことが減ります。

 

そのミーティングで作者がすること

事前に資料を読み込んでいって、質問を書き出しておきます。

ミーティングの場では内容の共有というより認識合わせの意味合いが強いです。

概要説明時に、対象になるシステムは何か、フローはどうなっているのか、などをさらに聞きます。

そうするとたまに事前に資料を読み込んで想像していた内容と違ったり、関係がありそうなのに話に出てこない部分があったりします。

そういった部分をマンガのような質問をすると(1回ではなく「これどうなってます?」と結構あれこれ質問しますが)見落としていた部分、勘違いが生まれていた部分が出てきたりします。

続きを読む

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のカンバンボードを見ながら、その場でスタンディングミーティングをしていることをイメージしています。

続きを読む