テストする人。

ソフトウェアテストってわかんない。テストとQAのゆるゆるブログ。

人によって違うモヤモヤってなぁに？～エンジニアとテスターの問診～

ということでポエム。

このあとに、ちょっとTweetしたのだけど　おそらく患者さんと医者に似てるんだと思う。

患者はこの場合、エンジニア。 私は医者。

エンジニアは、何となく不安な部分を抱えてるのだけど上手く言えない。

  • エンジニアAさんは、やたらと膝を気にしてるし でも本当は腰が悪いかもしれないし、膝も腰も悪いのかもしれない。

  • エンジニアBさんは、腰が痛いと最初から言ってくる。 本当に腰だけで健康になった。

  • エンジニアCさんは　よくわからないけど身体がだるいと言ってきた。 やっぱり腰が原因だった。

  • エンジニアDさんはどこもかしこも痛いと言ってくる。 焼けるように痛いって。 でも原因は腰だけ。

そうした場合に、できるだけ「腰」という原因を早く発見してあげたい。 また、本当に腰だけかを適切に効率よく発見できないのかなー。

その不安は、前兆のときもあるのだけど 本人の「不安がり度」にも依存していると思っていて そこを　ある程度あらかじめ安心してもらって できるだけ適切に早く診察ができないのかな。と思った。

というところで、書いていて2つ気づいたこと。

  • こんなときは？　みたいにFAQみたいな何かしらの指標を提示しておくことができれば、事前に本人が自覚できるのかな？
  • テストをする前に事前に問診票を作ればいいのかな？

なんか、とってもそんな気がしてきた。

いいんちょを継続した

はじめに

下書きのままあっためてたエントリー。 公開しようかどうしようかと思っていたけど、来年も実行委員長をやろうと決めたので 公開することにした。

ちなみに、そのまえの　いいんちょの話 いいんちょをやってみた - テストする人。

---

今回もいいんちょをやった。 いよいよ一人で。

どれだけ一人だと（気持ち的な）責任が自分に降りかかってくるか嫌というほどわかった。

まず、大前提としてシンポジウムは みなさまのおかげで盛会だった。。 それは 登壇者や参加者、実行委員とみなさまの協力や応援があってこそ。 自分自身は3年関わってきた中でも一番反省した。

当日は我慢したけど、自宅に帰って泣いた。*1 そのくらい反省することがあった。

自分が長としてやることに関してマイナスなことをエントリすべきか悩んだけど やっぱりそういうのも公開してこその社外活動なんじゃないかと思って、 このエントリをもって、来年度はさらに頑張るために公開してみる。

登壇者にたいして

  • 失礼な態度をとってしまったのではないか
  • 何度も連絡をお伝えしなければならない状態になってしまい、お手を煩わせた

参加者にたいして

  • お金を出していただいていることをちゃんと意識できていたか
  • そのお金にたいしてのおもてなしをスタッフ全員考えてできていたか
  • アンケートは知っている人は優しさ加点をしてくれたのではないか
  • 今日の機会がソフトウェアテストの勉強のキッカケになるかもしれないと考えていたのか
  • これが機会損失になるかもしれないのに

アンケートに関して

  • 基本的に高得点
  • 悪いところはだいたい、自分に関するところ
  • 身内からもらったであろう評価が甘いということは、気を使われているということ
  • 評価は甘くてはいけなくて、高くないといけない

実行委員にたいして

  • 育成ができていたのか
  • ボランティアの中でどこまでをもとめるべきか

登壇したことに関して

  • 何とかなるとおもっていた
  • 委員長しながら、周りが見えてないならやるべきではないのではないか
  • その分のフォローを前もってみえてなかった
  • 結果、すべてにおいて中途半端になったのではないか

今後どうするのか

結局のところ、自分が見よう見まねでやっていたこととか、 今まで何とかできたからと慣れなのかたるみなのかそういうのが 確実に感じてしまったんだと思う。

基本ポリシーは「ベストエフォート！みんなで楽しんで！」だと思ってるので ちゃんとがんばろう。

*1:理由としては、私なんかがこんな活動を引っ張ってやってるのがそもそも間違いなんじゃない？とか私ごときが社外活動なんてすべきだったのか？とか、そういう自己嫌悪

