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

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



130.テストプロセス その⑫

130.テストプロセス その⑫

テストプロセスの説明も長期にわたりましたので、一覧できる形で簡単にまとめです。

次回テストプロセス回の締めをして、久しぶりの箸休め回です!

 

テストプロセスについて思うこと

テストプロセスなんてやってられない!という人もいたりします。

けど、このテストプロセスはリーダーが普段何気なくやってることを活動として明確にした、といったものかと思ってます。

たぶんリーダーは、案件を聞いたら

「あの辺のロジックは開発の人にユニットテスト書いてるか聞いてみないとな。そこが守られているならこっちはこんな感じで進めるか……」

システムテスト期間3日はほしい……」

なんて計画を考えるでしょうし、

「あそことここもテストしないといけない。あ!あっちのシステムにも影響するじゃん!」

と分析も考えるでしょうし

「あそこのテストは複雑だから整理するか……」

なんて設計を考えるでしょうし

「テスト項目作るか」

と実装もすると思います。

(テスト完了でレポートは決められた業務としてやるかもですが、整理/ふりかえりは飛ばされることが多いと思っていますw)

 

けれど明確な活動として表したからこそ、今までフンワリとしか考えてなかった各工程について

「何をテストするか1時間みんなで考える時間もうけてみるか」

とか

「このテストどうやるか技法を使ってやってみるか」

などなど、注意を向けられるかと思います。

 

作者はドキュメントをしっかり残せとまでは言いません(怒られそうだけど)

けど一貫して伝えていることは「考える」ことです。

web/App/ゲームとまわってきた現場でよくみたことが「考えることの放棄」だからです。

とにかくいっぱい触ればいい。

とりあえず仕様をテスト項目にコピペしてPassつければいい。

もしそんな思考停止に気づいたら

「計画はどうなってるんだっけ……」

「何をテストするかは深掘りされてるのかな……?」

「ここのテストは「あかさ」と「test」って入力するだけでよかったかな……?」

「ふりかえりとかデータ整理ってやらなくていいの……?」

とプロセスごとに思い返してみてください。

 

130話は当初旅行に例えて解説しようとしていた

実は書いている途中まで旅行の話でしたw

「テストプロセスなんてやってられない!」という人に対して「そんな身構えることじゃないんだよ」みたいなことを伝えようと思っていました。

と、描いていたのですが「いや普通にまとめをしよう。現場でありそうな例の方が想像しやすいか」と方向転換した次第です。

 

供養のためにメモを張り付けておきますw

最近はnotionにメモを描き貯めています。

 

 

 

【4月1日】テスターちゃんアニメ化!?

【4月1日】テスターちゃんアニメ化!?

マンガでわかるテスターちゃんが、ついにアニメでわかるテスターちゃんに!!

……………………

………………

…………

……という気持ちでイラストを描きましたw

きらら系的なイメージで描いています。

はい、エイプリルフールですね!

もうね、どっきりさせようどっきりさせよう、という気持ちだけで夜な夜なチマチマと描いていましたw

 

こんなラフから絵ができました~

 

さて。

せっかくですので、それぞれのキャラの絵も上げておきます~。

 

きゅんちゃん

りんちゃん

うさこ

大田さん



 

 

 

 

129.テストプロセス その⑪

129.テストプロセス その⑪

今回は「テストのモニタリングとコントロール」です。

シンプルに言うと

「計画やアプローチは状況に合わせて見直しましょう」

です。

当たり前、と思う人と、え!?と思う人に分かれるかもしれません。

作者が北海道の会社さんで講義したときは「え!?」の人が多数でした。

計画通りに進めることが正しい!という考え方の現場は意外と多いものです。

その考えはわかります。ただその計画は、最初から情報が全てそろっていなければなかなか難しいものです。

例えはよくないかもしれませんが、例えば戦国時代で敵のお城に攻め込もうとして「相手の兵も少ないし正面突破しよう」と計画を立てたとします。

けれど「正面には罠が張り巡らされています!」と新しい情報がわかったとしましょう。

そんなときに「いやけど、計画通りやらないと……」だと目的の達成(敵の城を落とす)が失敗する可能性も出てきそうですよね。

上手くいっても損耗が激しくなってしまうでしょう。

別のアプローチを考えた方が筋がよさそうです。

いい例えが思い浮かばずごめんなさい。

実際テスト計画を立ててテストを進めたことがある方ならわかるかと思いますが、仕様が決まってくるにつれ想定がずれたり、仕様の追加、遅延の発生、仕様の見送り(スペックアウト)などが発生し、最初の計画やアプローチ通りには絶対いきません。

