変化に気がつくということ

@miwa719 いつも見てるからわかる変化もあるけど、いつも見てるからこそ気づかない変化もあるかもね(^o^)

— きたのしろくま（あだち） (@kitanosirokuma) 2015, 10月 15

長年愛用していたくるくるドライヤーがいつもと違う音を出すようになりまして（そろそろ壊れるのかな…）と思いつつ、それでもしばらく使っていたら、とうとう「パチッ、パチッ」という音と共に焦げ臭いが…。さすがにこれはダメだ…。

 

ドライヤーの側面を見ると「National」の文字が！型番でググったら2004年製でした。10年くらい使っていたのかな。すごいなあ。

 

新しいのを購入しました。 

CREATE ION クレイツイオン ロールブラシアイロン 32mm HSB-06R

今度のはアイロン型なので無音なんですが、これがとても良い！使用目的はどちらも同じです。くるくるドライヤーを使っているときは「音がうるさい」なんて思わなかったんですよね。全く気がつけなかった。耳に相当負担がかかっていること、その時は分からなかったんです。「テスト」を生業にしてる者として（ああ、やられた）って思いました。*1

 

*1:変化に気がつく話しをするつもりだったのに、変化（しないもの）に気がつかなかった話しになっちゃった。

サングリアの夜

Bar＋Gallery 殻々工房 KARAKARA FACTORY は、お気に入りの場所です。だから大好きな人や特別に想っている人を、連れていきたくなります。わたしは #toruby や #toteka でのコンテンツ委員長係ということもあり（いつかここで何かしたいなー）と、夢みていました。それがこうして実現できて、とても嬉しい。

 

「オトナとRuby」の「オトナ」ですが、実はあんまり深い意味はなくて、単にBarで夜の開催だから「オトナ」にしました。

 Photo by @you_ssk

 

それで今回のコンテンツはというと…、特別なテーマもないし、基調講演もない。パネルディスカッションもないし、ワークショップもありません。かといって、日頃の鬱憤(?)を晴らすような飲み会でもない。doorkeeper にも「パーティーをします」くらいしか書いてなかったはずです。

そんな曖昧なイベントが果たして成り立つのか、正直なところ不安もありましたが、終わってみれば、それはそれは素敵な場になっていました。

 

そんな「場」を作ったのは、世界中から集まった18名の参加者、おひとりおひとりです。みんなで作る「全員参加」のコンテンツ。素晴らしかったな。（コンテンツ委員長係、なんにもしてなかった…）

 

本当にありがとうございました。

 

みんな自分の話をして、聞いて、応えて、オトナだった。お客様がいない感じで、上質だったな。 しかし疲れた、オトナだから。

— seki at druby.org (@m_seki) 2015, 10月 11

 

 

そうそう 過去のブログ でも引用したことがあるのですが、この記事をまた思い出しました。

 

allabout.co.jp

 

ひとつは「様式」というものがありますね。どんな場にも様式があって、大坊珈琲店には大坊珈琲店の様式があったんじゃないかと思います。そして、そこに座った人が、自分もその様式の一部を担わなきゃいけないと思うことがあるらしい。

 

今回のオトナもいつもの #toruby の雰囲気を保ちつつ、みなさんが、みなさんらしくふるまっていたように感じます。ということは、もしかしたら #toruby という場にも「様式」のようなもの、があるのかもしれませんね。

 

大坊珈琲店には秩序があり、完璧で、非常にていねいでした。そんな言葉を並べると居心地が悪そうに聞こえますが、それがホスピタリティとともに感じられるのが素晴らしかった。その場所にいて気持ちを集中していると、自分も中に入り込んで、その世界に連れて行っていただけるような感覚でした。大坊さんとお客さまとのコラボレーションによって、空気が作られていたと思います。

 

あの夜、ていねいに作られたサングリアのるつぼの中に、みなさんと #toruby があったようにも思えます。

 

Special thanks : 殻々工房

 

わたしは、いくら混ぜても混ざらない個々と、全体の調和の不思議さに、サングリアを感じたのかもしれません。サングリアのレシピは無限にあるそうです。あの日のオトナが、あの日だけのものだったように。

そう、2015年10月10日の夜、みなさんは #toruby の世界に入り込んで、知らず知らずのうちに「オトナとRuby係」を演じていたのですよ。気がついてましたか？

 

