テストする人。

ソフトウェアテストってわかんない。ソフトウェアテスタ-による、ゆるゆるブログ。

デブサミ九州に今年もいってきた、そして懇親会LTにちょっとだけでた話

ちょっともう走り書きのようになるけど

event.shoeisha.jp

にいってきました。あと、3年連続自分がやってる勉強会がオフィシャルコミュニティとして参加していました。

といっても、ほんとーにほんとーに仕事が切羽詰まっていて(久々にデータがっつりにらめっこしないと終わらないやつ)
泣く泣く1セッションしか見られなかったのですが・・・

そう思うと、弊社に近いアクロス最高!ありがとうアクロス!

聴いたセッションはこちら(それも遅れてしまっちゃったけど)

http://event.shoeisha.jp/devsumi/20170922/session/1457/

一言でいって、勉強は筋トレ、結果にコミット

知識だけあっても ただのうんちく王だし
筋トレ毎日しないといつまでも自分のものにならないし
ちゃんと結果にコミットするって大事だよね。コミットしなきゃね。

というすごくざっくりした感想と

セミナーだけ受けてわかった気になっても
それを読書会とかやって、勉強してわかったどうか理解して
勉強会とか発表するような場でアウトプットすることにより 自分が理解しているか、またそのフィードバックを受けられるということ

という3つの話が ものすごーーく腹落ちして、来てよかったー!ってなりました。

セッション終了後も会場で何人かお話したり、紹介していただいたり ちょっと聞きたい情報を教えていただいたり
次の勉強会の話をしたりと

会場に1時間居れなかったんですけど、ものすごーく有益な時間がすごせました。

ありがとう!デブサミ
デブサミ最高!ってなりました💛

来年は登壇できるような何かがあるといいなぁ。わたし。

懇親会はオフィシャルコミュニティのLTをさせていただけるとのことで
昨年同様勉強会の告知とシンポジウムの紹介をしました。
若干すべりましたが気にしません。強くなったぞ。

懇親会会場では、拝聴したセッションの登壇者である吉川さんがいらっしゃっていたので
後半がっつり捕まえてw
色々お話聴かせていただきました。おもしろかった💛

特にUX読書会でやってる8分読書はマジ目から鱗で 「もう、川に向かって天才!って叫びたいです!」って言ってました。えぇ言ってましたとも。

8分読書についてはこちらがとても参考になると思います。

nobkz.hatenadiary.jp

これなら、その時間にインターネットとテーマの本さえ手元にあれば 準備いらずでできちゃうやん!天才!すごいすごい!

と、興奮再びですが、とにかく今年もデブサミ九州参加できてよかったです。

ありがとうございました:)
来月以降テストクラスタ8分読書やろー💛

簡易シーケンス図が簡単に描けるjs-sequence-diagramsがかわいくていいかんじ

js-sequence-diagrams by bramp

こんな感じで描けます。かわいい♡ f:id:underscore42rina:20170928194301p:plain

テキストエリアに

Title:login
user -> login : try login
login -> user info : exist User?
user info --> login : 
user info -> roll info : exist Roll?
roll info --> login : 
login --> user : 

で書けばできあがり💛 すてき、かわいい💛

※お題は↓を参考にしました。

qiita.com

ここにあるような実行仕様や複雑な分岐とかは作れなさそうですが、 シンプルなシーケンス図をささっと描きたいときは、テンション高めにかけそうです:)

オッサンを利用しろ と思った話~おっさん寄れば文殊の知恵~

タイトルをキャッチーにしたくてこんなタイトルになっちゃったけど、リスペクトは必要だし、お互いの信頼関係があってこそだと思っています。

わたしたちの会社ではSlackを導入しています。
その中でも、エンジニア中心のchannnelでは技術情報の共有のほかに
普段の開発で困っていることを気軽にきけるchannnelになっています。

手動テスターの私も、このchannnelで何度も助けてもらっています。

以前、迷えるエンジニアが質問をしていました。(私のIssueの修正で詰まったようです)
結果として、ちょっとしたミスが原因だったようですが、その間にも先輩エンジニア(おっさん)が

  • ~ではないか
  • ~にこんなことが載っているぞ
  • XXXでダメなら▲▲かもね

的なアドバイスをしていました(このプロジェクトチームではないメンバーです)

おっさん(といっても同世代のおっさんたち)が数人集まれば、色んな情報が入ってきます。
おっさん集まれば文殊の知恵です。
経験によるアドバイスも(今回あったかはわかんないけど)あるだろうし、引き出しの数と出す速さも全然違うなぁと
見ていて感心してしまいました。