非エンジニアの人に伝える「だからシステムを作るのは面白い」と、そこからの「テスターとしてのお仕事」

ランチでのこと。 バックオフィス（という言い方が最近流行っているみたい）の方に「モノづくりをする人は作るのが楽しいッて言うけど、それはどういう気持なの？イメージが沸かなくって」 というような話になった。

仕事として楽しいということ

割りとエンジニアとかって「作るのが楽しい」は基本マインドだったので
目から鱗というか、ハッとした。

会社とか社員が楽しいというより、作ってることが楽しかったりすると思う。
それを非エンジニアとか非ITとか非モノヅクリの人にどのように説明するのがいいのだろうか。

積み木にたとえてみた

即興で考えたにしては、上出来だと自負したのだけど
きっと何かを作るのが楽しいの感覚は
「積み木でお城を作る」
とかに近いのだと思う。

実際は、それを最初に発注するお客さまがいたり
その作り方や積み木を提供することでよろこぶユーザーさまがいたり
納期があったり
色々あるのだけど。

とってもシンプルなことは、こんな感じではないかな。

エンジニアにとっての個々のこだわり

ここで「エンジニアによっても全員楽しみ方って違うよね」という話がでた。

それも同じように積み木で例えてみた。

ある人は、同じ色でつくり上げることを楽しいと感じるかもしれないし
ある人は、少し組み替えることで、新しい形を簡単に作れることを発見するのが楽しいと感じるかもしれない
単に「城」を作るだけが楽しいと思うかもしれないし
いかに速くつくるかが楽しい人もいるかもしれないし
もしかしたら「積み木以外のもの」をあわせることで新しいお城を作るのが楽しい人もいるかもしれない

どう売れるかとか
どうお客さまの要求に応えるか
どうコストをかけないか

これらの視点もはいるけど、もともとの楽しいは上記のような感じなのかなーと想像した。

同じようにテスターの楽しさを考えてみた

それでは、私がテストする上で楽しいこと。

前にワタシ的テスターのお仕事の資料を作った
この辺で発表した資料

www.slideshare.net

今回のものを例にすると、やっぱり同じように例えられるなぁと思った。 （おにぎり試食人じゃ、想像力欠如しそうだし、無理があったのかもしれないｗ）

基本的には「壊すこと」がお仕事なのかもしれないけど、 どちらかというと、ただ乱暴にぶっ壊すわけではなくて、 同じ色が揃っているのに、違う色にあえて変えてみたらどうなるんだろう？とか
この三角の積み木の部分を四角のに変えてみたらどうなるんだろう？とか
トンネル作ってるから、列車を突っ込んでみたらどうなるんだろう？とか
違う素材のものをさらにあててみたらどうなるんだろう？とか

そういう興味でやっているのかもしれないなぁと。

それで、「ここ、こうやると崩れちゃうよねー」とか話しながら 「じゃ、こうしようよ！」って提案したり話したりするのが楽しいのかもしれない。

そういう意味では、一人遊びよりも
実際に作った人とやるから更に楽しいよね。

と思うのが私がテスターとして楽しいと思うところなのかもしれない。

一緒にお城ができあがる過程が好きなんだと思う。

社内で社外活動の話をしてみた

本来は読書発表をする場で、どうしてもエモい話がしたくなって かなり自己満足度だけは無駄に高い話をしてみた。

www.slideshare.net

あとでアンケート結果が来るのだけど 毎回社内ワーストなので、もう気にしない（本当は泣いてるかもしれないけど）

でも、それなりにいいこと書いてる。 もっとちゃんと書いて説明した方がよかったのとか、重複もしてるけど

社外イベントに参加するだけでも 出来ることはいっぱいあるし 得られることはいっぱいあるし 私、かわれたよ。

というところが、ちょっとだけ伝わったら嬉しいな。

正直、SNSに色々懇親会の食べ物だとかアップしまくって こいつうざいなーとか その後のツアーとかの写真で あいつ何しに行ってんだよーとか

思う人も当然いると思ってて

それはそれで理由があることをちょっとだけ知ってもらえると 嬉しいなーとか思ったのでした（それでもウザいと感じる人はいらっしゃると思うので、そっ閉じしていただければ幸いです）

質問を受けて思ったこと