テストプロセス改善以前のお話し

これまでわたしはいくつかのチームを転々とし、ウォーターフォール型や反復型のような開発の現場にいたり、独立したテストチームに所属し、外側から開発チームを見ていたこともあった。いまはアジャイル開発をしてるチームでテスターをしている。

 

そこで分かったのは、開発手法や所属するチームに違いはあれど、思ったことを何でも言えたり、起きてしまった問題を個人ではなく、全体の問題として捉えることができるチームの雰囲気が、わたし自身のアウトプットに大きな影響を与えるのだなー、ということ。

そう、開発手法なんて全然関係なかった！

 

わたしの日常

毎日少しずつモノができていく過程でテストしていくから、（あれ？おかしいな？）と思うことが、次のイテレーションでの開発アイテムになってる、ことはよくある。

それが明らかな場合（知っている場合）は、インシデントとしての報告はしないし、そこは実装してから改めてテストしよう、ということになる。

それが明らかでない場合は、その機能を担当しているプログラマに期待したことを話し、これから開発するアイテムなのか聞いてみる。その結果「ああ、それは考慮不足でバグでした」というのであれば安心する。

また、わたしの勘違いでその動作は正しい場合（＝仕様）もある。そのようなときは、新たな気持ちでテストをし直して、その結果をプログラマに話したりする。

 

そうではなくて、その仕様についてはまだ考えられていないとか、ちょっと前に話題になったけど、そういえばうやむやになっていますね、というケースもある。ほら、嫌なことが起きる前兆のような ザワザワ とした音が聞こえるでしょう。

こういった音にならない音や、いつもと違った匂いをできるだけ早く感じて、表舞台に出してあげるのもテスターの役目だと思っている。そして、わたしの日常では、そういった気づきを話すことが、推奨されているように感じる。

 

「誤報」になるとどうなるか

さて、わたしの報告が、実は仕様だった場合や、今後のイテレーションで開発されるアイテムだった場合に、それが気づきではなく報告のミス＝「誤報」であると認識されてしまうと、わたしのアウトプットは量も質も一気に落ちてしまう。

 

「誤報」は一般的に悪いイメージなので、できれば「誤報」は無い方がよい。わたしの誤報によりプログラマが調査や分析に、無駄な時間を使ってしまうからね。だから、わたしは「誤報」に敏感になり、「誤報」を恐れ、「誤報」しないように、より多くの情報を（プログラマに無駄な時間を消費させないように）自分だけで集めるようになる。

 

この時点で、嫌なことが起きる前兆のような ザワザワ とした音はもう聞こえなくなり、「誤報ではない何か」がタイムリーとは程遠いタイミングで報告される。

 

「ミス」には寛容に

ミスをしない人はいない。プログラマだってミスをするのだから、テスターだってミスしてもよい。ミスをしないことより、できるだけ早いうちにミスを見つけて、訂正できることが肝心である。（ミスをしなさいと言うことではありません）

 

何度も同じような「ミス」を繰り返してしまうような場合は、個人の問題（注意散漫なヤツだ！）と決めつけるのではなく、例えば、

• それはユーザにとっても分かりづらい仕様ではないのか？
• ミスを誘うようなテストケースの書き方になっていないか？
• 正しいテスト環境が作りづらいのではないか？

といったように、開発全体の問題として捉え、みんなで考えられるとよい。

 

 

なんで急にこんなことを書きはじまったのか分からないのだけど、そういえば今日は TPI NEXT（ビジネス主導のテストプロセス改善の本）を読んでいたんだっけ。

 

第4章 キーエリア 

• 「利害関係者のコミットメント」
• 「関与の度合い」
• 「報告」

 

第7章 さまざまな状況へのBDTPIモデルの適用

• 「反復開発手法への適用」
• 「アジャイル開発手法への適用」

 

このあたりを読んでいて、過去に経験してきたいろんな開発やテストを思い出して、お話ししたくなったみたい。

TPI NEXT? ビジネス主導のテストプロセス改善

この本は、先月開催されたソフトウェア品質シンポジウム 2015で、友人というか同僚に買ってきてもらったもので、翻訳者の湯本さんと皆川さんのサイン付きプレミアム本なのだけど、いつか薮田さんのサインももらいたいな。

 

 