もちろん、何にも考えずになんでもかんでも質問するのは
もうちょっと思考や工夫しなさい
って思うけど (わたしたちの会社では「N分考えてわからなかったら聞きなさい」ということを先輩たちがよく言っています。定量的でよいと思っています)

気楽にきける環境があるし(ここでダメ出しみたいなことはしない・・・と思ってる)
先輩たちも寄り集まれる環境があるのって
いいなぁと思いました。

横で見ているテスターもすっごく勉強になっていて超おすすめですよ!

私のテストとは

ふんわりと書いてしまったので、(・∀・)イイネ!!してくれた方それぞれの想いがあるんだろうなと思っています。
私自身が思っていることを今回エントリしてみようかな。と思います。

エンジニアが作るプロダクトの細部まで意図があるか

意図ってなんだろう

色んな意図があるかなーと思います。たとえば、

  • 各画面タイトルの命名規則が一定であるか
  • タイトルとメニューの関連性に一定の規則があるか

意図って、「これって何でこんな作りにしてるんだっけ?」て質問にエンジニアが答えられるかどうか
「何となくつくりました」ではない答えがあるかどうか かなー

そのためには「なんで」と思う力が私には必要かもしれないし
なんでの答えが明らかなものは聞かないとか
ある程度予測できる疑問まで落とし込めるか(issueになんでなんでじゃエンジニアも困っちゃう)とか

この例の場合、「上のメニューはXXの視点で見ると、この名前がいいと思ってつけた」とか「つい左メニューは上メニューのことを考えずにつけちゃった」とかあると思うので
テストするときに、そのどちらかなんだろうなーと思えるようになることが大事だと思っています。
(もちろん外すときもあるけど)

お客さまに提供できるか

数値目標やメトリクスで一目瞭然なのかもしれませんが

まずは、私が最初の利用者として提供してもいいレベルかどうかを体感しています。
(といっても、私は出荷判断をしていません)

例えば、なんか動き(UIかな)が変って思ったときに、
お客さまが使うなら、どういう動きだったり、配置だったり、色だったり、言葉だと
やりたいことができるかな?と考えます。

考えながら動かすときと、変だなと思ったときに「どうあるべきか」を考えてIssueに書きます。

そこまで最初から設計書にあると悩む時間がもったいないかもしれません(なので、最近は画面レビューもするようにしています)

テストが終わった時点でそのプロダクトのファン1号はきっと私

私は自社が提供するプロダクトの8割前後をテストしています。
分母が難しいけど、新規プロダクトで機能テストが必要なものの場合は
ほぼ私は一度は触っているはず・・・です。

上に書いたように、私が満足するためのことを可能な限り詰め込んだプロダクトができあがっているはずなので
リリースや納品するときに、私はそのプロダクトのファン第一号であることが大半であると思っています。

とはいえ、リリースする頃には他のプロダクトのテストをしているので
エンジニアに私のプロダクト愛があんまり届いてないなぁと前前から思っていました。
私自身も、プロダクト愛あるんだけどなーなんでだっけー?と思っていたので
今回気持ちの整理ができました。

これはQA活動とか品質マネジメントというのか

うーん、わからない

きっと一部ではそうかもしれないし、そうでないかもしれない。

”はじめてのソフトウェアテスト”を3年やってみた

2年ほど前から、この時期にソフトウェアテストの初心者セミナーという
ワークと座学をおこなっています。

www.slideshare.net

2017年 29名
2016年 39名
2015年 27名

とこれまで95名に参加いただいています。
また、このセミナーは、わたしたちの会社の新卒全員(技術部もマーケも全員)と
中途社員にも受けてもらっているので、のべ100名以上に参加いただいています。

なぜやるのか

社内の新人教育をしてほしいとマネージャーから依頼がきたことがきっかけでした。
その時に、わたしがやっているFBグループに相談したところ、色々なアイディアをいただきました。

そこで社内資料を作ったのですが、わたしたちの会社に特化したものではないものが作成できたことと
FBグループで社外のかたから色々知見を得たフィードバックという意味もあって
社外でもセミナーをするようになりました。

(社内は業務時間内にやっていますが、内容は一緒です)

参加者の声

このセミナーでは、一番最後にYWTを使ったふりかえりとセミナーアンケートを実施しています。
社外向けセミナーは、YWT(今回はTだけ)を全員に発表してもらうようにしていますが
とってもいいなーって思っています。

