テストする人。

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

Developers Summit 2016で爆発的に面白いセッションを作る方法

Developers Summit 2016 FUKUOKA #devsumi

という、憧れのイベントがありました。 通称デブサミですね。

そこでリレーセッションというものをしてきました。3人でやったのですがその結果こちら！

すごいでしょ！(なんかタネばらされてるけど）

今回の発表資料

www.slideshare.net

タネあかし

セッションの最後の方で以下の説明をしました。

  1. 「えー、Twitterアカウントをお持ちの方はスマホをあけてください」
  2. 「画面にハッシュタグがありますので、こちらを入力してください」
  3. 「さいごに、『このセッション、楽しい』と呟いていただけると、このセッションは成功になります」

うん。やらせです。

効果

  • やらせではあるにしろ、タグ内が爆発的にプラスの言葉で埋まる
  • きっとやってる方も楽しんでるはず。
  • 小さなアウトプットの一つとして双方がハッピーになる体験ができるんじゃないかな

このスライドの誕生秘話もあるけど、また別のストーリーとしてエントリできるといいな。

はじめて（とくに新卒）に指摘するときに気をつけていること（BTSの記入について）

去年社内向けに書いた記事が、なかなか良いこと書いていたのでブログにあげます。

わたしたちの会社は、中途／新卒に限らずエンジニアは最初にOJTの一貫として何らかのシステムを作ります。 そして必ずわたしがテストを担当するという決まりがあります。

昨年から、外国に住んでいた外国籍の新卒（つまり生まれも育ちも外国の外国人。会社は日本語のみ）を採用するようになりました。 昨年は2人の外国人の新卒＋日本人の新卒2人の4人のエンジニアがいて、 そのうち3人のテスト時期がかぶっていました。

いろいろ初めての経験もあったので 主にBTS(Redmine）に記載するときに気を付けた点をまとめておきます。

元ネタを記載

連携先システムのバリデーション規則を実際に連携先システムで確かめてみるとか

日本の文化や経緯を書く、調べる

  • 在職と在籍の違いとか
  • 姓名、氏名の違いとか

どういう意図で書いているか書く

メッセージの変更では、現在のメッセージと私が提案するメッセージを記載し、そのメッセージにした意図の説明を書く

現在：ファイルのサイズが2MB未満でなければなりません
提案：1ファイルサイズは10MB以下にしてください
■説明
    2MB→10MBの間違い？
    「未満」→「以下」？ボタンは以下になっていて、メッセージは未満になっています
    　どちらかに合わせてください。（プログラムコードも確認してくださいね）
    ユーザーが次にアクションしやすい表現にしてください
    　「～でなければならない」ではなく「～してください」になるメッセージを考える

説明までは通常書くことが少ない（か、書いてもちょっとだけ）のですが、何でこんなことを書いているかの理由がわからないと「あがったチケットに反応するだけ」になってしまうのは良くないと思い、出来る限り説明を入れるようにしました。

感想

　新人OJTは全員個性もあり、こちらがあらためて勉強不足だと気づいたこともあり、システムを作る上で相談することもありとても楽しかったです。

　中途のOJTとも違いがあったり、今年は今年で違いがあるのでそういうのもまとめてみると楽しいかも。

英語の勉強をする時間のない人はSlackで技術と英語を勉強するといいと思うよーtestes.ioのススメー

英語の勉強しなきゃ 　と言い続けて○年・・・　未だに手付かずの状態です。

「だって技術の勉強もしなきゃいけないし」 　えぇ、そういう言い訳ばかりしています。

両方やってしまえばいいじゃん

ということで、とあるSlackのTeamに入りました。

Software Testing Community Chat

テスターのためのSlack Teamです。
http://www.testers.io/

参加されている人の国籍はわからないのですが、会話は英語、 #eventsのchannelを見る感じだとアメリカのものが多いようです。

メリット

興味のあるジャンルのchannelがある

ExploratoryTesting（探索的テスト）は私がずっと気にしているテーマで、日本でも研究会に入っています。
こちらのchannelでは具体的な「こういうときどうしてる？」という話が見れるので、かなり勉強になります。

こういうカジュアルさがあるのはSlackのいいところですよね。

話し言葉＋技術要素なので意外と単語は読めちゃう

ここが一番のポイントなんですが、英語偏差値が絶望的に低い私でも、なーーーーんとなく読めてしまいます。
すごい、技術の話すごい、話しことばすごい！

今やっている流れ

  1. 何も見ずに意訳（「探索的テストのログってどうやってるー？」的に意訳も話し言葉で妄想）

  2. 翻訳機にかけてみる 　技術的な単語は翻訳せずに分かるものも多いので、会話の流れがあってるか確認してみる

  3. 誰かに聞いてみる 　英語の分かる人に「この意訳であってる？」って聞いてみます。　よく間違ってますｗ

デメリット

デメリットというほどのものはないかもしれません。

これだけではTOEICには役立たないかもしれませんね。

おわりに

英語を日常に取り入れる環境づくりって大事だな。と思いました。一挙両得しちゃうぞ♡

日本語に自信がない非エンジニアはtextlintのChrome拡張を入れるといいと思う

昨日TL見ててtextlintの話題があったのだけど、私のブログ出てこないなぁ(´・ω・｀)ｼｮﾎﾞｰﾝ
と思っていたら、そもそもブログにあげてなかった(´・ω・｀)ｼｮﾎﾞｰﾝ

社内展開してただけでした。
ということで、ブログ展開。

textlintにはChrome拡張がありました。

記事

http://io-monad.hatenablog.com/entry/2016/03/14/225800

ブログ掲載前の日本語のチェックができますので、是非入れてみるとよいと思います。

導入の仕方

前提

入れ方

１. Chrome ウェブストアにアクセス↓

https://chrome.google.com/webstore/detail/textlint-proofreader/hdongmdneapmhfblomidbafplpanpdmm?hl=ja&gl=JP

２. 追加します

f:id:underscore42rina:20160615103309p:plain

使い方

１. テキストエリアのある画面を表示します ２. 文章を入力しましょう。
３. Chrome拡張で追加されたボタンをクリックします。
f:id:underscore42rina:20160615105918p:plain ４. オプションを確認して「文章のチェックを開始」をクリック

５.　日本語チェック結果を表示してくれます。
f:id:underscore42rina:20160615105751p:plain

RedmineのBTS管理からGithub／GitlabのITS管理へ乗り換えた理由と効果

最近バグの報告に、Redmineだけではなく、Github/GitlabのIssueで報告したり、ヌーラボ社のBacklogを使って報告することも増えてきました。

使うにあたっての背景

  • チケットによるメトリクスはとっていない

どうして乗り換えたか

エンジニアが楽なのがいいから

この一点につきます。
開発する上で、ツールが複数あるよりも少ない方が楽なはずです。
社内テストの確認のためだけにRedmineを開かなければならないのは（Slack連携で楽になってきたにしろ）あまりうれしいことではないな。と思いました。

また私の方では、記載する時は以下の項目が殆どなので、GithubでもBacklogでも問題はありませんでした。

メリット

  • お客さまも読まれることで「ここまでテスト確認してもらえるのですね」と褒めてもらえた！
    エンジニアが楽になるように。ということでお客さまも見える場所と意識していなかった（もちろん見られてもよい表現、データ、内容を書くようにしています）ので、こんな相乗効果があるのかーと目からうろこでした。 　私は普段お客さまと接する機会がないのですが、こういった形で弊社がシステムをリリースする前に「不具合を報告する」だけではなく「リリース前により使いやすくするにはどう改善した方がよいか」をテスターから提案している流れを公開するのっていいな。と思いました。
    　私が書くことでお客さま自身も「こういう視点で見ると受け入れテストもやりやすいな」とか「こういう書き方をすれば、もっと伝わりやすくなるのね」といったヒントやお手伝いがも今後できるといいなぁと思っています。
    　なにより、私からお客さまに届けるものが今まで直接的になかったので、とても嬉しかったです。

  • 社内テストも公開することで、お客さまにより明確な開発ができるのかもしれないと思いました。

  • エンジニアは少しは楽になったのだろうか？←誰かおしえてください とかいてたら、エンジニアが教えてくれました（ありがとうございます♡）

    バグとコードが一緒に管理（紐づけ）されているので非常に管理しやすいです。 今まではRedmineみて、Gitみての行ったり来たりだったので、それが無くなったことで楽になったと感じてます。

Github/Gitlab

  • 変更したプログラムコードが追えるはず
  • Margeしたかどうかはっきりするので、マージ漏れなのかデプロイしていないのかエンジニアに聞かなくてもわかるように（今後）なる予定！がんばれ、私！

デメリット

  • 画像以外のファイルが添付できないと困ることがあるかも。
  • お客さまの目に触れる環境で書くので、相応の表現を気をつける必要がある（案件によっては問題になるかもしれないですね）
  • 案件によってどれに何を書いたか最近よくわからなくなってきた
  • チケットのメトリクスをとっているところがあるならば、複数にわかれるのはよくないかもね。。
  • 当然ながら、セキュリティ対策はしっかりと！テスト環境やテストデータには最善の注意を！

おわりに

１年くらい前にバグやチケットをBTS管理しているところとITS管理することにどういった効果や違いがあるのだろう？と疑問に思っていました。
自分がちょっと「やってみる」と言うと、すぐチャレンジさせてくれるプロジェクトにいられるのはいいなぁと思いました（なので、フィードバックもできるだけしたいと思う）

・・・となると次はJIRAではないか・・・という話になるのかもしれないけど、それはまた未来の話。。

PHPカンファレンス福岡2016でお話してきたよ

PHPカンファレンス福岡2016というのに参加しました。

だいぶ全力で釣りに行ったタイトルのお話をしましたよ。

www.slideshare.net

PHPの話もできないし、そもそもコード書けない（読めなくはないけど）私が あんなすごい所で登壇していいのかなと。 採択してくれた実行委員や聴きにきてくださる参加者の期待にこたえられるか不安すぎました。

テストの勉強をはじめて３～４年になって、やっと少しずつ自分がしていることやエンジニアとしたいことが 人に話せるようになったかなと実感できました。

きっと私たちがやっていることは、エンジニアにとってもテスターにとってもしあわせになれることで それをもっと多くの人に気付いてもらえると嬉しいです。

なんで応募したか

  • 去年エンジニアのみなさまが盛り上がっているのを指くわえてタイムラインみてるだけだったから
  • 行ってみたかったから。
  • ただ「参加したい」だと何で？てなるけど「話すから」だと参加できるから←だんだん卑しい理由になってくる

登壇してよかったこと

  • テスト大変なだけじゃないよ、テスト楽しいよが伝えられたかなー
  • 懇親会とかで「テストの話しにきました」って声をかけていただいたこと
  • 県内外のエンジニアの方々と新しくお友だちになれたのはうれしかったな

参加してよかったこと（参加者として）

  • ViewをAPIでもっと（エンジニアも私も）幸せになれるかもしれない。という技術が学べたこと
  • 弊社のセッションをみて、知らなかったこととか、あれ？これ私もコードレビュー入った方が良いんじゃない？て気付きが結構あった
  • 弊社技術者とそこそこ上手くやれていると信じているけど、まだまだやれるチャレンジがあることに気付いたこと
  • 運営視点で見えてくるものがたくさんあった。すごいなー。

もっとがんばっとけば

  • 有名人情報をもっと調べ上げとけばよかったなぁ（人見知り発揮）
  • 次は「テスト楽しい」から「テスト勉強したい」につなげられたら嬉しいなぁ

今回知った一番の衝撃

（弊社にValidationに特化したプラグインがあると知ったつぶやきより）

最後に

PHPカンファレンスなのに発表資料にコードの1行も表示できない私に登壇の機会を与えてくださった実行委員のみなさま、ありがとうございました。 運営も大変だったと思います。すごい一日を過ごせて本当によかったです。 私も登壇者としてカンファレンスを盛り上げるお手伝いが少しだけできたのならとても嬉しいです。

わたしはどうやってバグを出しているか～報告までの思考の流れを実例を使って書いてみる～

事例 ソフトウェアテスト テスター

テストをしていて、どうやって報告するバグを見つけているかの流れを書いてみます。

システムの説明

入力画面→確認画面→登録　のいたって普通のシステムです。
今回は、ファイルアップロードがファイル数が固定(N個とします)で出来るようになっていました。

今回みつけたバグ

  • 確認画面で、すべて「ファイル１」の名称が表示されている。
  • この画面から入力画面に戻った場合、それ以外のファイルも「ファイル１」のファイル名が表示された。

バグをみつけるまでの流れ

ここから心の声の実況も混じえます。

手順1.確認画面でファイル名が全て同じ名称になっていることをみつける

違うファイルをN個登録しようとしたのに１番目のファイルをN個登録しそうになってる バグだろうと予測しました。

心の声：「あー、きっと変数みたいな何かを全部同じの使っちゃってるんだろうなー」

手順2.本当に登録されるかやってみる

登録してみたら　登録はうまくいってしまった（全ファイル違うものが登録できてる）

心の声：「確認画面を表示するところの設定が違うんか」

手順3.もう一度確認画面まで表示して、戻るを押してみる

すべて、ファイル１のファイルが入力フォームに表示されてしまった。

割りと珍しいパターンかもしれない

同じような場合、手順1に書いた登録系のバグである可能性が経験上高かったりします。
（確認画面でファイル１を表示するときに、登録も同じようにファイル１で登録しちゃうことが多いだろうと予測しています）

また、このままチケットを起票して、実は登録はされずに表示だけのバグであることもあります。
→今回のように動かしてわかるものであれば、こちらで拾えるのですが、場合によっては修正してもらったら　報告内容と違うこともよくあります。

おわりに

見つけた時点では「登録される」バグだと思っていましたが、実際に確認すると「登録ではなく表示が問題」のバグでした。

報告するまでに、できるだけ的確なバグ報告ができると、修正してもらうエンジニアも時間が短縮できます。
また、テスターも再テストが楽になったり、再テスト時に新しく試してみたいテストが増えることもありますし、何を増やした方が良いか考えやすくなります。

できているエンジニア（テスターとして参加する場合）には当たり前の思考かもしれませんが、一度思考の整理をすると　ほかの人にも共有しやすくなると思います。