XP主要プラクティス - 全員同席（Sit Together）について

わたしたちのチームは、毎朝同じ時間に同じ場所で、チケットの読み合わせをする。
朝会が終わる頃には、今日やるべきテストのイメージ（それはもしかしたらカジュアルなテスト設計のようなものかもしれないし、探索的テストの断片のようなものかもしれない）ができあがっていて、それをもとに毎日テストしている。

テストはラボで行う。ここにはチームのみんな（プログラマ、アーキテクト、プロの無職、テスターなど）がいて、それぞれが、それぞれの作業をしている。

たいてい複数のプロダクトが並行して走っているから、テストPCもその分だけ用意されている。テスターはテストするプロダクトに合わせて席を移動する。変わらないのは、隣にはいつもプログラマがいる、ということ。

これはテスターにとってとても心強いし、作業効率が良い。（無駄になるかもしれない時間が減らせるという意味でね。）

例えば（昨日と比べて動きがすこし違うような気がする…）と思うようなとき、これはチケットを発行して報告すべきだろうか、もう少し深追いしてもっと深刻なバグを探すべきだろうか…というようなことを考えたり、実際に作業して時間を消費してしまう前に、隣のプログラマにこう話しかければいいのだ。

「昨日と比べて動きがすこし違うような気がするのだけど、気のせいかな？」

そういえばこんな時もあったな。画面を見つめ（うーん）と首を傾げていたら、前に座っていたプログラマたちがザワザワしはじめて、心配して？見にきてくれた。言葉にしなくても伝わるって、素晴らしいと思う。

プロの無職がふらっと歩いているのを見つけたら、視線を合わせておいでおいでして（手で）、朝会で気にしていたチケットの動作を一緒に見たりする。

テスター同士の情報交換も、いつでもすぐにできる。

「いまこんなバグがでてるよ」
「これおかしくない？」「あー、おかしいね」「だとすると○○もヤバいかも」
「あのチケットのテストやってみたんだけど、まだ不安があるから一緒にテストしてほしいな（ペアテスト）」

次の日になれば、朝会でみんなの頭の中は同期されるのだけど、全員が同じ空間で作業しているからなんだろうね、それはチームに自然な会話と、適度なスピードをもたらしている。みんなが何をしているのか知っているし、わたしが何をしているのかも、みんなは知ってるはずだ。それがとても気持ちいい。

エクストリームプログラミング

とちぎRuby会議06 - 珈琲セッションのつくりかた

6月20日に開催した とちぎRuby会議06 - Regional RubyKaigi に 珈琲専門 猫廼舎さん が出張ドリップに来てくれました。どのようにして珈琲セッションをつくっていったのか、また当日の様子などを書き留めておきます。

用意したもの

• ミネラルウォーター
• バケツ2つ
• 食器洗い用洗剤、スポンジ、キッチンペーパー
• おぼん
• ゴミを入れるビニール袋
• ブルーシート（使わなかった）

公民館からお借りしたもの

• テーブル（作業台です）
• 電気湯沸かしポット
• はさみ
• 電源等

用意したツール

• 珈琲引き換え券
• 猫廼舎ステッカー（ここで作りました）
   

あらかじめ決めておいたこと

珈琲の配送

当初、参加者が各自珈琲を取りに行くことも考えたのですが、タイミング的に難しそうでした。

• テーブル毎に取りに行く時間を決める？
• タイマーにテーブル番号を動的に表示して取りに行ってもらう？（かなりスリリングというか無謀すぎである）
• 「珈琲できたよ！」「取りにきてね」の同期を、どうやって取ればいいの？

結局、講演中に立ったり座ったりするのもねぇ…ということで、どれもボツ。スタッフが運ぶことにしました。

テーブルの配置

これまでの会議をふりかえると、コンテンツの内容によって、わざとテーブルを置かずに椅子だけでやったり、毎回こだわりを持って工夫してきたなと感じます。
今回はテーブルが必須ですね。会場の東那須野公民館は過去に何度か利用したことがあったので、広さや間取り、テーブルの大きさなどは把握していました。

参加人数から必要なテーブル数が決まり、さらにそこから動線を考慮して、だいたいの配置図をホワイトボードに書き、イメージをみんなで共有。あとは当日設営しながら調整しました。

珈琲飲みたいぜ！の見える化