YWTとは

YWTとは、ふりかえりをするためのフレームワークです。

Y(やったこと)
W(わかったこと)
T(次にやること)

を書く、今回のようなセミナーでとても有効なのではないかなーと思って取り入れています。
YWTのTは「次にやること」なんですが、私はTRYしたいこと として書いてもらいました。間違って覚えていたというのもある・・・ごめんなさい

私は、WACATEというテストのワークショップで初めて教えていただきました。

満足度・理解度

5段階評価で今回
 満足度 4.6  理解度 4.7
をいただきました!やったね!わーいわーい:)

参加者のTRY

最後15分くらいで、参加者全員のTRYを発表していただきました。
これだけであと2時間くらい話せる気がしました。
興味深いものをいくつかご紹介します。

本を買いたい。おすすめがあれば教えて欲しい

 以下のブログが参考になるかなと思います。

kyon-mm.hatenablog.com

mhlyc.hatenablog.com

yoshikiito.net

私が最初に買ったのが  - ドリル本 - ソフトウェアテスト293の鉄則 - ソフトウェアテストPRESS総集編

この辺なのですが、293とかは、読んでもなんか当たり前のことが書いてある気がして よくわかりませんでした。

「今しているテストがうまくなる魔法の本」を欲しがったのだろうなと思っています。
「これさえすればバグが出せるテスト実施の本」を欲しがったのかもしれません。

これらのどれも未だに必要な本で、特に293は、今色々言語化したいなーと思っていることが まさに書いてあってびっくりするので、
テストの勉強をして数年だったり、テストマネージャーなどテストを他の人とやっている、教えている人には そうそうそう という内容が書いてあるのでお勧めです。

ドリル本を買おうと思う←数名いました

ちょっとゴリ推ししたところもありますが^^;
やっぱり日本で売っている「テスト技法」だけが凝縮された本なのでおススメしています。

ただ、きっと技法だけが理解できても、業務にうまく適応できなくて挫折するかもしれません。
とお伝えしています。
そうじゃない優秀な方も多いと思いますが、
私は結構使いどころがわからず戸惑いました。

そのときに「使えない」と思うか「使い方を工夫する」「つかいどころが分かった時にさくっと使いだす」ために必要なので 諦めないでください。

あと、使い続けないと忘れるし、下手なままです・・・

JSTQBについて調べようと思う

JSTQBシラバスのPDFは無料ダウンロードできるので、是非おすすめします。
今回シラバスの中から紹介したものも多くありますが、 他社や社外で話をする場合、相手が何の話をしているか、JSTQBを知っていると言葉のずれが減って、会話が楽になります。
「テスト」といっても、さまざまな「テスト」があって、 そのせいで会話がかみ合わないことをできるだけ減らせるといいなー

みたいな話をしました。 また、試験もあるけど、まずはシラバスを読んでみるといいよ!無料だし! とお伝えしています。

みんなも読んでみるといいよ!

社内に今日のことを持ち帰って共有する

さっそく共有してくれるのって嬉しいです!

また、私の場合は”めんどくさい”とか”別に外でも中でもよくない?”て思ったものは どちらにも共有するようにしています。
このブログもそうですし、わかんないのは社内や社外(Twitterが多い)で聴いてしまいます。

自分が楽でプレッシャーにならない方法を模索して欲しいと思います。

もちろん、社外秘じゃないことであれば。

武装して上司と闘う

 個人の好みもあるんだろうけど、「闘う」ってあんまりよくないような気がしています。
 私にはあわないかなぁと。
 わたしたちの仕事は、エンジニアのやったものに対して、ダメだったところや、カイゼンした方がいいところ  エンジニアにとって、つらいところを指摘することが多いお仕事です。

 そのときに、戦うモード(上司はエンジニア側ではないだろうから、この例は変かもしれないけど)なのは、お互いが消耗するんじゃないかなと思います。
 できれば、テストする人もエンジニアも、使うお客さま全員が  しあわせになれる方法を考えたほうがいいなーと思いました。

無駄なテストをしていないか見直そうと思う

 今回「テストケースってこんなに考えないといけないのね」のワークをしたので、「減らす」TRYが出てきたのはびっくりしたしとても嬉しかったです。
 テストはどうしても増える傾向にあると思うので、  減らすためには工夫しないといけないと気付いてもらえたのは本当にうれしいです。  

