テストする人。

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

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

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

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

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

会社とか社員が楽しいというより、作ってることが楽しかったりすると思う。
それを非エンジニアとか非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年続けるにはそれなりの秘訣があるのだろうな。と思っています。

おわりに

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

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

オレオレテストアーキテクト（超妄想編）

おお、なんかすっごい偉そう。

 

もう、あれね、ただ「アーキテクト」って使ってみたかったです。すみません。の世界ね。

 

私がいる会社はテスター。。テスト専任者が私一人なもんで、

すっごくざっくりいうと　好きにしちゃっていい環境なんです。たぶん。

 

で、どうもこの地域の私が知っている限りのシステム会社は

まだまだテスト自動化も進んでないし

テストコードも書いててもユニットレベルだし。と

発展途上な気がしています。

 

気がしているだけです。

 

私が知ってることなんて、ほんの一部ですし

そもそも、テストコードについての知見がなさすぎます。

どこまでカバーしてんの？って分かっていませんし

テストコード書いてる方も、何がカバーできているか分かっていないと思います。

と書くと失礼ですね。。

 

えっと、憶測ですが、Unitレベルで、ホワイトボックスでGreenになった。とかではないかな。と思っています。

それは境界値テストなの？テストのパターンどのくらいしているの？

コードチェック？静的テストてこと？

 

・・・うーん、ちっとも分かりませんし、お互いにわかりあえそうにありません。

 

このへんの「テストに関する認識の違い」を正しくお伝えできるように

そして、どこまでテストコードを書くかとか、今回はこういう構成でテストしようとかを

計画立てられるようになればいいな。

 

と、最近感じています。

 

あと、せっかく数千にもなるバグチケットの活用。

資産を活かさないと勿体無いですよね。

唯一の私の資産なので。

 

頭のわっるい文章なので　ちっとも理解できていないことが浮き彫りになりますね。

1年でどのくらい変わるかな。

 

‘‘‘

から現在。一年半経過。

なんか、色々（主に考え方）とか関係性はかわってきた。

* バグチケットは相変わらず活用はできていない

　興味の対象がそれてきているので、また興味が戻ったら考える

* テストコードについて、このブログを書き始めたときはUnitレベルだと書いたのだけど、現在はUnit以外も書いてるときもあることがわかった。

　そしてエンジニア自身も全部テストコード書かなくてもいいんだ。とか、ここに関してだけはテストコード書かないと辛いよね。というような話を急激にできるようになった。（権限による制御とかの、実装もシンプル、動作もメニューが見える/見えないとかのシンプルなものの割に、人的ミスでバグが出やすいもの。さらに再起テストが全項目必須になって心が萎えるもの）とかはぜーったいテストコード入れておいた方がいいよ。とかの話ができるようになってとても嬉しいし楽しい。

　さらには「全数テストすべきかどうか」というような話もできるようになりました。

私もテストコードがどういうものか、ほんっとにさらっとだけ勉強して(Selenium Webdriver, RSpec, Turnipなど）何となくお互いが歩み寄りやすくなったこととか、それなりに説明し理解しやすくなったことが成果として出てきているんだな。と思います。

自分でもテストコード書けるとなおよし、ですが、Turnipとかの日本語で書ける内容でのレビューができることが次の1年くらいでできるといいなーと思います。

ビリギャルにならう

 

素直だったこと

ノリと勢いが常に大事

 周りに「イイネ」と言ってくれる大人や仲間がいること