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

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

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

１の場合

２の場合

・・・２の方が圧倒的に見つかりやすいですよね？

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

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

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

軽微なバグを潰す利点

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

余談ですが・・・

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

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

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

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

おわりに

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

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

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

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

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

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

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

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

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

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

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

気がしているだけです。

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

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

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

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

と書くと失礼ですね。。

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

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

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

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

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

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

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

と、最近感じています。

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

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

唯一の私の資産なので。

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

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

‘‘‘

から現在。一年半経過。

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

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

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

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

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

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

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

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

ビリギャルにならう

STORYS.JPから初の書籍化 学年ビリのギャルが1年で偏差値を40上げて慶應大学に現役合格した話 http://t.co/liFz9PX0D5 @popular_storyさんから 出てくるキーワードが私と一緒だｗ

— リナ？ (@____rina____) February 6, 2014

素直だったこと

ノリと勢いが常に大事

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

地域貢献ってなんだろう

「地域に貢献しているね」ってお褒めに預かる機会があったのだけど

ぶっちゃけ、貢献しようとかだいそれたことを思っているわけではない。

ずっとソフトウェアテストについて一緒に考えたり勉強したり、情報交換したかったのに周りにいなくって

だからもうこの地域には存在しないんじゃないかと思ったりして

最終的に今わたしが運営とか開催する流れになっちゃった・・・

という話。

なので、地域に貢献するために何かしたわけではなくて

自分に必要だったから　作るしかなかっただけなのだけど。

もちろん、「ないならつくろう」って　全てが簡単なわけじゃないし

今のこの環境だからこそ出来た（というより、スムーズにできてる）ことが殆どだけど

今の自分ができる範囲からちっちゃいことを始めるって大事だよなぁと思う。

「あぁ、これなら私でも出来そう」な範囲をはじめる。ってことか。

・自分のブログをはじめてみる

とか（完全に自分だけで完結できる）

・Facebookグループを作ってみる

とか（参加者に登録してもらわないといけないけど、作るだけなら登録すれば出来るわけで）

で、今が

・オフラインの勉強会をしてみる

の段階。

・・・で、肝心のテストの勉強はできているのかは聞かないでください(´・ω・｀)ｼｮﾎﾞｰﾝ

‘‘‘

で、今。

オフラインの勉強会は不定期ながらも続けることができている。

マリーアントワネットよろしく「勉強会ないなら、作ってしまえばいいじゃない」は嘘じゃなかった。

続かなかったとしたら、次に新しいものを作ればいいし、もしかしたらそれは私じゃない別の誰かが作ればいいんだと思う

縁

去年から縁あって、仲良くさせていただいている偉いｵｻｰﾝ*1がどうやらこれまた偉いｵｻｰﾝ（私の地元出身）と飲んでたらしくTwitterでやりとりをした。

地元弁のやりとりでそのｵｻｰﾝ達に受けたらしく電話することになった。

てかね、ｵｻｰﾝといっても、偉いｵｻｰﾝなので、電話になると敬語なわけですよ。

うん。電話出たけど、方言でないっすよ。

今度こっちに来るから、講演聴きにおいでよーって誘っていただいた。

どうやらUXの研究をしているｵｻﾝらしい。

丁度同僚にUXとテストを絡めた活動したいなー

って言ってた矢先だったので、まさに棚ぼただった。