それなのに計画を見直さないで進めたら無用の長物となります。

それだけならまだしも、想定とは変わったのに当初考えた状態のアプローチのままテストプロセスを進めてしまい不要な場所のテストをしてしまう、スコープが増えたのに見逃してしまうといったように逆に害になってしまうこともあるかもしれません。

 

その昔作者がやっていたテスト計画「松竹梅プラン」

作者はテストコンサル(テスト計画の策定と相談役)のような形で入り、開発の方々がテストも含めて行う現場がありました。

そこで作者がやっていたテスト計画の方法で「松竹梅」の計画を立てておく、というものがありました。

どういったテストが必要か見せつつ、状況に応じてスイッチングしていこう、という方法です。

松は一番細かくテストができるプラン。ただし工数がかかります。

梅は重要個所は細かくテストするけど、他の個所のテストが少ない、簡略化されているようなプラン。

竹はその中間のプラン。

このような形です。

プロジェクト開始時は開発の方々も松プランで「これで細かくテストしよう!」と進めているのですが、開発が進んでスケジュール感が見えてくると「竹……いや、梅で……!」がほとんどでした。

仕様ややることがわかっているけどスケジュールが見通しづらい場合に重宝させてもらいました。

(もちろんそれでOKではなく、状況に合わせて梅のプランのアプローチを変更、なども必要です)

 

アジャイルの現場だとリーダーはとても忙しい

アジャイルの現場の話じゃないでしょ、という人もいるかと思います。

アジャイルPJのとき作者がどんな感じだったか書いておきます。

その昔アジャイル系のチームをまとめていたときがありました。

どの機能はどういうアプローチでどういったスケジュール感で進めていこうといったベースの計画はあるのですね。

けれど機能は開発された順に飛んで来ますし、それぞれの機能でテストプロセスの進捗も異なりますし、バンバン仕様変更やスケジュール変更も発生するわけです。

 

Agile QA Nightの資料より

できた順で機能をテストしていく様を餅つきに見立てた様子。

 

IT検証フォーラム2018より

色んなプロセスが並走していてみんな状況を把握できなくなるので、状況を物理的に見える化した様子。(コロナ前)

 

こんな感じの時は、出社したらチャットに現状の計画(どういう風に進めていきましょう)を投下。

朝のMTGでもどう進めていくか全員に連絡。

進捗や突如チャットに投下されたメテオフォール(仕様変更)などを鑑み対応方針を立てて計画(どういう風に進めていきましょう)を変更。

変更したらチャットに投下。

メンバーが「どうなってましたっけ?」のときは、他のメンバーが「まつさん、これ投げてました!」とやってくれる(人頼み!)

こんな感じでした(笑)

細かく軌道修正していく、といったところでしょうか。

マンガの4コマ目が絶え間なくループする感じでしたねw

ドキュメント自体の変更は……ごめんなさい><

マンガでいいことを書いておきながらやってないことも多かったです。

毎日の終わりのステータスレポート(テスト進捗の現状報告)のときに載せる必要があったりするのでそこでドキュメントは変更したりもしてました。

 

GPT-4で作ったwebアプリを4つ公開【テストの練習などご自由にお使いください】

GPT-4で作ったwebアプリを4つ公開【テストの練習などご自由にお使いください】

 

 

ChatGPT(GPT-3.5), GPT-4など、急激にAIが能力を伸ばしてきました。

本当にいろいろなことができるので、作者もついついマンガを描かずに遊んでしまっています(笑)

 

遊んだついでに、Webアプリを4つほど公開しました。

GPT-4で出力されたコードをそのまま張り付けただけで、作者は改造もテストも何もしていません。

テスト設計の練習や、探索的テストの練習、バグ票を書く練習など、様々なテストの練習に使えそうです。ご自由にお使いください!

 

映画予約アプリ

WebApp : 

https://jam0824.github.io/MovieSeatReservationByGpt4/

Github

https://github.com/jam0824/MovieSeatReservationByGpt4

GPT-4に与えたプロンプト (仕様)

よくテスト技法のデシジョンテーブルの演習時に出てくる「映画館予約アプリ」です。

割引の条件が複数ありますので、テスト技法の練習に使いやすいかと思っています。

 

TODOアプリ

WebApp : 

https://jam0824.github.io/TodoAppMadeByGpt4/

Github

