読者です 読者をやめる 読者になる 読者になる

テストする人。

ソフトウェアテストってわかんない。ソフトウェアテスタによる、ゆるゆるブログ。だいたいエロいことを書きます(嘘

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

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

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

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

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

Software Testing Community Chat

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

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

メリット

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

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

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

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

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

今やっている流れ

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

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

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

デメリット

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

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

おわりに

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

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

昨日TL見ててtextlintの話題があったのだけど、私のブログ出てこないなぁ(´・ω・`)ショボーン
と思っていたら、そもそもブログにあげてなかった(´・ω・`)ショボーン

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

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

記事

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

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

導入の仕方

前提

入れ方

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

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

2. 追加します

f:id:underscore42rina:20160615103309p:plain

使い方

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

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

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

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

使うにあたっての背景

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

どうして乗り換えたか

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

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

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

メリット

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

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

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

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

Github/Gitlab

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

デメリット

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

おわりに

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

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

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

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

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

www.slideshare.net

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

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

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

なんで応募したか

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

登壇してよかったこと

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

参加してよかったこと(参加者として)

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

もっとがんばっとけば

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

今回知った一番の衝撃

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

最後に

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

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

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

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

システムの説明

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

今回みつけたバグ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

おわりに

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

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

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

ブラウザ上でテスト仕様書を作ってみよう-Chibineko操作レポート-

テスト会社のSHIFT社が作っている'Chibineko'というサービスがOSS化されました。
さっそくエンジニアに私のMBPに入れていただきましたので操作レポートです。

Chibinekoってなぁに?

タイトルのとおり、テスト仕様書をブラウザ上で作って管理するシステムです。
 第三者検証会社のテスト仕様書(テスト操作手順書)にしては物足りないと思いますが、私が普段作成しているようなテストチャーターに近いテスト仕様書や、ミニマムなテスト、ざっくりしたテストチェックリストを作りたい人にはお手軽でよいです。

 昨年無料サービスとしてオープンしていましたが、テスト仕様書を外のサービスに登録するのを躊躇っていたのでOSS化は非常に嬉しいです。

できること

テストケースをマークダウンで書くことができる

大きな特徴の1つ。テストケースをマークダウン方式で書くことができます。 f:id:underscore42rina:20160406130220p:plain

ワンクリックでテスト結果を登録できるUI

ここも大きな特徴です。テストのOK/NGがいたってシンプルに作られています。 f:id:underscore42rina:20160406130303p:plain

チームが作れる

チームを作ることができます。

進捗管理がみやすい

フッターのインジケーターのような表示とヘッダーの数での表示で進捗状況がすぐにわかります。 f:id:underscore42rina:20160406130351p:plain

テストのコピーや出力も簡単

CSV出力機能やテストの複製メニューが用意してありますので、簡単に操作できます。
マークダウンなので、そもそも作りなおしてもコピーは簡単にできると思います。 f:id:underscore42rina:20160406130325p:plain

プロジェクトが作れる

チーム内でのプロジェクトを作ることも可能です。

使えそうなシーン

  • ちょっとした自己チェックに
  • かなりシンプルな人力テストなど複数テスターで同時にテストをしたい時

難しそうなところやデメリット

事前条件が多いようなテストケースの場合、読んでもわかりにくい。書き方を工夫しないと。

再テストをした日などがわからない。(知る必要ないかもしれない、メモで何とか工夫する)

今後期待していること

OSSなので自分たちで作ればいいじゃん、ということかもしれませんが。。。

  • テストコードへの相互変換が簡単にできるといいなぁ
  • GithubRedmineへの連携ができないかなぁ
  • SlackにWebhookかけられたらいいなぁ

テストデータを簡単に出そう!-BugMagnet使用レポート-

ということなので、使用レポートを書いてみます。

BugMagnetって何?!

詳しくはこちら↓

ざっくり言うと、テストデータを出してくれるChromeのExtentionとFirefoxのアドオンです。

Webシステムのテストの時に使えます。Chrome拡張機能(Extention)とFirefoxのアドオンで用意されていました。 今回はどちらも入れてみました。

インストール

Firefoxの場合

  1. [ツール]-[アドオンの追加] f:id:underscore42rina:20160401174236p:plain

2.[bugmagnet]で検索します f:id:underscore42rina:20160401174420p:plain

  1. 「bugmagnet」が表示されたら[インストール」をクリックすればOKです

Chromeの場合

gojko.github.io 1. コチラのサイトから[Add to Chrome]をクリックすればOKです f:id:underscore42rina:20160401174552p:plain

使い方

f:id:underscore42rina:20160401175204p:plain

  1. テストしたい入力フィールドで右クリックします。
  2. [Bug Magnet]を選択します。
  3. テストデータを選択します。
  4. 入力フィールドにデータが入ります。

いたってシンプル。

境界値もあるよ

f:id:underscore42rina:20160401175545p:plain [Number]を選べばIntegerとかの境界値、あるあるな数字がでてきます。

クレジットもちゃんと使えるテストNoがでてくるよ

f:id:underscore42rina:20160401175705p:plain [Credit Cards]を選べば、登録できるテストデータが用意されているようです。

日本語対応はまだ

f:id:underscore42rina:20160401175920p:plain

[Names]だけ日本人名もありましたが、[Addresses]や[Phones]には対応されていませんでした。

でも大丈夫!GitHubで公開されていますよ!

github.com

ないならプルリクすればいいじゃない。 ということで、日本語は私達がどんどんプルリクしてしまえばよいのではないかと思います。

https://github.com/gojko/bugmagnet/blob/c29e3bede5fa55bb5827ba8f9922498b09c62112/template/common/config.json

この辺に各設定値が書いてありました。

"Other charsets": {
            "Japanese": "田中太郎",
            "Japanese Tōkairin": "東海林賢蔵",
            "Ze Dong": "泽东",
            "Russian male": "Борис Николаевич Ельцин",
            "Russian female": "Наина Иосифовна Ельцина",
            "Thai nickname": "แม",
            "Arabic": "ابن خلدون"
        }

データの選定基準がなぞ。なぜショウジさんをトウカイリンとしているのか謎。*1

感想

  • とりあえず何のデータ入れたらよいかわからない、それっぽいデータをいれたい人には有効だと思います。
  • エンジニアにも勧めたいです。デバッグの時に楽だと思う。
  • 探索的テストのツールとして作られたもののようですが、スピードが遅くなりそうな・・・(ノッてる時なら操作性が悪いかもと思いました。)
  • 日本語が今のところ弱い(けど、公開されているので自分たちで追加しちゃえば問題なし!)
  • データそのものの選定の意図がよくわからないので、各自で考える必要があるかも(一般的なデータとして深い意味はないデータも多そうです)

*1:と思ってたら、東海林賢蔵ネタのスライドを見つけた→Whats My Name? ショウジだとどの漢字かわからないからトウカイリンにしているとかそういう話なのかなんなのか。誰かおしえて。