後日その方の経歴を拝見したら教授で((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙした。

うん。偉いであろうことは分かってはいたけどね。

ご縁は大事。

一期一会も大事にしようと思って今日も過ごします。

*1:ｵｻｰﾝとTwitterのやりとり上書いていますがもちろん超尊敬するステキな方なのです

ドッペルゲンガーを見つけた話

 これも一昨年のはなし。

---

仲間を見つけた

いや、違う、ドッペルゲンガー。

いや、ちがう。

とにかく、同じような境遇のテストの人を見つけた。

私と話した感想が

まさか自分の日頃考えていることや抱えている悩みを

「～でしょ」って言い当てられた時は、どこの占い師かと思いました(笑)。

というくらい、一緒でした。

彼女はプログラマだったことがあるので

何となくの知識はあって

何となく動かしたらバグが出て

「まぁ、こんなパターンのデータ作ればいっか」でテストして

何となくOKて出荷したやつも　そんなに重大なバグが出ることもないので

現状うまくいってる気がする。

だから、

・体系化して

とか

・今までITの知識なかった人にも教えてあげて（テストオペレータの教育）

とか言われるけど、出来ない。

　↓

チェックリストのような仕様書作るけど、それじゃ自分が出してるようなバグが出せないし彼らでは気づいてもらえない。

　↓

じゃー、気づいた所全部洗い出せば体系化できる？

（そんな工数ねぇよ。動かしてたらバグが出るテストケース思いつくんだし）

つまり、こんな感じ。

そもそも、自分がテスト専属でやっているけど、

正しくテスト出来ているのかも実はよく分かってないし自信もないし

実際はお客様に不満のないレベルのものはできているようなので良さそうだし

でも、プロジェクトが増えてきたら　一人では限界がある。

どうしていいかわからない。

昔テスト界隈の人に現状を話してたら

「てか、今何か困ってる？」て言われたのを思い出しました。

困ってるんです。

自分がやってるテストが　どういうレベルのものなのかも分からないし

なぜ体系化できないか

どうやったら体系化できそうか

そういう悩みを持った人たちがこの世の中にいるのか

どういう勉強をすればいいのか、する必要があるのか

わからないんです。

私の場合も　まったくこの状況で（しかも、現場の状況が変わったわけではない）けども

とりあえず、仲間を見つけよう、何かの情報を入手できればと

MLに参加したり、シンポジウムに参加したり、勉強会に参加したり。。

1年ちょっとかけて、色んなお知り合いの方はできて

勉強することで、分からないが分かるようになる　ということは分かりました。

残念ながら、肝心の勉強の進捗率があがらないのですけど・・・

でも、一緒に考えたり、勉強することで　今困っていることが少しずつ改善できると

確信しているので（企業規模とか色んな要因で簡単でない所もあるとは思うけど）

今の活動は間違ってないな。と最近よく思います。

何にしろ、ドッペルゲンガー（違）に会えて嬉しかったです(´∀｀*)

これから、がんばろ。

---

ということで現在。

テストオペレーターの育成には興味がなくなりました。

テスターの育成は、遅かれ早かれやるかもしれない。

今やっている仕事の体系化にもあんまり興味はなくなったと思う。

ソフトウェア品質の体系化は理解しとかないといけないことはわかってる。

今はエンジニアやディレクターといかに品質やテストを共存できるか、やっていくかというところに力を入れたい。←ちょっとずつ進んでる気がする

テスト自動化、テストコード、探索的テスト、コードレビューこの辺のキーワードで超高速テストアーキテクトができるとカッコイイナと最近は思っています。

エンジニアとかディレクターとしあわせになりたい（もちろんお客さまに満足できるシステムを提供した上で）

ク◯みたいな仕事

昔プログラマだったのですが、

まぁ割りとク◯プログラマだったと自覚してて

向いてないとずーっと言ってて（実質向いてなかったと思うけど）

そんなク◯プログラマをさらに上回るようなプロジェクトにも

参加してたことがあるわけです。

絶対使えない仕様

やることは、一覧画面にある帳票ボタンを押すと、その一覧の帳票が出力されること。

　ウチは、その帳票ボタンを押した先を作ることになったのだけど、

なぜかDBアクセスからSQLも1回でしなければならない。と言われた。

この業務で300行を超えるSQL文を書けるようになったのだけど

1回の発行では確実に帳票にできないものが出てくる。

なぜか一回にこだわる上司は　GROUP BYすることにした。

そうすると、まとめられないカラムは何らかの条件（Max表示したり）をつけなければならない。

って、それ帳票でやっちゃだめやん。

ていうか、一覧と同じもの表示するはずの前提ひっくり返してるやん。

当時新人だったので、どこからおかしいのかがよく分からず、言われたまま頑張って作ってた。

まぁグルーピングが始まった時点で、ちょっとおかしいのは気付き始めたのだけど、どうおかしいかまでは分からずひとまず完成させるために走った。

途中、同じプロジェクトの同僚が病に倒れ、私も無駄なSQL文を作って超絶メンテナンスできなさそうなものを作ることに成功した。

納品には間に合い、私達はそのプロジェクトから抜けたわけだけど

どうなったんだろうね・・・

今ならどうするかなー。

とりあえず、画面と違うものが帳票で出るんだから、同じものをどうにかして出す方法考えるよね。（なぜあれでよしとなったのか、もめなかったのか謎だけど）

1.画面に出ているものと全く一緒でよかったので、その情報をそのまま引き継げるようにpostで渡してもらう。

　→力技すぎるけど、一番頭使わなくてよさそう。まぁ普通はしないか。

2.そもそもpostが一回というだけの制約なので、SQLが一回しか発行できないことがおかしいから、そのプログラム設計周りを再考する。

　→たぶん使えるモジュールの制約とかがあったはずだけど、理論的にSQLが一回しか発行できないって変。

3.そもそも先方とそんな仕様で合意できたってどうよ？というところを納得したい

　→納得できちゃだめだと思うけど、今の自分だったらどういう話でそんな合意が取れたのかあらためて聞いてみたい（興味本位）