例えば「前のテーブルから順番に珈琲を置いていく」なら簡単なのですが、中には珈琲が苦手な人もいるわけで「わたしは珈琲が飲みたいです！」の意思表示をしてもらう必要がありました。

今回は受付で全員に「珈琲引き換え券」を渡すことにしました。飲みたい人は引き換え券をテーブルに置き、スタッフはそれを目がけて運びます。そして、珈琲を置いたら引き換え券を回収します。

朝から珈琲セッションの状態遷移図を書いてる #toruby

— miwa (@miwa719) June 14, 2015

珈琲セッションのはじまりをいつにするか
事前に @ogijun さんから、珈琲４杯あたりの所要時間を教えてもらっていたので、タイムテーブルにここまでで何杯、ここまでで何杯…と書き入れてみたりしたのですが、頭の中でシミュレーションすればするほど、不確定要素が出てきてしまうんですね。これは、もう当日になってみないと分からないなぁ…て。

とりあえず「まつもとさんの基調講演がおわったら珈琲を淹れてもらう」ことにして、あとはその場の状況に応じてうまく動こう！と決めたら、気が楽になりました。

当日のオペレーション

準備

定刻どおり本会がはじまりましたが @ogijun さんと @arton さんが来なくてハラハラしました。関くんは「さすが、安定してるなー」と言ってました。

まつもとさんの基調講演がはじまって少しした頃に、お二人が現れたのでホッとしました。よかったー。用意しておいた作業台（テーブル）に @arton さんの車で運んできた器材、用品一式を並べながら、設営開始です。

そうそう、公民館には冷蔵庫がなく、たまたま持ってきていた 凍らせておいしいカルピス がミルクを冷やすのに活躍しました。わたしってすごい！と思いましたが、誰もミルクを使いませんでした。というか、ミルクやシュガーがあることをアナウンスしてなかった！（ごめんなさい）

準備段階ではまったく気が付きませんでしたが、保冷剤を入れた小さなクーラーボックスなどを、用意しておくとよいのかもしれませんね。

珈琲セッション

基調講演がおわり @ogijun さんからお店の紹介の後、休憩をはさみ、一般講演とマルチトラックで珈琲セッションがはじまりました。

はじめは何をどう手伝えばよいのか分からなかったので、見学してました。（経験値は"ネルドリップ生まれてはじめて見たー"とかそういうレベルです…）

わたしのミッションは「カップに注がれた淹れたての珈琲を各テーブルに運ぶこと」だったのですが、

• 温めたカップの内側の水滴をふきんで拭き取る
• カップを温める
• 淹れたての珈琲をカップに注ぐ

…と、任せてもらえることが、少しずつ増えていきました。うれしい。

@ogijun さんがこの工程に入ったら、カップを温めておくとちょうどいいとか、まだあの工程に入ってないから、今のうちに下げたカップを洗ってこようとか、どのタイミングで何をしておくとよいのかが、少しずつ分かってきました。

また、何種類かのカップを持ってきてもらったのですが、このカップは小さいくせに口は広いから、運ぶときにこぼしちゃうかもしれない。だから、なるべく使わないようにしよう！とか、ふだんの開発の中で感じるような「ドライブ感」のようなものがそこにもあって楽しかったです。

それではりきりすぎて、カップを洗うときに力がはいり、持ち手の部分を破壊してしまいました。ごめんなさい。（わたしがノリノリで仕事しているとヤバい仮説、だいたいあってる）

途中、スタッフの池澤さんや中内さん、佐々木さんが手伝ってくれたので、心強かったです。また、飲み終わったカップを作業台まで持ってきてくれた人もいて、たいへん助かりました。

書籍『アンダースタンディング コンピュテーション』を使った、笹田さん音読＆解説による「いつもの勉強会」が中盤にさしかかった頃、全ての珈琲が淹れ終わりました。（だいたい60杯くらい）

アンダースタンディング コンピュテーション―単純な機械から不可能なプログラムまで

撤収作業

本会が閉会した後、懇親会会場に一番乗りしなくてはならなかったため、片づけや掃除は、ほとんどできませんでしたが、いつものようにみんなで協力して（参加者も巻き込んで）やったのだろうと思います。

