テストする人。

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

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

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

おわりに

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

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

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

ブラウザ上でテスト仕様書を作ってみよう-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なので自分たちで作ればいいじゃん、ということかもしれませんが。。。

  • テストコードへの相互変換が簡単にできるといいなぁ
  • GithubやRedmineへの連携ができないかなぁ
  • 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? ショウジだとどの漢字かわからないからトウカイリンにしているとかそういう話なのかなんなのか。誰かおしえて。

人によって違うモヤモヤってなぁに？～エンジニアとテスターの問診～

ということでポエム。

このあとに、ちょっとTweetしたのだけど　おそらく患者さんと医者に似てるんだと思う。

患者はこの場合、エンジニア。 私は医者。

エンジニアは、何となく不安な部分を抱えてるのだけど上手く言えない。

  • エンジニアAさんは、やたらと膝を気にしてるし でも本当は腰が悪いかもしれないし、膝も腰も悪いのかもしれない。

  • エンジニアBさんは、腰が痛いと最初から言ってくる。 本当に腰だけで健康になった。

  • エンジニアCさんは　よくわからないけど身体がだるいと言ってきた。 やっぱり腰が原因だった。

  • エンジニアDさんはどこもかしこも痛いと言ってくる。 焼けるように痛いって。 でも原因は腰だけ。

そうした場合に、できるだけ「腰」という原因を早く発見してあげたい。 また、本当に腰だけかを適切に効率よく発見できないのかなー。

その不安は、前兆のときもあるのだけど 本人の「不安がり度」にも依存していると思っていて そこを　ある程度あらかじめ安心してもらって できるだけ適切に早く診察ができないのかな。と思った。

というところで、書いていて2つ気づいたこと。

  • こんなときは？　みたいにFAQみたいな何かしらの指標を提示しておくことができれば、事前に本人が自覚できるのかな？
  • テストをする前に事前に問診票を作ればいいのかな？

なんか、とってもそんな気がしてきた。

いいんちょを継続した

はじめに

下書きのままあっためてたエントリー。 公開しようかどうしようかと思っていたけど、来年も実行委員長をやろうと決めたので 公開することにした。

ちなみに、そのまえの　いいんちょの話 いいんちょをやってみた - テストする人。

---

今回もいいんちょをやった。 いよいよ一人で。

どれだけ一人だと（気持ち的な）責任が自分に降りかかってくるか嫌というほどわかった。

まず、大前提としてシンポジウムは みなさまのおかげで盛会だった。。 それは 登壇者や参加者、実行委員とみなさまの協力や応援があってこそ。 自分自身は3年関わってきた中でも一番反省した。

当日は我慢したけど、自宅に帰って泣いた。*1 そのくらい反省することがあった。

自分が長としてやることに関してマイナスなことをエントリすべきか悩んだけど やっぱりそういうのも公開してこその社外活動なんじゃないかと思って、 このエントリをもって、来年度はさらに頑張るために公開してみる。

登壇者にたいして

  • 失礼な態度をとってしまったのではないか
  • 何度も連絡をお伝えしなければならない状態になってしまい、お手を煩わせた

参加者にたいして

  • お金を出していただいていることをちゃんと意識できていたか
  • そのお金にたいしてのおもてなしをスタッフ全員考えてできていたか
  • アンケートは知っている人は優しさ加点をしてくれたのではないか
  • 今日の機会がソフトウェアテストの勉強のキッカケになるかもしれないと考えていたのか
  • これが機会損失になるかもしれないのに

アンケートに関して

  • 基本的に高得点
  • 悪いところはだいたい、自分に関するところ
  • 身内からもらったであろう評価が甘いということは、気を使われているということ
  • 評価は甘くてはいけなくて、高くないといけない

実行委員にたいして

  • 育成ができていたのか
  • ボランティアの中でどこまでをもとめるべきか

登壇したことに関して

  • 何とかなるとおもっていた
  • 委員長しながら、周りが見えてないならやるべきではないのではないか
  • その分のフォローを前もってみえてなかった
  • 結果、すべてにおいて中途半端になったのではないか

今後どうするのか

結局のところ、自分が見よう見まねでやっていたこととか、 今まで何とかできたからと慣れなのかたるみなのかそういうのが 確実に感じてしまったんだと思う。

基本ポリシーは「ベストエフォート！みんなで楽しんで！」だと思ってるので ちゃんとがんばろう。

*1:理由としては、私なんかがこんな活動を引っ張ってやってるのがそもそも間違いなんじゃない？とか私ごときが社外活動なんてすべきだったのか？とか、そういう自己嫌悪