https://github.com/jam0824/TodoAppMadeByGpt4

GPT-4に与えたプロンプト(仕様)

非常にシンプルなTODOリストです。

テストの練習にも使えますし、このアプリをどうすればよりよくできるか、といったことを考える練習にも使えるかもしれません。

 

メッセージ投稿アプリ (テストの項目もGPT-4に出してもらいました)

WebApp : 

https://jam0824.github.io/BbsByGpt4/

Github

https://github.com/jam0824/BbsByGpt4

GPT-4に与えたプロンプト (仕様)

 

このWebアプリでは、テストの項目も出してもらいました。

内容は以下のページに張り付けています。

https://github.com/jam0824/BbsByGpt4

このテストケースは以前に解説したCPM法であり、テストすべき項目が足りません。

テストケースのレビューの練習にも使えるかもしれません。

 

ブロック崩しゲーム

WebApp : 

https://jam0824.github.io/BrickBreakerByGpt4/

Github

https://github.com/jam0824/BrickBreakerByGpt4

GPT-4に与えたプロンプト (仕様)

 

GPT-4を使ってみての感想

公開したアプリはすべて出力されたコードをコピペしただけです。

コードを見ても「それなりのエンジニア」レベルです。

バグはさておき、これだけのものが仕様を説明しただけでそれなりにできてしまう世の中になってしまったわけです。

これからGPTが幅広く活用され、我々の仕事分野に入ってくることは間違いないでしょう。

開発エンジニアであれば、簡単な部分はGPTに書いてもらって、それを読み解きコードの考慮不足部分を補ったり、効率化や全体調整するような能力が求められていくようになるかと思います。

テストエンジニアであれば、テスト観点を出す際やテスト設計の際の壁打ち役になってもらったりすることも出てくるでしょう。

ただ「メッセージ投稿アプリ」のテスト項目でも示した通り、「AIとしてはすごい」であるだけで、実用できるかといえば今はまだまだです。

これらのどこの何が悪くて、どういったところを追加しなければならないのか、ということを判断できる必要があります。またどういったところでならGPTを使えるかも判断できる必要があります。そういった人が今後はより重宝されることでしょう。

そのためにも、テストや自分の分野についての勉強は不可欠ですし、技術を身に着け、経験を重ねることもとても大切となってきます。

AIに仕事が奪われるどうしよう!ではなく、技術を身に着け、AIを活用し成果を上げられる人になっていきましょう!

 

 

128.テストプロセス その⑩

128.テストプロセス その⑩

今回は「テスト完了」です。

自社開発のチームだったりすると、結構なおざりにされるプロセスです。

 

まずはテストサマリーレポートの提出があります。

テストサマリーレポートは、どんなテストをしたのか、テスト結果としてどうなのか、残ったバグとそれに伴うリスクはどんなものなのか、といった情報をステークホルダー(関係者の意味)に伝える資料です。

これによって、ステークホルダーは意思決定を行います。

作者の経験上(web/app系自社開発)では、問題などについてテスト完了より前にすでに話し合っていて、テスト完了時には残バグなどの対応方針が決まったうえで完了、が多いかなといったところです。

 

残バグについては、マンガに書いたようにわかってること、わかってないこと、リスクを伝えましょう。

それと、放置はしないで対応方針を決めて(もしくは対応しないことを決める)優先度をつけて、バックログに積むなりしておきます。

ちゃんと積んでおかないと、新機能実装に追われて放置されることが多いです。

(ユーザーに言われて慌てて直すまでがセット)

作者は残バグを優先度順にリスト化してテストサマリーレポートに載せてました。

 

マンガに記載していないところだと、テストデータなどのテストウェアを次回も使えるように整理、保管します。

テストデータは使いまわしがきくようにできるのがベスト……と作者も思ってやっているのですが、結局新しいデータを作ることも多かったりします(汗)

テストケースは記憶が新しいうちに編集や追加をしてしまって次のスプリントに備えたりしています。

 

ふりかえり会

カイゼンのサイクルを回すためのカナメが「ふりかえり」です。

次から次へと案件が来るので忙しくて飛ばしてしまう気持ちもわかるのですが、やらないと次回に繋がらず、なかなか進歩もしないのですよね。

非効率なプロセスは非効率のまま、ただ忙しさに追われてひたすらこなす、ということになってしまいます。

そのことについてのマンガ(寓話?)も以前描いたりしました。

 

加えて、ふりかえりのような場がないと情報の共有もあまりされなかったりすることもあります。

