再生リストはこちらから!
再生リストはこちらから!
作者は会社では横断的にテストの社内コンサルしたり、テスト計画作成をしたりしています。
その時最初に行うミーティングがコレ。
プロダクトに関わるメンバーで集まります。
プロダクトの概要を聞いて、その後に気になっていることや不安なことを聞きます。
つまりリスクだと思っている部分です。
これ「リスクだと感じている部分は?」と聞くより「気になってること、不安なことありますか?」の方がちょっとしたことまで話が出やすかったりします(体感だけど)
このリスクがプロダクトリスクなら、その部分をテストすることでリスク軽減することができます。
テスト分析(何をテストするか考える)時の良い材料収集の場となるわけです。
こういった場があると、プロダクトに関わるメンバーがあらかじめ気をつけたほうがよさそうなところが共有されるため、その部分について「だから言ったのに」なことが減ります。
事前に資料を読み込んでいって、質問を書き出しておきます。
ミーティングの場では内容の共有というより認識合わせの意味合いが強いです。
概要説明時に、対象になるシステムは何か、フローはどうなっているのか、などをさらに聞きます。
そうするとたまに事前に資料を読み込んで想像していた内容と違ったり、関係がありそうなのに話に出てこない部分があったりします。
そういった部分をマンガのような質問をすると(1回ではなく「これどうなってます?」と結構あれこれ質問しますが)見落としていた部分、勘違いが生まれていた部分が出てきたりします。
続きを読む作者はテスト経験のほとんどがテスト部隊で、探索的テストも基本的にはチームプレイでやることのほうが多かったです。
探索的テストの全体設計をする人がいて、その人の指揮に合わせて進めるという形。
探索的テストをチームプレイで行うときはセッションベースドの探索的テストが管理がしやすく進めやすいです。
デメリットとして、指揮する人がテスト全体の状況が見えていない、状況から次の打ち手を考えられないと明後日の方向に連れていかれます。
無駄な行動をすることになったりするので注意が必要です。
セッションベースドの探索的テストは時間で区切られたセッション、そのセッションでのミッション(目的)を設定して行う探索的テストです。
1回のセッションが終わったらデブリーフィング――終了後の相談を行って、次のセッションでの方針を決めます。
なので「学習→設計→実行→FBから次の行動を決める」という探索的テストの行動にさらに大きな枠「1回のセッションの実行→FBから次のセッションの方針を決める」のサイクルがあるわけです。
作者は1回のセッション時間は40分で設定していました。
よく理由を聞かれますが、web/appの現場の経験上です。
30分だと短いのですよ。やりたいことができずに終わったりします。
1時間だと飽きちゃうメンバー、同じことを繰り返しているメンバーが増えてきます。
その辺を見ながら調整をしていったら40分に落ち着いたといったところです。
この時間も、探索する規模によっては短くしたり長くしたり調整は入ります。
これは通常のマネジメントでも同じですね。
続きを読むこんにちは。作者です。
お昼休み、ということで箸休め回になりました(笑)
ちなみにテスターちゃんの世界ではパンデミックは発生していません!
作者もお昼は外食派でした。
最初の頃は色んな所に行くのですが、だんだん行く場所が固定化してくるんですよねー。
作者はというと、もっぱら会社の近くの中華料理屋で担々麺を食べてましたw
今は在宅業務なので、昼は普通に家で自炊です。
自炊にしてわかったことは昼食代が全然かからないこと!
都心で昼ご飯に行くと一食1000円~1200円とかそんなところ。
なかなかな金額。
それが自炊だと恐らく使っても500円ほど。
この差は大きい……!
テスターちゃんができるまでの動画を1分でw
タイムラプスという機能を使って録画してみました。
バグを登録するときの流れは組織によってまちまちだと思います。
ここで紹介するのはきゅんちゃんたちのチームはということで。
テストリーダーに全部の情報が集まる形です。
不正(アノマリー/期待と異なる結果)があった場合はチャットでリーダーに報告します。
口頭で済ましてしまうと他のメンバーに情報が伝わらなかったりします。
そうなると重複した報告が出てきてしまいます。
そしてリーダー側で、情報が不足してないかの確認(他の端末は見た?など)や、報告された情報が重複されてないかや、勘違い(偽陽性)などではないかの判断を行います。
で、わかった情報からバグ修正の優先度をつけて登録指示です。
メンバーはバグを登録したら、テストケースにバグ票のURLを紐づけて、登録報告です。
新人さんの場合は、登録完了の報告後にリーダーがバグ票のチェックを行ったりします。
まとめるとこんな感じです。
確認テストは、修正されたバグが再現しないことを確認するテストです。
テストの項目書から出たバグであれば、結果をFailにしてバグ票のURLなどが紐づけられているはず。
その項目の結果を更新しましょう。
ちゃんと項目が更新されてないと大変になるのがリーダーです。
リーダーはみんなの一日の業務が終わった後なんかに、テストの項目がきちんと記載されているかを見返したりしています。
その時にFailの項目を見つけると
「ここの状況どうなってるんだっけ……」
と見返します。
それで
「ああっ、修正されてるけどFailのままじゃん!更新状況直さないと……」
というわけで約束された残業が待っていたりするわけです。
(もっとつらいのがバグが報告されているのにPassがついている項目。。。)
続きを読むこんにちは。作者です。
組織によって「ウチはスクラムで開発もテストもワンチームだよ!」というところもあれば「開発とテストは別組織」という場所もあるかと思います。
作者は開発とテストが別組織の経験の方が圧倒的に多いので、そちらのパターンで描いていこうと思います。
あと、これから紹介していく「テスターの一日」は飽くまで一例!
「他社ではこんな感じやってるところがあるのかー」くらいの気持ちで読んでくださればです。
きゅんちゃんたちの組織ではJiraのカンバンボードを見ながら、その場でスタンディングミーティングをしていることをイメージしています。
続きを読むさて、今回から「テスターの一日」について描いていこうと思います。
作者が経験したweb系、ゲーム系のテスト実行者の流れを合わせた形で描いていくつもりです。
経験した現場の流れとしては大体同じ感じでしたのでw
あと「リーダーの一日が知りたい!」「マネージャーの一日が知りたい!」といったご要望ももらっていたりしますw
近頃は副業?も落ち着いたので、テスターちゃん更新を頑張っていきたいところです。
めざせ同人誌8巻!
同人誌10巻まで出せたらおそらく書籍2巻を出せる分のページ数が貯まるはず。
めざせ書籍2巻!
はい、作者です。今日はテスターちゃんの話ではありませんw
表題の通り、自分が話した言葉をまぁリアルタイム…もといワンテンポ遅れでVOICEROIDに話してもらうプログラムを書いてみました。
動画を見ていただくのが早そうです。
githubにコードをおいています。
全ファイルのプログラム合計でたった69行!
これで作れるのは世の中の進歩のおかげ……。
今日はそのプログラムの説明をしたいと思います。
webを操作するためにseleniumと、Windowsアプリを操作するためにappiumを使っています。
これらはテスト自動化でよく使われるものです。
これも超最低限の構成で、webから要素を取得したり、ウィンドウズのアプリに文字列張り付けてボタンを押したりさせてます。
テスト自動化を勉強している人は、webの操作/windowsアプリの操作の最小限の構成がわかるかもしれません。
あとコードがわかれば応用も聞くので、音声認識を使ったアレコレも作れるかもしれません。
自分が話した言葉を音声認識させて保存させるような議事録取り的なものとか。
イベントでtwitterやzoomに来た最新チャットを読み上げるとか。
zoomにきた最新チャットをコメントスクリーンに回すとか。
様々考えられそうですね。
同じことがゆかりねっと様でも可能です。
プログラムなんてどうでもよくてツールだけ使いたい!という方はそちらがお勧めです。
続きを読む
久しぶりの更新の作者です。
久しぶりの更新なのに箸休め回からの更新です。
2021年6月に発売した同人誌版7巻を作るときにページ数の関係と締め切りのタイミングで箸休め回がなかったわけです。
実はテスターちゃんには規則的な流れがあります。
本編(テスト系の話)→箸休め回
になっています。
話と話の区切りの意図の他に、キャラの掛け合いをしたいなーといったところ。
ただの説明マンガではなく、ちゃんと「マンガ」として楽しめる要素を入れたいわけですねw
さて、作者7月は何やってたの?という話です。
続きを読む