「やった気になってその場で満足してしまうから勉強会が嫌い」 「そういう『やれた気持ちになって』慣れ合いになってしまうのが嫌」

という話を聞いて、あー、確かに思うところはあったりします。

その時だけで完結しちゃうのは、きっと良くない。 最近は自分の勉強会でKPTA使うようにしているのとかは その辺を改善してもらいたいという思いが強いのかもしれん。

明日から、終わった直後から何かをちょっとだけアクションする、アウトプットする てことが大事なんだろうなー。 継続的に何かを出せるようになる。ことが大事なんだな。

（あー、だから最も手軽なSNS厨なのかもしれない）

テスト設計コンテスト東京予選にはるばる来てるよの話

テスト設計コンテストとは

NPO法人ASTERが主催するテスト設計を決めるコンテスト。 http://aster.or.jp/business/contest

テストベースと呼ばれる要件定義書（ASTER作成）を基に、どんなテストをするかというものを設計して設計成果物（ドキュメント）とプレゼンで優劣を決定する。

テスト設計てなんぞや？

　特に大規模なシステムなどの場合、いきなりテストフェーズで気ままにテストしてしまうと重複や漏れ、バグの見落としがあります。

また無駄な工数がかかってしまう為、その戦略としてテスト設計を行うと（勝手に）思っています。

　ちなみに、わたし自身は独り身テスターで、上に書いている「大規模システム」でないこともあって、「テスト設計」としてきちんとアウトプットを出しているまではありません。テストのスタイルとして（なんとなく脳内で）設計している状態のようです。 実際よくわかっていません。（模索中です）

行った目的

  • テスト自動化カンファレンスの前日に開催されている（予選の観戦だけに東京行くわけにもいかず、連日であってラッキーだった）
  • 九州では今のところ予選はなく、書類選考のみ（参加チームが増えたら予選もあるはず）
  • 私自身、過去2回出たことがあるが、いずれも予選敗退
  • 予選に出て、モチベーションをあげたいなぁ（次回）

出たチームとか

東京は11チーム *２グループに分かれてプレゼン

出ているチームの出たキッカケ

  • 2～3年でチャレンジしてみよう
  • 設計コンテストの決勝を観に行って、観るだけと参加しているのと全く違うと気付いた。一人でやってみたいと思った。

どんな会社が出てるの？

  • 企業枠として、某大手メーカーのテストチームや、第三者検証の会社
  • 個人枠で、各メーカーや第三者検証の複合チーム
  • 一人で参加（某メーカー）

所感

まずは、 参加できてよかった！

参加できてよかったところ

  • 決勝だけでは上級レベルすぎてついていっていない分、予選で自分と同じようなレベルの人などのプレゼンを聞いたことで、自分のわかっているところ、ダメだと思ったところ、良かったと思うところが理解しやすかった
  • 最近のテストだと「やってみてなんぼ」「バグは出た時になおせばいいやん」という傾向があるなかで自分に対する気付きを得るにも、俯瞰してみるにもやはりテスト設計は必要だなーと思った
  • 経験や主観でテストしていたものを設計することで全体を俯瞰することができ、自身の抜け漏れの早期発見につながる（はず）

自分が分かってないなぁと思うところ

テストアーキテクチャ― is 何 どのチームもテストアーキテクチャ―という項目でマトリックスやモデル図や機能関連図を使っていることは理解できたが、結局テストアーキテクチャって何よ？という目的や意図がわかっていない。

他にはテスト要求分析やテスト詳細設計などがありますが、そこは何となく理解できているレベル。というより、テストアーキテクチャ―is何が決まらないとその前後に発生する要求分析やテスト詳細設計がどこまで？どこからすればいいか分からなくなる。

おわりに

重複になりますが、参加できてよかったです。本来なら、テスコンに参加した上で観ることが出来れば一番良かったのかもしれません。 　来年出る・・・かどうかは自分の身体と要相談ですが、やはり手と頭は動かさないとだめだなーと思いました。（聞いてるだけじゃだめだー）

追記

このエントリーで、テスト界の偉い人@akiyama924がテストアーキテクチャ― is 何？　を教えてくれた

なるほど。

テスト要求で、どんな要求があるか考えて テストアーキテクチャ―で、それらの要求ややらなければいけないことを「こうやるとスムーズにいけてるように出来るんじゃね？」を考える ・・・のかな。