自分が問題だと思ってるし他の人も問題だと思っているだろう、きっと誰か対策してくれるだろう……

と思っていると、自分しか気づいていなくて、対応もされないということがあったりします。

 

ふりかえり会の最初のころは意見が出ないこともある

最近の現場だと、ふりかえり会をしていたのですが最初は全然意見が出なかったです。(そこそこ人数が多い現場)

内省といいますか、起きたことに関してどれだけ情報が得られるか、考えられるか、といったことには慣れが必要なのかもしれません。

よかったことも問題も感じないし何かするならすればいい、という場合が結構あります。

(それはそれで、特に問題なし、という意見でよいと思う)

毎回続けていくと徐々に意見が出てきていました。

 

それと「気づいた時にここに書いておいて」みたいなこともやりました。

これは言った時には効果がありました。しばらく経つと使われないシートが爆誕するだけなので、もしその方針で続けるならしつこく言い続ける、が必要そうでした。

 

あと、やたらしゃべる人がいるとみんなその人任せになってしまう、なんてこともありました。

この辺はファシリテーターの腕が必要かもしれません。

 

127. テストプロセス その⑨

127. テストプロセス その⑨

さて、テスト実行です。

テスト実行では、今まで準備してきたことを進めていきます。

 

語ることも多くはありませんので、作者の経験の話を書いておきます。

作者はWeb系App系ゲーム系なわけですが、システムテストのテスト期間はおおよそ3日程度、長くて5日くらいが多い印象です。

大変だったのはゲームでした。

イベントが週替わりで回っていまして、システムテストの期間は3日間、テストケース数は1万件くらいでした。ガ〇ダムなゲームで、ステータスの反映など確認がかなりありました。テスト実行も大変でしたが項目を作るのも大変だったことを覚えていますw

(イベント一つずつにQA担当者1名、テスターは25名くらいの体制)

 

ゲームもアプリも期間も短くやることも多いですから、とにかく事前準備が命。

そこがミスっていると、もう取り返しがつかない状態に陥ったりするわけです。

さらに計画してたからといってそれ通り進むかというとそうもいかず、リーダーをやっていた時は毎朝「今日はこういう風に攻めていって、誰々さんと誰々さんにはこれを任せて、もしこうなった時はこっちの計画に移して……」と考えながら会社に通ってました。ちょっとした軍師気分ですねw

 

CPM法

コピー&ペースト&モディファイ法の略称です。

簡単に言えば仕様書のコピペです。

例えば仕様書に「メールを送信できる」とあった場合、「メールを送信できることを確認」と書き換えてテストの項目を作る方法です。

これは根底に「仕様通り動きさえすればオッケーだろう」思考があります。

作者が回ってきた限りですとこの現場は非常に多く、なにが悪いかもわからない人も多いかもしれません。

例を出すとしたら……

 

仕様書

「年齢に数字を入力すると、プロフィールページに反映される。数字以外の場合はエラーが発生」

これからテストの項目を作ると……

* 年齢に数字を入力し、プロフィール欄に遷移する→期待結果:プロフィール欄に入力した数字が反映されている

* 年齢に数字以外を入力する→期待結果:エラーが発生する

 

こんな感じでしょうか。

数字といっても、整数なのか、小数は許容なのか、inputboxでnumberのみの制限にしててもeは入るけどどうなる、などなど考えられます。

また、数字以外の文字も、全角の数字はどうなるのか、改行文字、スペース、そもそもnull(空白)の場合はどうなる……ということがあります。

あとは、エラーメッセージは何さ……などもあるでしょうかw

実は仕様書に全てを書く、ということはないのです。(現実的でもない)

 

そのようなわけで、上記のテスト項目では、先に挙げたようなパラメーターのテストは行われません。

前回のブログでも書きましたが、テストが不慣れな人がテストする場合、数字を試すなら1だけ入れて確認、数字以外の場合はaだけ入れて確認してOKとなるでしょう。

そんな変な入力する人はいない、という方もいますが、ターゲットにもよります。

ユーザーが1万人いれば、何かしらする人はいるわけです。

 

これは、テスト分析やテスト設計が全く考えられていない状態です。

仕様書をなぞればオッケーだろう思考になっていますので、もし自分がいる現場がこんな感じなら「他にテストした方がいいことはないんだっけ?」を考えるのがよいでしょう。

 

その昔、開発者ばかりの現場ではこれを見せました

前の現場では、テストは実装通り動くか確認する、仕様通り動くか確認する、といった認識でした。