床が少し汚れてしまったので（用意していたブルーシートを作業台の下に引けばよかったのかな…）と思ったのですが、ブルーシートはなんとなく猫廼舎に似合わない感じもする。床は拭いたらきれいになったので、今回は結果オーライということにします。

さいごに

はじめての試みで正直不安もありましたが、最後までやり切った！と感じられるセッションでした。@ogijun さんは、ほとんど休みなしだったのに、淡々とこなす所作がクールで素敵でした。でも、そのまなざしはあたたかい。

後日、この日のツイート（#toruby）を読み返してみました。みなさん美味しく飲んでいただけたようですね。

大きなトラブルもなく、うまくいってよかったなーと思っていたのですが、当日かなり緊張しながらも、司会業をがんばってくれた米澤さんが珈琲を飲めなかったことを、昨日、知りました。

バグが１つ見つかったら、大抵その周辺にもバグは存在しますので、他にも飲めなかった人がいるかもしれません。

わたしは味見と称して２杯、いや３杯は飲んだことをここに告白し、懺悔いたします。@ogijun さんから手渡しされた珈琲は、とても美味しかったです。

丁寧な仕事はチームに伝染する

先日、ある機能をテストしていたときの話。

いつもなら瞬時に画像が表示されるのに、今日は5秒くらい待たされる。おかしいな？と思い、別の画像で試してみるとすぐに表示された。どちらも表示自体には問題ない。画像に依存してるのかなあ…（もしかしたらそういうものかもしれない）と思ったのだけど、担当のプログラマOさんに見てもらう。

「確かに遅いですね。チケットあげちゃってください」

結論から言ってしまうと、作り方に問題があるということが分かった。（雑すぎる説明だな。大抵の場合はそうよね。）
ええと、表示するときに「無駄な処理」をしてるっぽかった。

わたしはね、Oさんが問題の画像を別のテスト環境にコピーして、確認していたのを知ってる。（テスト環境に依存しているのかを切り分けるためだと思う）

それから、その画像の内部的な構成を調べて、同じような画像を作っていたのも知ってる。（その遅い画像だけに起こる特有の問題なのか、同じような構成の画像を作ったときも、同じように遅くなるのかを確認するためだと思う）

OさんとＷさんでコードを見ながら、遅い原因を探っていたのも知ってるよ。

とにかく、その結論にいたるまでOさんが、地道にいろいろやっていたのを知っていた。

それから数日して、わたしは朝会でびっくりすることになる。（わたしたちのチームは毎朝チケットを読み合わせている）

画像表示が遅くなる件について、Ｏさんが話した内容はこんな感じ。

• ここが問題でした（コードレベルで）
• 具体的な修正方法
• 処理速度を計測し、その修正方法で問題ない（遅くならない）ことを確認した
  
  ふむふむ。
  
  
• 実際の運用を考えると、このような構成の画像が使用される可能性はとても低い
• よって、今回は修正しないことにしました
   
  えっ？
  修正しないの？
  
  

前にもブログに書いたけど、わたしが報告した問題を何がなんでも直してほしい、という気持ちはありません。
ここまできっちりやったのにコミットしないのかー。勿体無いにも似たような、驚きの気持ちというのかな。うん。

朝会が終わって自分の席に戻り、もうすることのないテストに思いを巡らせた。

（もし、これがコミットされたら、わたしや他のテスターがいつものようにテストするよね。あの修正方法だと、わりと基本的な部分にも手が入るから、問題のある画像だけを使用したテストだけでは済まされないな。影響を受けそうなところは、、、）

そうか、そういうことなんだ。もう、あの時にプロダクトとしてのコストや効果を考えて、修正しないことを選択したのだな…。

allabout.co.jp

料理でもカクテルでもコーヒーでも、ひとつひとつをていねいに作る。決して宝石のようなものを作るわけじゃない。単にコーヒーを一杯作るだけだけれども、ていねいに作る。そういうことは、それを見ている人に伝染するんじゃないだろうか。

丁寧な仕事はチームに伝染する、と思う。

わたしたちのチームのプログラマは、テスターが報告した問題や、問題とまではいかないけど気になることに対して、いつも真摯な態度で向きあってくれる。そして、こんなにも丁寧に製品を作っているのだ。

だから、わたしは丁寧に製品を壊していきますね。

テスターがコードを知るということ

先日いつものようにテストしていたら、おかしな現象に遭遇したのでプログラマAさんに見てもらいました。

