テストする人。

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

私のテストとは

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

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

意図ってなんだろう

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

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

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

そのためには「なんで」と思う力が私には必要かもしれないし
なんでの答えが明らかなものは聞かないとか
ある程度予測できる疑問まで落とし込めるか(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とかは、読んでもなんか当たり前のことが書いてある気がして
よくわかりませんでした。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

武装して上司と闘う

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

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

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

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

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

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

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

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

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

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

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

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

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

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

マイヤーズの三角形問題

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

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

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

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

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

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

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

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

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

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

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

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

2023.03 追記

3年前に現在の所属企業でも同じワークショップをしたときに. 英語版のスライドを作成してもらいました。

Speaker Deckの方が使いやすいと思うので、日本語版もあげなおします。

Speaker Deck日本語版はこちら

speakerdeck.com

Speker Deck English version here.

speakerdeck.com

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

おわりに

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

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

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

アクセスが激減した

underscore42rina.hatenablog.com

から数週間経過。

見事にアクセスが減ってしまった。

Excelってやっぱり人気なんですね。

f:id:underscore42rina:20170328164029p:plain

テストでもアクセス伸びるようにがんばろー(あんまりテストの技みたいなの書かないので、それはそれで微妙だけど)

日本縦断オンライン勉強会(とサドンデス飲み会)を仲間とやってみたよ。の話。

先日した読書発表の話を聞きたいって東北の仲間に言われて、
もう一人の東北の仲間と3人でかるーくやってみよかー
って話になったのです。

当日になって、声かけなくてよかったのか?という話になったので、
まー、タイムライン覗いて興味ある人いたらいんじゃない?
ということで、冒頭のtweetになったのでした。

そうすると、わらわらと仲間が集まり
22時には北海道から福岡まで7名の仲間が
お酒を持って集合

結果として、22:00~02:30までの長丁場の勉強会(ほとんど飲み会)になりました。

楽しかったです♡

運営とか感想とか

中身のある話はおそらく @ToshiManaPlus1 がブログ書いてくるはずなので

構成

  • 22:00~22:15 セッティングとか
  • 22:15~23:00 @rina 発表
  • 23:00~23:30すぎ? @ToshiManaPlus1 発表
  • 23:00~02:30 フリータイム

環境

  • Googleハングアウト
  • Sway(私の発表資料)

全員Googleハングアウトに接続。音声必須、カメラ・マイクは任意としました。
カメラは2名、マイクは適宜必要なときに。
どちらも使えない人はコメント欄に書き込むことで参加しました。

やっぱり女性はカメラなしだと嬉しいです。

よかったこと

  • 殆どが知り合い(私は全員タメ口で話せるくらい友だち)同士だったこと
  • 人数は7~8人くらいまでがよさそう。それ以上いると、話せない・意思を伝えづらいような気がする
  • 当日セッティングでも何となく全員が使えた
  • Googleハングアウト使うと、画面共有がしやすい。切り替えが楽
  • 全員オンラインだとストレスが少ないと思う(一部オフラインだと置いてけぼりとかがあるときもあるので)
  • 社内向け発表資料だったけど、そのままオンラインでも使えるものだったのはうれしい♡*1
  • むしろ早押し的なところを、全員に入力で答えてもらうのは、参加ハードルさがって出してて楽しかった

思った以上に普通に勉強会としても成立できたし、
オンライン飲み会としても楽しかったです。

勉強会は、参加者の入力が可能だったり、発表者の資料を自分の手元で確認できるので、
内容によってはオフラインより向いてる可能性もあるなぁと思います。

飲み会は以前もやったことがあるけど、ハングアウトを使うことで、超どうでもいい黒歴史を暴露するのに
キャッキャできました。
SNSでもできるんだけど、クローズドだからこそってものもあるなぁ。

カイゼンしたいこと

  • Googleハングアウトになれていないからか、画面共有中に他のマイクが入ると、画像が切り替わってしまい、確認しづらいときがあった
  • フリータイムのサドンデス方式はつらい人にはつらい。勉強会のターン、中締めを入れると幸せになれるかも
  • 自分の発表も間延びしたところもあるかなーと思うので、時間はやっぱり気にしたほうがいいよね。

ハングアウト素晴らしいと言いたいところだけど、もうちょっと使いこなす必要があるかも。
他にも画面共有とかはサービスあるので、他のサービスを使ってみるのもいいかもね。って話になっています。

そして、時間については最近とくに私の課題になっているところだったので、
ちょっとちゃんと対策とろうと思います。

オンラインでしあわせだったこと

  • 北海道・東北・関東・九州勢が集まれたってすごい!
  • 終電を気にしなくていい(次の日のことはちょっとだけ気にします)
  • 深夜の飲み会のぶっちゃけぶりとか、ものすごくどうでもいい話とか楽しいよね
  • 子どもを寝せてから参加できるのは家族にも優しい
  • お好みの酒持ち込み可能♡
  • 終了10秒でベッドにダイブできるのは本当にしあわせ

やっぱり、なんだかんだで遠くの仲間たちと自由に集まれるのはしあわせです。
もっとみんなオンラインやればいいのにー)

これからオンライン増えてくるかもね:)

*1:興味があれば再演可能です

アクセスが伸びてきたけど、意図しないことだったので弄ってみている

f:id:underscore42rina:20170328164029p:plain

ブログを続けて4年くらいになる。平日であれば一日のアクセスが100件を超えることも増えてきた。

大変ありがたい。

しかし、大半がその4年ほどまえにエントリーした「条件付き書式」について書いた記事へのアクセスだった。
悲しい。

ちょっと天狗になりかけていたのを反省するために
そのエントリーを非表示にしてみた。

すると、どうだろう。

見事に一日のアクセスが半分以下になった。
それでもトップアクセスエントリーは404になった「条件付き書式」のエントリーだ。

恐るべしExcel
恐るべし条件付き書式。

Google検索でもテストとか社外活動とかでアクセスしてもらえるように
精進しようと思う。

【追記】

f:id:underscore42rina:20170328164029p:plain

順調にアクセスが減っている