Unit testは確かにその通りなのですが、プロダクト全体をテストするとしたらその考えのままだと本番でバグが出ます。

理由はシンプルで、バグを探すテストをしないから本番でバグが見つかるわけです。

 

とりあえずSpeaker Deckにあげておきます。

テストがあまり浸透していない状態の開発者向けの資料ですから「まずは考えよう」くらいの話しか書いていないですw

speakerdeck.com

 

 

 

 

 

 

126. テストプロセス その⑧

126. テストプロセス その⑧

さて、テスト実装です。

テスト実装では、テスト設計でハイレベルテストケース(具体的な数値などではないテストケース)をローレベルテストケース(具体的な数値などが決められたテストケース)に落としていきます。

あとは、マンガでも描いたように「テスト実行のために必要な準備を全部やっておく」プロセスです。

作者の経験上、テスト環境の準備やテストデータの準備なんかは早め早めに着手した方がいいことが多かったです。

開発者に依頼する必要があることがあったりするんですよね。

ギリギリに言うと向こうが困ることもしばしば。(大抵は「いえいえ、大丈夫ですよー」って返ってくるけど、無理させてる場合も結構ある)

他にもテストで使うツールの準備、テスト管理ツールの準備、新しく入ってきたメンバーの初期教育(テスト入る前までに基本的なアプリの知識をつけておいてもらう)みたいなこともありますね。

 

テストデータの準備の自動化は費用対効果が高いことが多かった

作者がweb系App系ゲーム系を周ってきてるからかもですが、大量のデータが必要だったり、特殊な状態のデータがリストが最大になるまで必要だったり……そんなことが多かったです。

これ、手で作ってるとつらいのです。。。

単純作業の連続ほど疲労するし、時間と共に効率が落ちるし大変です。

それらが単純作業であればあるほど、自動化できたりします。

そして効果が大きいです。

大層なツールを使わなくても、スプレッドシートでGASを使ってできたりとか、E2E自動テストツールの使う練習の一環として、といった感じで作れることが多かったです。

作業時間が圧倒的に縮みます。

たとえば、記事100件作る。

たとえば、キャラ100体作る。

これがサクッとできた日には感動すらします(笑)

 

作者は、メンバーが強いならテストケースの粒度が荒い場合もよくある

と、いうとエライ人から「どういうテストしたかわからなくなる!」「証跡として意味をなさない!」と怒られそうなわけですが、メンバーのスキルが高い場合、作者はよくやります。

その場合、テスト実行時にメンバーはテストの項目ひとつひとつをテストチャーターとして簡易的な探索的テストをします。

前提条件をガッチリ決めた時よりバグを見つけてもらえることがよくありました。

(ちなみに作者がつくるテストケースには「テストの意図(何をテストしたい項目なのか)」というはほぼ必ず書いている)

では全部のケースが粗いのかというとそんな風にもならず、単純なケースは粒度粗く、パターン分けが必要でしっかりと確認したい場合はパラメーター設計を細かく……と考えることも重要です。

 

あともう一つのメリットとして、作者もずっとテスターもやっているのですが、値までしっかり決まっていると「作業感」が妙に強いのですよね。

遊びがないといいいますか、淡々としているというのか、「目標をセンターに入れてスイッチ」というのか……。

それが本来は正解なのですが、メンバーのモチベが下がることもあります。

 

もちろんデメリットもあります。

先に書いたように、エライ人が言うようなことが発生します。

何で確認したのかが追えなくなります。

本番障害が出たときにテスト項目がPassになっていることもあるわけです。

それに、テストのスキルが浅い人がそのテストケースを実行する場合もアウトです。

「~に入力」みたいなケースがあった場合、慣れた人ならHTMLタグから長文、絵文字、空文字、改行のみなど色々試しますが、テストスキルが浅い人だと「あ」といれるか「てすと」と入れて終わります。

(ついでにいうと開発者がテストするとなぜか"test"しかいれない人が多い気がする)

 

 

125.テストプロセス その⑦

125.テストプロセス その⑦

テスト分析では「何をテストするか」を考えました。

ただ何をテストするかを考えただけでは、それをどのようにテストすればいいかは考えられていません。

(何をテストするかだけ考えて、仕様と照らし合わせて確認するだけという現場もたくさん見ました)

 

テスト設計では、テスト分析で挙げたテストするモノ・コトをどうテストするかを考えていきます。

この時、「テスト技法」を使ってパターンを出していったりします。