いつもしているテストケースは何のためにしているか考えてみる

 すでにテストケースが用意されているところだそうで、  「今の自分たちがやっていることが何なのかふりかえる」って気づくの本当にすごいと思いました。
 テストの意図がわかるようになると、もっと工夫するところがでるし  意味のないテストにイライラするかもしれないし  ここから、今回キーワードに出していない「テスト設計」に目覚めるかもしれません。すごいなぁ。
 とってもワクワクしました。

諸事情で社外活動控えていたけど、やっぱり社外の人と触れる機会は必要だなと思った

 数年ぶりに私のテスト勉強会にきてくださった方です。(他にも某研究室の元学生さんが5年ぶりに後輩つれてやってきてくれました)
 それぞれ諸事情もあるし、疲れることもあるので、自分のペースで社外にでるといいよ。とお伝えしました。
 疲れたら外にでない日があってもいいと思う。

 でも社外はやっぱり刺激的だし、できるだけ楽しい気持ちで帰ってもらえるとうれしいので、  私もがんばろうと思いました:)

プレゼンや話し方も勉強になった。がんばろうと思う

 社内でずーっとプレゼン最下位グループにいた私なので、とってもうれしいです!
 やればできるようになるし、  今までみてきた諸先輩方のセッションで、ぐっときたところをどんどん取り入れたり意識して  たくさん伝えられたらいいなぁ。  

3年やってこっそり気づいていたこと

事前に予習をしている人はほぼ0

SNSに慣れていないとかもあるのかもしれませんが、このセミナーの資料は毎年公開しています。
また、申込み画面にアジェンダを記載しているのですが、
「マイヤーズの三角形問題」を予習している人がいませんでした。このセミナーと関係なく知ってる方はもちろんいらっしゃるんですが

マイヤーズの三角形問題

と記載しているけど、事前に中々調べないもんだなーと思っています。もちろん調べてくる必要はないようにワークをしています。
調べてくるときっと面白くないかも

セミナーを広く浅くするか、もっと掘り下げるか

毎年「もっと深く教えて欲しかった」や「最後が駆け足だった」というような声をいただきます。
今回の目標は「さまざまなキーワードや用語がある、テストの存在を知ってもらいたい」ということがあって さらっとお伝えするようにしています。

1つ1つ本当に勉強しようとすると、それだけで1テーマになると思うので難しいのですが 来年またちょっと工夫できたらいいかもしれないなぁと思います。

このセミナーを3年やってきて

自分がテストの勉強している内容を、少しだけ体系的に、
自分が外に出るようになって「テスト楽しい」をセミナーで体験して欲しい
自分が色々シンポジウムとかに参加して得た「楽しさ」「発表スタイル」を感じて欲しい
せっかくなので社内だけじゃなくて、社外にも伝えたい

色々想いはあるんですが(書いてて気づいた)
うまく伝えられるようになってきたみたいです。
(それでも初年度の「感動しました」は、いただけてないので、エモさが減ってきたのかもしれない。
 でも、誤解のないような説明はずいぶんうまくなってきたんじゃないかなぁ)

このセミナーではいきなり武器を渡すことはできなくて(カタログを見せてるのに近いのかな)
テストって楽しいのかもしれない
自分たちも何かできるようになるかもしれない
テストも勉強することがあるのか

とかをちょっとだけ、本当にはじめの一歩を踏み出せてもらえるといいなーと思っています。

また、悩みを聞いて「これはこう」「これはそうじゃない?」とか
本を読んでつまづく気持ちとか
この数年で色んな人と色んな話や経験をしたことが活かせていると思いました。

わたしは今のところ「ソルジャー」「エキスパート」みたいなところにはいなくて
多くの人にテストの子とを知ってもらったり
そこから活躍する人たちを発掘したりするのが楽しいみたいなのと

凡人だからこそ、伝えられることとか、わかりあえることがあると思うので
これからも続けたいなぁと思います。

今年もPHPカンファレンス福岡でお話してきたよ(1年ぶり2回目)

昨年に引き続き、今年もPHPカンファレンス福岡2017でお話してきました。

昨年の↓ underscore42rina.hatenablog.com

さて、私は非エンジニアなので、2年も連続して採択してもらって本当にありがたいと思いました。
ありがとうございます!

昨年は「日本で一番PHPのテストしている」と豪語したわけですが
「(開発部署で一人でテスト専門にやっている手動のテスターの中で)日本一PHPのシステムのテストをしている人」だと思っていたのですが、
昨年部署構成が変わって、開発部門じゃなくなったので、全然日本一じゃなくなりました。たぶん。
去年話せてよかった。