それから、

テストアーキテクチャ―という言葉に振り回されて、大事なことを見失わないようにしたいな。 というか、多分「テストアーキテクチャ―is何？！」で、見よう見まねで手先だけ動かしちゃうとそうなっちゃうんだろーなー って過去の自分がそれだったんだね。とわかった次第。

広島でふつうのソフトウェアテストの勉強会を準備期間5日で勝手に開いた話

www.adventar.org

ふつうの広島9日目の投稿です。 前日は　ふつう＝ユニバーサルでアクセシブル | nishimotzの日記　でした。

九州生まれ九州育ちの私が広島のふつうの勉強会をしてみたお話を書いてみようかな。と思いエントリーしました。

※タイトルですが、本当は思い立ってから開催までは1ヶ月。思い立ってATND建てたまでが5日間

2015年11月15日（日）広島市でソフトウェアテストの勉強会をしてきました。

当日の様子: http://togetter.com/li/900636

なぜ5日で準備をしたか

  • 思い立って、つぶやいたら、運営メンバーがすぐ集まった
  • 思い立ったのが10月中旬で、紅葉の時期に広島に行きたい！（11月～12月上旬までにしたい）
  • 運営メンバーの都合がよい日がこの日だった（開催日決定）
  • 宿と会場をおさえろ！ 　→で結局5日間でひとまずの準備ができちゃった

5日間でやったこと

  • FBグループメッセージ作成（運営用）
  • 勉強会会場の調査
  • 宿の確保（最大8名まで泊まれるように）
  • 広島の勉強会コミュニティの調査
  • ATND作成
  • 勉強会カレンダーの存在確認→掲載のお願い
  • SNSでの開催情報確認

なぜ広島

今回、運営メンバーに広島在住の方はいませんでしたし、そもそも「広島でテストの勉強会を！」という声が聞こえてきたわけでもありませんでした。

主な理由

  • 関西のコミュニティの@NoriyukiMizunoと、合同で何かするときに「広島くらいは中間地点だよね」って話を以前してた
  • 中国地方がテストコミュニティ未開拓な土地（テストコミュニティ界隈でやっている人を聞いてなかった）
  • SeleniumのSlackコミュニティの運営者@oh_rusty_nailが地方在住でオフラインの勉強会ができない＞＜とお嘆きになっていた
  • クックパッドのテストエンジニア@Kazu_cocoaが中国地方出身と知っていたのであわよくば何か一緒にできないかなーと思っていたところ、TLでそういう話になった

開催するにあたって気を付けたこと

  • 楽にやる
  • 旅行いったついでに勉強会やるよー。くらいの感じ（実際そうだった）

f:id:underscore42rina:20151207123645j:plain

ボケてるけど、厳島神社のライトアップがどうしても見たかったんです。 最高にステキでした。

運営

  • 負荷にならないようにする
  • ネタは全員持っている、すでに登壇ネタを作っている人はそのまま使ってOK

お金的な話

  • 遠方メンバーは前日に勝手に観光しているので「旅行にきた」という自費でバランスがとれたかなと
  • 私個人は子連れ旅行（家計上で「家族旅行費」の科目）にすることで、家庭調和をはかった
  • 今回の会場は和室4時間で2000円弱とかなり安いところをさがせた（全員にカンパしてもらって賄えた）

勉強会の内容

www.slideshare.net

www.slideshare.net

www.slideshare.net

www.slideshare.net

www.slideshare.net

www.slideshare.net

ここからかいつまんでのお話だった・・・かな

もう一つ、全国のテストイベント（勉強会やシンポジウム）に行った話というのもありました。

うーん、濃い・・・

やったことによる効果

帰りの時間もあった中、4時間の勉強会＋お好み焼き屋の打ち上げまでほぼ全員に参加してもらって楽しかったです。 Twitterを見る限り、満足度も高かったと思います。

参加者

  • 13人（東京、関西、鳥取、福岡、広島）参加
  • 広島の勉強会コミュニティーの中の人たちがこぞってきてくれた
  • 登壇側も参加者側も濃いメンツだったので濃い時間がすごせた
  • 各地方のコミュニティ事情の話などを知れるのはおもしろい