例えばマンガに描いたように同値分割法などです。

テスト技法の話は……たぶんそのうちテスターちゃんでも描くかと思います。

きっと。

 

テスト設計では「ハイレベルテストケース(高位レベルテストケース)」に落としていきます。

ハイレベルテストケースは具体的な値や期待結果を伴わないテストケースです。

マイヤーズの三角形で例えるなら……

(マイヤーズの三角形は3辺の辺の長さを入力すると、それが正三角形か、二等辺三角形か、不等辺三角形か出力するプログラム)

「正三角形と出力されること」を確認するのであれば、「同じ値の自然数を3つ入力する」といった粒度になります。何の数字を入れるかまでは踏み込んでいません。

ちなみに「5を3つ」と具体的になるとローレベルテストケース(低位レベルテストケース)と呼ばれたりします。

 

あとは、どの仕様のどこの話なのかを明記しておくと良さげです。トレーサビリティ、なんて言ったりします。

仕様変更があった時にパターンを考え直すのが楽になります。特にアジャイルなどで継ぎ足し継ぎ足しで作っていくシステムだと様々な変更が入るので、後々になって助かるヤツだったりします。

 

テスト技法でのパターン出しの話ばかり書いてしまいましたが、他にも負荷を測る場合は何のツールを使うかといったことなどなど、「どのようにテストするか」全般を決めていくことになります。

 

テスト技法を学ぶのなら

以下の本をお勧めします。

練習帳でして、例題を解きながらテスト技法を学ぶことができます。

テスト技法を学ぶときは、自分たちが今扱っているシステムならどこに適用するのがよさそうか、ということを考えながら進めると、より力になると思います。

 

 

 

124.テストプロセス その⑥

124.テストプロセス その⑥

今回はテスト分析です。

やり方の例など細かな話はまた後で行う予定です。

この辺を説明するとなると先が長くなりそう……なんて思ってしまいますね(^-^;

その際は恐らくマインドマップやテスト観点出しのお話になるかと思います。

気になる人は以下の「マインドマップ本」を読んでみるとよさそうです。

 

作者は、テスト分析とテスト計画をよく行ったり来たりしていました。

テスト分析すると「あ、これもあった!」となり、テスト計画に記載しているテストのスコープやアプローチなどを修正したりするわけですね。

まだテスターちゃんではテストコントロールの話に行ってないので書いていないですが、テスト計画は作りっぱなしではなく更新していきましょう。

絵にかいたモチになってしまいます。

 

不安だから全体的に

作者が前職でよくやっていたのは、開発者や企画者に

「不安なところはありますか?」

ヒアリングしていました。(テスト計画時のリスク出しの時に行っていたけど)

そうすると開発の人からは

「~~~の部分がレガシーコードをいじるからコワイ」

とか、企画の人は

「~~~は他サービスとの依存関係が複雑だからミスるとヤバい」

など話を聞いていくと、資料からはわからないことや内部的な話など様々なことが聞けたりします。

 

作者はずっとwebやapp系でQAをやってきていますが、「これを見ればわかる」ような資料がそろっているところなんて見たことがないです。

関係者からしっかり話を聞く、気になったところを質問する、関係者の頭の中にだけあるものを形として出力してもらう、ということが必要だったりします。

 

 

2022クリスマススペシャル「勉強会で学んだことの活かし方」

2022クリスマススペシャル「勉強会で学んだことの活かし方」

この記事は「ソフトウェアテスト Advent Calendar 2022」の24日目の記事です。

 

その昔いた会社でこういった話が出たことがあります。

「テスト系の話はフワッとしたイイカンジの話をしてるけど、結局どうやればいいかわからない。現場でのやり方を教えてくれ」

気持ちはわかりますし、テスターちゃんが生まれた背景もこういったことからだったりします。

ただ、こういったお話をする人は「これさえやればうまくいく!そういう方法がある!」という思考がありそうに感じます。

やり方は一例を示すことはできます。

ですがそれは自分たちのやり方であって、それが他の人でも再現性があるかというと、マンガで描いたように条件が異なるのでうまくいかないことが多いです。

なので、聞いたことをそのまま鵜呑みにするのではなく自分で考えることが大切です。

「イイカンジの話だけど結局どうやるの?やり方教えて」

から

「イイカンジの話を聞いた。自分のとこで使うにはこういったことをすればいいんじゃないか」

への思考のグレードアップです。

今回はそんな話をマンガにしたためたつもりです。

 

具体化すると可能性を狭める

続きを読む