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

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



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自動テストが回っていて修正忘れに気付くこともありますが、修正範囲にそういった仕組みが作られてないときもあります。

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

続きを読む

107.リグレッションテスト その⑤

f:id:m_training:20210607074149p:plain

107.リグレッションテスト その⑤

リグレッションテストのやり方の一例

変更によって、他のテスト済みの機能に意図しない影響が出ていないか確認する目的のテスト全般がリグレッションテスト。

なので「これ!」といったやり方があるわけではないです。

ここで紹介しているのは作者が行った方法を並べています。

続きを読む

テスターちゃんねる第5回「仕様通り動くかのチェックだけだとNG!?」後編をアップしました!

「仕様通り動くかのチェックだけでよくない?」「自動テストだけでよくない?」に対する作者なりの返答もしてます。