運営

  • 運営メンバーが各地で勉強会開催していたり登壇したりなどのノウハウを持っているメンバーだったので、私が動くことが少なくて非常に楽だった（会場は他のメンバーがしてくれたので当日他に注力できた）
  • 会場にしろ発表にしろ、何かしらフォローしてくれる知見のある人たちがいるのはとても頼りになるし、お互い楽でハッピーだった
  • Togetterを参加者の方が作ってくれた！早い！広島すごい！

横のつながりが増える

参加者にしろ、運営にしろ、横のつながりが確実に増えました。（運営メンバーもはじめましてがいる）

これが次につながるし、話のネタになったり、何かのイベントにつながったりするし、アンテナを張りやすくするという効果もあると思います。

子どもへの効果

  • 親がやっている内容を見せるというのも大事かなと。
  • 空きの時間で厳島神社に行ったり、平和公園で原爆についての話をしたりと広島ならではの話もできた
  • 着替え以外の荷物は自分で持たせることができた
  • いっぱい歩いた
  • 娘の感想「楽しかったかは微妙だけど、行ってよかった」とのこと。

揚げもみじまんじゅうが美味しすぎて、子どもと二人で全種類制覇してしまった f:id:underscore42rina:20151207123847j:plain （ついでにいうと、その後クックパッド見て、揚げもみじまんじゅう自宅で作ってしまったくらいに美味しかった）

荷物を減らす

  • 娘と二人、公共交通機関を使ったのでバックパックで移動した
  • やろうと思えば荷物は減らせるのね

おわりに

　今回はたまたま運営メンバーが揃ったり、参加者もコミュニティ中枢にいるような方たちばかりだったのでラッキーが重なったところもありますが、開催して本当によかったです。

　広島最高。また行きたい、広島。

　知らない土地でノリと勢いで勉強会するのもいいですね。ノリのよい広島のみなさま、ありがとうございました。

軽微なバグ？だからこそ早く直そう！

※今回の軽微なバグと言っているのは「表記ゆれ」、「デザインゆれ」、「ソートの指定間違い」などを想定しています。

この中からキャップの開いたボールペンをさがしてください

１の場合

f:id:underscore42rina:20151119120911j:plain

２の場合

f:id:underscore42rina:20151119123705j:plain

・・・２の方が圧倒的に見つかりやすいですよね？ f:id:underscore42rina:20151119123810p:plain

テストではこのような特定のエリアから おかしなところ を探すことをします。 その際に、予めそのエリアに規則性がすでにあったり、見やすいと違和感があるものを探しやすいです。

逆に、その周りで同じような名前が何度もあったり、並びが統一されていなかったりすると、そちらに気が行ってしまいなかなか重大なバグも探しづらくなってしまいます。

また、きちんと整列していることで新たな発見（ボールペンの種類や色の関連性など）があり、そこから新しいバグや改善案を提示しやすくなります。

軽微なバグを潰す利点

  • 操作性があがることにより、他のバグを効率的に探せるようになる
  • 軽微なので基本的には修正も難しくないことが多い（修正箇所が多い可能性はありますが・・・）
  • バグチケットが増えなくなる
  • バグチケットが減らせる
  • さらに別の関連性を見つけることができ、新しいバグや発見がある
  • システムや思考の整理になる

余談ですが・・・

社内で最速でチケットを返すエンジニアがいます。 その速さは朝あげたチケットが午後には全部返ってきてる、すごい時は１つ前のチケットが、次のチケットを書いている間に返ることもあります。キャッチボールというより、トスバッティングくらいの速さです。

入社から5年んほぼこの座は変わっていません。

当然ながら、私がテストしている間に、データ移行の準備、サーバーの準備、他の案件の打ち合わせ・・・仕事が詰まっている状況で優先度がありますので、必ず誰でもできるわけではないと認識しています。

ただ、5年続けるにはそれなりの秘訣があるのだろうな。と思っています。

おわりに

　私自身、軽微なバグの対応は後回しでもしょうがないなと思っていたのですが、それがテストスピードやバグ発見の糸口になると最近気づきました。

　軽微だから後でいいや。と優先度を下げることも大事な判断だと思いますが、タイミングがあうのであれば先に対応することでテストがもっとスムーズになるかもしれません。