今年はさらにテストの話もせずに、日本語の話(バリデーションメッセージの話)をしました。 エンジニアさんがささっと設定しちゃうのかなーって 思う背景とか
そういうメッセージ だと、ユーザーはどう思うのかなとか
なぜだめなの?とか
じゃー、どうすればいいのかなとか。

今回のセッションは、本当に当たり前の人は当たり前すぎる話だったので
こんな当たり前なことを15分も使ってメインホールで話して大丈夫なのか
超不安でしたが
ちょっとだけ「そうなんだよね」とか「明日からちょっと気にしてみよう」

って気になってもらえたら大成功だと思います。

そんなこんなで、今年のスライドがこちらです↓

www.slideshare.net

※今年はYoutubeの動画配信もOKにしちゃったので、あとで追加します:)
※追記しました↓(2017/07/24)

www.youtube.com

登壇後にAsk the Speakerや懇親会で
「発表を聴きました」
って何人かの方に言っていただけました。

「おすすめされて、メインに聴きにきました!」って方もいてくださって嬉しかったです。

ありがとうございます!

「日本語大事ですよね」

って言っていただけて、うれしいです。

機会を作ってくださった、実行委員のみなさま、聴講していただいた参加者のみなさま
応援してくださったいつものみなさま どうもありがとうございました。

今年も参加できてよかった:D

バグの原因を教えてもらうとき、もらわないとき

2年ほど前に社内用に書いたエントリーだけど、いいこと書いてたので一部修正して公開します。

はじめに

もともと私自身の頭の整理をするためにこのエントリーを書きました。

初めて私とテストされる方や新人のエンジニアは特に読んでいただけると嬉しいです。

私と仕事をしたことがあるエンジニアのみなさま、バグ票(チケットやIssue)のやりとりをしていて「何かやたらこのチケットにリナさん食い下がってくるなー、こだわってるなー」と思うことがあるはずです。

チケットについて突っ込まないとき

普段、チケットを起票するときには原因が何となく予想できていることが多いです。

例
 表記ゆれ
 データベース登録時のエラー
 JavaScriptのエラー
 変数の型間違い
などなど

ある程度のパターンがわかっている場合は、「なおしました」と書いてもらうか、あるいは書かなくても修正していただいてチケットを確認します。

チケットに突っ込むとき

時々、全く予想つかないバグが出ることがあります。

その場合はある程度腑に落ちる説明をお願いしています。 理由は、

  • 二次被害を抑えるため(今起こっている内容を回避する方法はわかるけど、原因を正しく理解していないと、根 本的なバグを残したままということがあります。
  • 他の案件のテストでも、同様のことが起こった場合に過去の経験からバグの解決ができたり、誰に聞けば解決できるか思い出したりできますのでとても重要です。

例:

■バグの現象:
 登録画面で誤った入力をした場合にバリデーションメッセージが表示されず、404エラーの画面が表示された。


■バグの原因:
・バリデーションは入っていたが、バリデーションに引っかかっていたときの画面遷移先が間違っていた。
・バリデーションメッセージが表示されなかった。

このように、1つの現象に2つバグが含まれる場合、2つとも修正されずに手前の修正(この場合、バリデーションメッセージを表示する)だけされることがあります。

わたしの場合、

  1. 登録ができていない
  2. その後の挙動がおかしい

の両方が納得できたときにはじめてチケットをCloseするようにしています。

バグの原因が報告時点で二つとも指摘できればよいですが、現象だけで判明(または予測)できないことも多いです。
ですので、「気持ち悪い」「変な動き」と思った部分が説明を受けて納得できると、Closeすることができます。

うちのエンジニアも良いこと言ってた

バグって1個出てきたらそれを修正して終わりではなくて、必ず同じようなバグがないかを確認する必要があります。これはエンジニア側も常に意識しておいてほしい。
で、「こういう原因でバグでした」という情報があると、同じような箇所を確認できたり、「こういう修正をしました」という情報があれば、その修正ならばこのケースは考慮できてるかな?とか確認できるので、どう修正したかを伝えるのは大事です。

おわりに

つらつらと書いていますが、単に私のこだわりだったり我儘だったりわかってないだけ、ということも多々あると思います。

バグ票は私(テスター)とエンジニアの活動を幸せにするためのコミュニケーションツールだと思っております。

思い込みの部分もあると思いますので、優しいツッコミお待ちしております。