わたし「こんな条件で動かすと、ほらこうなっちゃう。」
Aさん「あー、なるほど、そうなりますねぇ。バグですね。」

Aさんの頭の中のエディタにはコードが表示されているんだろうね。どこがまずいのか、だいたい分かったような顔をしていたから、わたしもホッとして、Aさんにそのチケットを引き取ってもらいました。

数日後、そのバグが修正されてきたので、よし大丈夫だろう、というところまで一通りテストしたのだけど、どう直したのかとても気になる。直し方によっては、テストが変わることもあるからです。

例えば、こんなバグがあったとします。

変数Aの初期値は0です。0のときは何も処理をしていない状態（初期状態）である、とプログラムが判断しているとしましょう。
処理がはじまると変数Aは0以外の値になるのですが、ある特殊な条件を与えると変数Aが0になってしまうことがわかりました。
初期状態ではないのに、変数Aが0なのでプログラムは初期状態だと判断してしまい、システムとしておかしな状態になります。

これが修正されてきたら、どんなテストをしますか？

バグが発生したときと同じように、特殊な条件を与えても、初期状態にならないことをテストしますよね。それから（特殊ではない）通常の条件を与えても、おかしな状態にならないこともテストしますね。

JSTQBで4つのテストレベルが定義されていますが、わたしはそこで言うところのシステムテストを担当しているので、ピンポイントな確認を行いつつ、システム全体として連携するような機能や状態に影響がないか、またユーザがやりそうなことも想像してテストします。

そして一通り確認して大丈夫かなーと思ったとき（このバグ、どう直したんだろう）と思うわけです。

変数Aの初期値を0以外に変えたのか、変えたとしたらどんな値にしたのか、その値は、また別の特殊な条件でその値（初期値）になったりはしないのか。それとも特殊な条件になったときに変数Aを0にしないようにしたのか。そうではなくて、初期状態の判断自体を変えたのか。まさか、システムの使われ方に応じて、初期値を変更できるように設定ファイルで外に出す、なんてことしてないよね…。

ほら、直し方ひとつで、気になることがガラッと変化し、テストすべき内容が変わってきませんか？

テストオラクル（test oracle）：テスト対象のソフトウェアが実際に出力した結果とを比較する期待結果のソース。オラクルは、実在する（ベンチマーク用の）システム、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。

— ソフトウェアテスト用語集 (@software_test) 2015, 6月 5

「テストオラクル」は、わたしがなかなか理解できなかった用語のひとつです。今でも分かってないかもしれない。

”コードであってはならない”なんて書いてあるから、テストするときはコードを見てはならん！みたいな印象を受けてしまうのだけど、最近は（そうじゃないかもなー）と思うのです。

誤解を恐れずに書くと、コードを知ることで、それまで見えてなかったテストが見えてくることがあるのね。それは時として、あまりやる意味のないテストを実施してしまうこと、を適度に抑制する効果もある。（そこで浮いた時間で、別のテストができる）

だから「わたしはテスターだからコードは知らなくてもいい！」「テストオラクルの説明にもそう書いてあるし！」なーんてガチガチに思っている人がいたら、そうじゃないかもしれないんだよね、と言いたい。

はじめの話に戻るけど、わたしはAさんのところに行って、一通りテストして大丈夫そうなことと、今回こんなテストをしたんだけど、直し方によってはテストが足りてないかもしれないから、どんな風に直したのか、教えてほしいと伝えました。

Aさんはメモ用紙を取り出し、図を書きながら、①その処理の本来あるべき姿、②今回どこが問題だったのか、③それをどう直したのか、をコードも交えて説明してくれた。

それを聞いて、わたしがもう少しやろうかなと思っていたテストの話もして、そういう直し方をしたなら、そのテストはやらなくても大丈夫そうだねーということになりました。

コードを知ることで、省略してしまったテストで見つかるはずのバグが見つけられなくなる（かもしれない）という危険性を十分知った上で、コードを知ることのメリットも大切にしたい。

ブラックボックステストをきっちりカバーし、グレーボックスなテストの領域にも踏み込み、まだうまくできないけどグレーボックスとホワイトボックスの間のテスト（そんなテストの領域があるのかわからないけど）にも、果敢に挑戦していく。そんな勇気のあるテスターになりたいなぁと思う。