テストする人。

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

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

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

システムの説明

入力画面→確認画面→登録 のいたって普通のシステムです。
今回は、ファイルアップロードがファイル数が固定(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? ショウジだとどの漢字かわからないからトウカイリンにしているとかそういう話なのかなんなのか。誰かおしえて。

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

ということでポエム。

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

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

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

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

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

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

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

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

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

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

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

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

いいんちょを継続した

はじめに

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

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

---

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

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

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

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

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

登壇者にたいして

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

参加者にたいして

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

アンケートに関して

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

実行委員にたいして

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

登壇したことに関して

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

今後どうするのか

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

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

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

非エンジニアの人に伝える「だからシステムを作るのは面白い」と、そこからの「テスターとしてのお仕事」

ランチでのこと。 バックオフィス(という言い方が最近流行っているみたい)の方に「モノづくりをする人は作るのが楽しいッて言うけど、それはどういう気持なの?イメージが沸かなくって」 というような話になった。

仕事として楽しいということ

割りとエンジニアとかって「作るのが楽しい」は基本マインドだったので
目から鱗というか、ハッとした。

会社とか社員が楽しいというより、作ってることが楽しかったりすると思う。
それを非エンジニアとか非ITとか非モノヅクリの人にどのように説明するのがいいのだろうか。

積み木にたとえてみた

即興で考えたにしては、上出来だと自負したのだけど
きっと何かを作るのが楽しいの感覚は
「積み木でお城を作る」
とかに近いのだと思う。

実際は、それを最初に発注するお客さまがいたり
その作り方や積み木を提供することでよろこぶユーザーさまがいたり
納期があったり
色々あるのだけど。

とってもシンプルなことは、こんな感じではないかな。

エンジニアにとっての個々のこだわり

ここで「エンジニアによっても全員楽しみ方って違うよね」という話がでた。

それも同じように積み木で例えてみた。

ある人は、同じ色でつくり上げることを楽しいと感じるかもしれないし
ある人は、少し組み替えることで、新しい形を簡単に作れることを発見するのが楽しいと感じるかもしれない
単に「城」を作るだけが楽しいと思うかもしれないし
いかに速くつくるかが楽しい人もいるかもしれないし
もしかしたら「積み木以外のもの」をあわせることで新しいお城を作るのが楽しい人もいるかもしれない

どう売れるかとか
どうお客さまの要求に応えるか
どうコストをかけないか

これらの視点もはいるけど、もともとの楽しいは上記のような感じなのかなーと想像した。

同じようにテスターの楽しさを考えてみた

それでは、私がテストする上で楽しいこと。

前にワタシ的テスターのお仕事の資料を作った
この辺で発表した資料

www.slideshare.net

今回のものを例にすると、やっぱり同じように例えられるなぁと思った。 (おにぎり試食人じゃ、想像力欠如しそうだし、無理があったのかもしれないw)

基本的には「壊すこと」がお仕事なのかもしれないけど、 どちらかというと、ただ乱暴にぶっ壊すわけではなくて、 同じ色が揃っているのに、違う色にあえて変えてみたらどうなるんだろう?とか
この三角の積み木の部分を四角のに変えてみたらどうなるんだろう?とか
トンネル作ってるから、列車を突っ込んでみたらどうなるんだろう?とか
違う素材のものをさらにあててみたらどうなるんだろう?とか

そういう興味でやっているのかもしれないなぁと。

それで、「ここ、こうやると崩れちゃうよねー」とか話しながら 「じゃ、こうしようよ!」って提案したり話したりするのが楽しいのかもしれない。

そういう意味では、一人遊びよりも
実際に作った人とやるから更に楽しいよね。

と思うのが私がテスターとして楽しいと思うところなのかもしれない。

一緒にお城ができあがる過程が好きなんだと思う。

社内で社外活動の話をしてみた

本来は読書発表をする場で、どうしてもエモい話がしたくなって かなり自己満足度だけは無駄に高い話をしてみた。

www.slideshare.net

あとでアンケート結果が来るのだけど 毎回社内ワーストなので、もう気にしない(本当は泣いてるかもしれないけど)

でも、それなりにいいこと書いてる。 もっとちゃんと書いて説明した方がよかったのとか、重複もしてるけど

社外イベントに参加するだけでも 出来ることはいっぱいあるし 得られることはいっぱいあるし 私、かわれたよ。

というところが、ちょっとだけ伝わったら嬉しいな。

正直、SNSに色々懇親会の食べ物だとかアップしまくって こいつうざいなーとか その後のツアーとかの写真で あいつ何しに行ってんだよーとか

思う人も当然いると思ってて

それはそれで理由があることをちょっとだけ知ってもらえると 嬉しいなーとか思ったのでした(それでもウザいと感じる人はいらっしゃると思うので、そっ閉じしていただければ幸いです)

質問を受けて思ったこと

「やった気になってその場で満足してしまうから勉強会が嫌い」 「そういう『やれた気持ちになって』慣れ合いになってしまうのが嫌」

という話を聞いて、あー、確かに思うところはあったりします。

その時だけで完結しちゃうのは、きっと良くない。 最近は自分の勉強会でKPTA使うようにしているのとかは その辺を改善してもらいたいという思いが強いのかもしれん。

明日から、終わった直後から何かをちょっとだけアクションする、アウトプットする てことが大事なんだろうなー。 継続的に何かを出せるようになる。ことが大事なんだな。

(あー、だから最も手軽なSNS厨なのかもしれない)