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

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



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

f:id:m_training:20210913061037p:plain

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

確認テスト

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

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

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

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

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

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

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

と見返します。

それで

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

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

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

 

きゅんちゃんの会社の流れ~朝のタスク~

きゅんちゃんのところでは、朝は確認テストから。

作者が回ってきたweb系やゲーム系の会社もだいたいそういった流れでした。

朝に定型業務として入ってるけど、一日のうちでも修正が返ってきたら随時確認といったところです。

修正されたかどうかは、よくあるのはBTS(バグトラッキングシステム)のステータスフローで行われます。

よくあるのがこんなステータスフローでしょうか。

  1. 登録(バグが登録された状態)
  2. 修正中(開発側でバグ修正中)
  3. 確認テスト中(修正が終わりテスト環境に反映済み)
  4. 完了(確認テストが完了しバグ票のクローズ)

各社で使いやすいようにフローが追加されたりするかと思います。

逆にこれ以下(登録→修正中→完了)だと、開発とテストがわかれている場合は管理しにくそうです。

 

で。きゅんちゃんの組織では「確認テスト中」になったバグは確認する、といった約束事が開発組織とテスト組織にあったりするわけですね。

このステータスフローが決まってないと

バグの状況が見えん!

どういう状態の時に何をするかわからん!

なんて管理ができない状況になってしまったりします。

 

テスト実行

テスト手順を見ながら操作し、期待結果と同じか比較し、結果を記載します。

求めてるのは上記の行動です。

発展させると、その項目から浮かぶ他の操作もやってみる、をやると意外とバグが見つかったりします。

作者がそんな感じでした。

要はテストの項目1つ1つが「探索的テストのチャーター」としても機能したりするわけです。

 

作者はなのですが、テストの手順がしっかり書かれた項目は見る機会が少なかったです。

ふんわりした手順とふんわりした期待結果がならんでたり。

JSTQB的に言うとハイレベルテストケースの粒度(さらに上のテスト観点的粒度まで!)だったりしたわけです。

web系の現実といったところでw

そうなると、テスターとしては「他に見る場所は……」の発想には自然になってきたりします。

 

複数台同時テスト

これまた作者がこんな感じでした。

De〇A社でゲームのテストするときに何気にこれをやってたら

「マジで!!」

とスゴイビビられたものです。

その前の会社(中国だったけど)だとみんなやってたので作者もびっくりでした。

 

ゲーム系のように、入力がほぼボタンとか、一画面で基本見られる系がやりやすいです。

アプリ系だと、一端末だけ画面が小さくてスクロールしないとボタンが見えない、などがあるとやりにくくなります。

全端末スクロールしてボタンを押す、だと全台行動が一致するのでやりやすくはなります。

あとは文字入力はさすがに一台ずつになるかなと。

他やり方としては一台一台順番に同じ行動をしていくベルトコンベア式(作者命名)があるわけです。

スマホを置いた状態でポンポンポンといった感じで。

これも最強に強まった人は北斗百裂拳みたいになります。

f:id:m_training:20210913065520j:plain

 

そういえばテスターちゃん35話「探索的テストその⑤」でシレっと絵に描いてましたね。

f:id:m_training:20210913065723p:plain

 

作者が経験したゲーム系だと、3~4日でテスト項目10,000~12,000くらい行う必要がありました。

ゲームのイベントが毎週変わるのでそういうサイクルになるわけです。

なので、チンタラしていると死が待ち受けています。

(テスト実行も大変でしたが、テストケース作成はもっと大変だったんですからね!)

毎日大騒ぎでテストしてましたw

そこからアプリ系に移ったときは

「ここは天国か!」

(粒度も期間も変わらず多くて2000ケースとかかな)

と思ったくらいでした。

 

アプリ系はアプリ系で新規アプリリリースの時はAndroid60端末くらいで基本動作がクラッシュせずに動くかのテストもありました。

そういったときにはピアノを弾くような形でやっていました。

 

オマージュ

気づかれて嬉しいのがオマージュ。

気づかないと困るのがパロディ。

らしいです。

それでいうと作者が描いているのは大体オマージュでしょうかw

気づかれなくても楽しめる。

気づかれたらもっと楽しめる。

そんな感じ。

作者、いろーんなところに気付くか気付かないかのオマージュを挟むのが好きなんですよ。

パロディはというと例えば、髪が上に逆立った様子の絵を描いて

「おいおい、ゴンさんみたいになってんじゃんよ」

とツッコミ入れる、などでしょうか。

これはゴンさんを知らなければ楽しめないですよね。

 

で、今回のオマージュは「のだめカンタービレ」です。

もう結構古いマンガですが、ドラマもマンガもヒットしましたね!

作者はドラマから入った人で、この辺からオーケストラなんかを聞くようになりました。

 

描いている様子の動画

今回も動画を撮ってyoutubeにアップしてみました。

今回は背景やオマージュについて説明をしています。

全体を映すのではなくて、説明部分に絞っていいかもですね

www.youtube.com