テストする人。

ソフトウェアテストってわかんない。ソフトウェアテスタ-による、ゆるゆるブログ。

モブテスト(mob testing)をやってみたよ。その2

underscore42rina.hatenablog.com

2週連続ですが、今週のテストランチでもモブテストをやってみました。
(モブテストってなぁに?て方は、前回のエントリーを見てくださいね)

今回の参加者

前回より増えて12名くらい? 今回はテスト対象を作っているエンジニアや
ディレクターも参加してくださいました:)やったね!

テスト対象

先週とは別の自社で作っているサービスの1画面をテスト対象としました

やってみたふりかえり

成果

Issueが7件(うち、バグが2件とか?)でした。やっぱり効果はあるようです

よかったこと

1回目のふりかえりで「2回目はさらにテスト対象を絞ろう。画面ではなく1項目についてテストしよう」という案が出て採用しました。
テストスコープを狭くすることで、4分をぐっとバグを出すことに注力できたんじゃないかと思います。

また、最近自社に入ってきた非エンジニア(でもエンジニア出身かな)の方も参加くださったのですが
終わったあとに前職の心配をしてしまう程度にテストに対する意識を肌で感じていただけたっぽいです。よかった♡

うまくいかなかったこと / カイゼンしたいところ

  • テスト対象が基本的なことだったこともあり、新しい知見が前回ほどなかったかもしれない

 人にはよるけど、既知の内容が前回より多かったような気がしました。
それでも、非エンジニアのメンバーには復習になってよかったかもしれません。

  • ナビゲーターが多すぎた

さすがに11人は多すぎました。最低でも2グループにわけた方がよさそうです。

  • テスト対象、やりたいテストの内容によってはもっと少なくてよいのでは?

参加くださったディレクターからの提案?ですが、今回のテストの内容であれば3人くらいで十分では?という話になりました。
たしかに4分という時間で効率よくであれば、そのくらいでよいかもしれません。
ただし、もっとドメイン知識がいりそうなテスト対象であったり、シナリオテストのような内容であれば人数が多くてもいいかもね
という話になりました。

  • やっぱりふりかえり6分は短い

2回目のテストまでに改善する内容を6分でするのは無理があるかなぁと思いました。
それでも上で書いたような案がでて採用できたのはすばらしいと思います!

テストランチという短い時間なので、6分ですることをカイゼンではなく、次のテスト対象(スコープが狭い場合)を決めることに注力したり、
テスト中の説明とかにしてしまうとかの方が消化不良にならなくていいのかも?

次回のテストランチは

モブテストについては、一旦テストランチでのチャレンジは終わりです(すぐやるかもしれないけど)
各プロダクトの開発で入れてみてもいいかもなぁと思います。

次回はこのモブテストが終わってIssueを実際起こすまでに私が考えていることを 共有できるといいなと思っています(それ社内共有ツールに書けばいいじゃん。とも思う)

モブテストをやってみたよ

最近わたしの流行りのテストランチ
毎週思いついたまま、思いつかないときはだらだらと続けています。

今回はモブテスト( mob testing )

モブっていいですよね

モブテストってなんですか?

モブプログラミングのテスト版です。
といってもよくわかっていないので、海外のスライドを何となく読んだり読んでなかったりしながら
「みんな知らないからとりあえずやってみよう。体験してみよう」と思ってチャレンジしました

今回の目的

  • モブテストというのを参加者全員で体験する
  • 参加者のナレッジを共有する
  • わたしのテスト脳を共有してもらう

参加者

9名いました。
エンジニア2名、マーケティングチーム3名、CS兼テスト1名、サポート兼テスト1名とわたし(テスト)です。

やりかた

  • みんなで同じPC、モニター(プロジェクター)、場所でおこないます。
  • テスト実行⇔ふりかえり をおこないます。
  • 実際に操作するドライバーは1名です。
  • どういうテストをするかを指示するナビゲーターはドライバー以外の人です。

今回は時間に対して人数が多いこともあり、1人を書記(やりとりやIssueに書く内容などをメモる人)というロール(役割)を作りました。

特別ルール 書記

モブテストに書記というロールは特に出てこないと思うのですが、
以前ペアテストについての事例発表で書記というロール使ってるて言ってたなぁと思って入れてみました。 http://jasst.jp/symposium/jasst15hokkaido/pdf/S3-1-3b.pdf
http://jasst.jp/symposium/jasst15hokkaido/pdf/S3-1-3.pdf

これは、のちほどIssue起こすときにとっても助かりました!

ドライバー

今回1回目も2回目もわたしがおこないました。

タイムスケジュール

公開されているSlideShareを参考にしつつ、そもそも1時間しかないお昼休みにやりたかったので 無理矢理スケジュールを作成しました。

また、テストはふりかえりを活かすために複数回することを必須としました。

12:00 - 12:30 ご飯&モブテストについての説明&今日のテストアイテムについての説明
12:30 - 12:34 モブテスト1回目
12:34 - 12:40 ふりかえり1回目
12:40 - 12:44 モブテスト2回目
12:44 - 12:50 ふりかえり2回目
12:50 - 片づけ

複数回するっていうのは、昔 kyon_mm さんに 福岡でやってもらった勉強会で教えてもらって、取り入れました。

atnd.org

テスト対象

エンジニア、マーケティングチーム、CSまで色んな方が参加してくれたこともあったので、 わたしたちの会社で作っているサービスの1画面を対象としました。
わたしたちも使っているシステムなので、サービスについての説明はしなくてもOKでした。

やってみたふりかえり

成果

バグが1件、Issueに書いた内容が7件ほどありました。
8分+αの時間でこれだけ出せるのは効果が高いと思いました。

ドライバーをしてみて

「私のテスト脳を共有する」を掲げていたので、手と口をなるべく動かしつつテストしました。 * 今から何を入力するか

はあまり言えないときもありましたが、自分が思っていたよりかなりのことを伝えられたと思います。

一例ですが、スラッシュ区切りのデートピッカーがあった場合
「テキストでスラッシュ以外やスラッシュなしで日付が入れられるか」というナビゲートがありました。
ここで私が話した話

「まず区切り文字なしで入力します。20180131とかですね。(ここではこれは日付として認識できないだろうからそのまま登録できることはないと予測)
 デートピッカーのテキストエリアにコピペではりつけます。
 あ、自動補完でスラッシュが入りました。この場合はそのまま登録できるのでテストOKとします」←区切り文字なしのテストおわり

「次にスラッシュではないものを入れます。これは例えばPostgreSQLなどで使われているハイフン区切りを入れてみます。2018-0-31とかですね。
 デートピッカーのテキストに貼ってみます。あ、これだとハイフンのままですね。
 そのまま登録してみます。登録できちゃいました。(一覧画面が表示される)
 では、もう一度このデータの編集を見てみます。先ほどの値がスラッシュ区切りで表示されているので、私はこれはOKとします」←スラッシュ区切り以外のテストおわり

「どういうことかというと、ハイフンでも日付として認識できて登録できれば登録としてはOKと私は判断します。
 でも、他のデータと表示が違ってしまうと他に影響があるかもしれないので、編集画面をみてみて、表示にも影響がない(他と同じスラッシュ区切りになっていること)を確認しました」

*1

  • テストの実施
  • 入れる理由を話す
  • OKと判断する根拠、そうではない根拠を話す
  • なぜIssueに書くか、書かない理由を話す

などを話しました。いつもテストでやっていることなんですけど、これ話しながらやってみると、自分てここまで考えながらやってんのね。とちょっとびっくりします。

よかったこと

  • 1つの指示で芋づる式にテストがでてくる

モブテストのだいご味の1つだと思いますが、1つテストすると、それに関連して「あれは?」「これは?」というものがでてきました。

  • みんなで楽しんでテストができる
  • 当初の目的は達成できたかも
  • 短時間の実行なのにIssueに書くようなことがでてきた

うまくいかなかったこと / カイゼンしたいところ

  • ふりかえり時間中もテストの話になっちゃう

ドライバーのテストはしていませんが、ふりかえり中もテストの話(あれやったらどうする?みたいな)が続いてしまったので
もっとメリハリつけた方がよかったのかもしれません。

というか、ふりかえりで話すものをもっと限定してしまってもいいかもしれない(ふんわり、次のテストに向けてカイゼンした方がいいことって言ってしまったので) ここは、他の資料も読みつつカイゼンしたいところ

  • Issueの書き方も別に共有したい  後ろに書いていますが、わたしがIssueを書くときに気をつけていることが色々とあるんですが、この流れでそこまでお伝えできたら
     共有という意味では理解しやすかっただろうなぁと思います(モブテストとは離れちゃうけど)
     2回目テストを入れずにふりかえりでそれをやってみてもいいかもしれません。いいのかな

想定外の発見

  • 社内共有ツールと併用できる

普段ちっこい気づきはできるだけ社内共有システム(Tamel)に書くようにしているのですが、今回の時間で
「あ、これ詳しくはTamelに書いてるから」ということが3~4個ありました。社内共有ツール大事。書いててよかった。社内共有ツール。

ただ、書いていても使いどころや、そもそもそんな記事があるって当事者にならないとわからないので、それが短時間に4つも既知の情報を共有できてよかった♡

  • Issueに書く内容や時間も省略できるかもしれない

このあと出てきた内容をサービスプロダクトのIssueに書いたんですが、Issue書くだけで1時間以上かかっちゃったんですね。
Issueは出来事だけを書くわけじゃなく、エビデンスや、どうすべきかを知ってるかぎりのコンテキストも考えつつ
最適解を自分なりに考えて書いています。
今回はサービス担当のエンジニアが参加していなかったのですが、担当エンジニアが参加していたら、考える部分もモブテスト中に解決できるかもしれないので
Issueを書く時間が短縮できるかもしれません。

  • 時間に対してのインプットとアウトプットの量が半端ない! これ↑20分のできごとだからね!ほんとすごい。
    ただ、めちゃくちゃ疲れる!

これを実業務に入れようとすると、適切な頻度や範囲みたいのはあるかなーと思います。 マリオでいうスターとった時間みたいな感じ。

さて次回

すっごい疲れましたが、来週ももうテスト対象のサービスがリクエストきたのでやってみます。
次回はサービス担当エンジニアが参加してくれるので、また違った発見がありそう!Issue問題も解決するといいな:)

Twitterでは「#テストランチ」で水曜日くらいに呟いています。

これこうした方がいいよ。うちはこうしてるよ。とかあったらぜひ教えてください。時間配分とか。

参考にした資料など

教えてくださったみなさま、ありがとうございます♡

Slideshare https://www.slideshare.net/llewellynfalco/mob-testing-72610210

https://www.slideshare.net/maaretp/mob-testing

www.stickyminds.com

devtest.hatenablog.com

本・雑誌

WEB+DB PRESS vol.102「はじめてのペアプロモブプロ」

*1:・・・そういえば区切り文字でNGパターンやってないなぁ

私が出てこないカタカナ集

何度も出てくるのに何故か出てこない用語集です。

完全に私都合です。

という内容で社内ツールに書き溜めていますが、ほんっとーに何度も見てしまいます。
脳が記憶しないようにしてるとしか思えない。

こういうの作っとくと便利ですよ。これはもう覚えないんだと思う。

エスケープとエンコードの違い

むかーし「HTMLエンコードされすぎてる」ってチケット切ってました。

「それエンコードじゃねぇだろ」とご指摘をいただき、 いまさらながらエスケープとエンコードの違いを調べました。

参考サイト:http://write-remember.com/archives/2728/

プレースホルダ

f:id:underscore42rina:20180123193427p:plain

何故か出ないプレースホルダ

[関連記事] プレースホルダーをラベル代わりにしちゃいけない http://u-site.jp/alertbox/form-design-placeholders

デートピッカー

f:id:underscore42rina:20180123193453p:plain

カレンダー機能

ローディング(インディケーター)

くるくるのやつ。f:id:underscore42rina:20180123193519p:plain

でも正しいのはスロバーみたい。

favicon(ファビコン)

f:id:underscore42rina:20180123193730p:plain よくfavicon設定してないよね。で書きます。

Subscribed

GithubのIssueを書くのに、これがないとassignやlabelがつけられない。

github コラボレーター追加してください

とお願いすること( ..)φメモメモ

ローカルストレージ

記事入力途中でうっかり消しちゃったときに 再表示してくれるあいつ。

入力途中の保存について、実装方法はLocalStorageだけとは限らないので、キャッシュはキャッシュで良いかもしれません

ということなので「ローカルストレージ的なキャッシュ保存」と言えばエンジニアに伝わる予定

CEGTest脳になろう!あらためてCEGTestを使ってみる

呟き発進で、お題をいただきました。

最近CEGTest使ってデシジョンテーブル書けるようになりたいなと思うことがあり、
あらためてお勉強中です。

ちなみに、

underscore42rina.hatenablog.com

で書いたテストランチでCEGTestの紹介をしたら、速攻CSの同僚が使いだして びびりました(エンジニア経験ありの方なので早い)

このエントリーよりもTogetterの方が勉強になるかも↓ togetter.com

このエントリーでは私の脳内回答と
課題を出してくださったあきやまさんの模範解答をご紹介します。

目次

CEGTestとは

原因結果グラフをデシジョンテーブルに変換するソフトウェアです。 JavaScriptで書かれているので、 ↓にアクセスするとすぐ使えます。

http://softest.jp/tools/CEGTest/

使い方はCEGTestを作った加瀬さんのブログなどでご覧ください。 原因結果グラフによるテスト設計支援ツール – CEGTest | ソフトウェアテスト・テスト技法に関する情報サイト

本日の課題

《以下の条件のパスワードを受け付ける》

  • 8文字以上15文字以下
  • 英数/記号

ただし、 * 英字は大文字/小文字混在すること * 数字を含むこと * 記号を含むこと * 過去3回のパスワードと同じものでないこと

わたしの解答

テストランチで紹介しながら「何か変ね」と言いつつ完成したのがこちらです。

作成までの思考回路

さて、この図ができるまでの思考回路を紹介します

1.まずは結果のノードを書くよ!

結果は「パスワードをうけつけるかどうか」 f:id:underscore42rina:20180118232102p:plain

「パスワードを受け付けない」を入れた方が良いか悩み。あとで消すかも。そして消した。

2.「8文字以上15文字以下」かつ「英数/記号」のときにログイン成功を作る

  • 「8文字以下、または15文字より大きいときにログイン失敗」も作った
  • 英数/記号じゃないときにログイン失敗も作った

f:id:underscore42rina:20180118232305p:plain デシジョンテーブルもあってそう

3.英字を含むこと、数字を含むこと、記号であることを追加してみる

・・・なんか怪しくなってきた
f:id:underscore42rina:20180118232457p:plain

4.大文字小文字、過去3回のパスワード入力でないことを追加してみる

あれ?わりと素直にできてしまった

完成した図

f:id:underscore42rina:20180118231605p:plain

実際の動きを見たい方は、CEGTestのインポート機能を使って↓をインポートすると結果が動作で見ることができます。

インポートデータ

10,0,
パスワードを受け付ける
8文字以上
15文字以下
英数/記号
英字である
数字である
記号である
大文字入力
小文字入力
過去3回のパスワードと同じものでない
159,411,165,20,obs,AND,0,1,1,1,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,,-1,
133,133,72,20,obs,,,-1,
177,130,80,20,obs,,,-1,
410,214,87,20,obs,AND,0,0,0,0,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
374,75,87,20,obs,AND,0,0,0,0,0,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,,-1,
415,78,77,20,obs,,,-1,
454,79,77,20,obs,,,-1,
318,96,77,20,obs,,,-1,
323,4,77,20,obs,,,-1,
500,94,241,20,obs,,,-1,
--
[Cause Node]
8文字以上=
15文字以下=
数字である=
記号である=
大文字入力=
小文字入力=
過去3回のパスワードと同じものでない=

[Middle Node]
英数/記号=(英字である AND 数字である AND 記号である),
英字である=(大文字入力 AND 小文字入力),

[Result Node]
パスワードを受け付ける=(8文字以上 AND 15文字以下 AND 英数/記号 AND 過去3回のパスワードと同じものでない),

[Constraint]

ポイント

  • 結果ノードを先に決める
  • 適切なノードの粒度を決定するのが難しい
  • もっと複雑な条件(前提条件ありとか)のときにもスムーズに書ける自信はない
  • これで書くのに慣れると、テストパターンの洗い出しが超早くなれる予定

秋山さんの解答

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 の著者である秋山さんに添削していただいたので、内容と解答を添付します。

この本にデシジョンテーブルについての説明や、CEGTestの使い方も掲載されています。

追記:Twitterで最新解答を貼ってくださいました

Togetterもみてね☆

18,1,
パスワードを受け付ける
正しい文字列
使いまわしでない
文字列長が正しい
文字種は正しい
8文字以上15文字以下
7文字
8文字
12文字
15文字
16文字
短すぎ、長すぎ
英大文字を含む
英小文字を含む
数字を含む
記号を含む
英数/記号以外を含む
過去3回のパスワードのどれかと同じ
279,778,165,19,obs,AND,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
231,629,100,19,obs,AND,0,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
358,602,126,19,obs,AND,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,,-1,
177,445,126,19,obs,AND,0,0,0,0,0,1,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,,-1,
324.8000030517578,457,113,19,obs,AND,0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,,-1,
126,248,150,19,obs,OR,0,0,0,0,0,0,0,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
220,146,46,19,obs,,,-1,
121,143,46,19,obs,,,-1,
154,139,54,19,obs,,,-1,
187,141,54,19,obs,,,-1,
267,147,54,19,obs,,,-1,
232,260,114,19,obs,OR,0,0,0,0,0,0,1,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
281.8000030517578,268,103,19,obs,,,-1,
311.8000030517578,268,103,19,obs,,,-1,
344.8000030517578,295,77,19,obs,,,-1,
376.8000183105469,295,77,19,obs,,,-1,
406.8000183105469,238,135,19,obs,,,-1,
447.8000183105469,149,228,19,obs,,,-1,
ONE,176,28,27,19,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,,-1,
--
[Cause Node]
7文字=
8文字=
12文字=
15文字=
16文字=
英大文字を含む=
英小文字を含む=
数字を含む=
記号を含む=
英数/記号以外を含む=
過去3回のパスワードのどれかと同じ=

[Middle Node]
正しい文字列=(文字列長が正しい AND 文字種は正しい),
使いまわしでない=(NOT 過去3回のパスワードのどれかと同じ),
文字列長が正しい=(8文字以上15文字以下 AND NOT 短すぎ、長すぎ),
文字種は正しい=(英大文字を含む AND 英小文字を含む AND 数字を含む AND 記号を含む AND NOT 英数/記号以外を含む),
8文字以上15文字以下=(8文字 OR 12文字 OR 15文字),
短すぎ、長すぎ=(7文字 OR 16文字),

[Result Node]
パスワードを受け付ける=(正しい文字列 AND 使いまわしでない),

[Constraint]
ONE(7文字 8文字 12文字 15文字 16文字),

1. 結果ノードについて

結果ノードが[パスワードを受け付ける]と[パスワードを受け付けない]のふたつありますが、こちらは、片方が真ならもう片方は必ず偽になりますので、[パスワードを受け付ける]一つだけのほうが良いです。
(結果ノードについては、しばらくは、一つにして、複数になるときには原因結果グラフを分けて描いた方がよいです)

2. 中間ノードについて

問題文から中間ノードを抜き出した感じですが、そうではなく、結果ノードを一段ずつ分解するイメージで中間ノードを作成するほうが良いです。
(私の解答例を見ていただけるとコツがわかるかな? と思いますが、何枚も描いてコツをつかむしかありません)

3. 原因ノードについて

原因ノードについては、どこまで具体化したらよいか迷うと思います。
決まりはありませんが、「ロジックレベルまでは原因結果グラフに描いて、具体値はデシジョンテーブルにしてから列を増やす」のが原則です。
上記原則で言うと、私の原因結果グラフの文字数は具体化しすぎです。私はテスト設計者として、テスト実装者へ必ず実装してほしい同値分割レベルを描いています)

4. 制約について

制約については、まずは【ONE】だけ使いこなせるようになってください。他の制約は当面不要です。

5. デシジョンテーブルを見て

全体的に[T]がほとんどなので、むむむという感じです。[ログイン失敗]の結果確認がしたいのであればよいのですが……。

CEGTest脳になろう

冒頭でご紹介したTogetterには、他にも同じ問題で解答してくださっています(なんとCEGTestを作った加瀬さんまで!)
実際に書いてみると実感できると思うのですが、デシジョンテーブルをいきなり作るのと
同じお題でCEGTestを使おうとすると、作り方が違うんですよね(もしかしたら一緒の人もいるかもしれないし、途中で一緒になるかもしれないけど)
複雑な項目になると、こういったツールを使えるか使えないかで差がでてくるなぁと感じているので
ぜひみなさんも使ってみてくださいね!

テストランチを社内ではじめた話

2018年もよろしくおねがいします。

ブログではとくにふりかえり(100エントリーのふりかえりはしたけど)も
今年の決意表明もしていませんが
自分らしくやります。はい。

テストランチをはじめてみた

昨年から社内でテストランチというものをお試しではじめました。

テストランチとは

『ゆるく、長く』 をモットーに、 テストについて考える、勉強する、知る、共有する ことを ランチを食べながら設ける時間です。

  • 名前:『テストランチ』
  • 時間と場所:1~2週に1度程度。12:00~12:50 会議室
  • 対象者:何となくテストの話がしたい人(エンジニア、カスタマーサポート、マーケ、バックオフィス、役員問いません!)
  • テーマ:設けるときと、フリーのときを作ろうと思います
  • やること:必ずわたしがいます。テーマがあるときは、それに則った何か(発表者だけ、または全員)を持ち寄るでも、フリートークでもよいと思っています。
  • モットー: ゆるく長く! (事前勉強や宿題はできるだけ設けず、ゆるくやりたいです。ゆるく続けることで意義があればいいなぁ)

誰もいないときは、私が一人でもくもくする予定です(´~`)モグモグ
今のところ誰かしら参加いただいているので、雑談とともにお話しています。

テストランチを開こうと思ったわけ

色々とあるのですが、以下のことを思い、もっと自分が動かないとダメじゃん。 でも重いのは続かないし、カジュアルにはじめたい!と思いました。

  • テスターが複数人になると「お隣のテスターがどんなテスト(やりかた、気持ち、悩みなど)をしているかわからない」
  • エンジニアのテストってなんだっけ?
  • プロダクト(のIssue)以外でテストの話する機会がないよね
  • エンジニア同士、エンジニア、テスター、ディレクター・・・テストの話する機会ないよね
  • コンスタントにテストの話題、課題、やりたいこと、知っていることを話す機会を増やしたい
  • 勉強会を定期開催するのは重いなぁ
  • 一方的にブログや社内共有ツールやSlackに発信しても情報交換がなかなか進んでいない

もちろん↑にペアテストやればいいじゃん。とかすでに出そうな解決策もあると思うのですが
そういうのも含めて話す機会を増やしたいなぁと思っています。

この先のこと

コンスタントに開催が継続できそうであったら、話題に上がった中から

  • 勉強会をする
  • 読書会をする
  • 情報を発信する(ブログなどなど)
  • テストの戦略を考える
  • テストのやり方をかえてみる

とか始められるといいなぁと思います。

テストする人。は、テストできる人になったのか

記念すべき100エントリー目です♡ありがとうございます。

このブログを始めたきっかけ

・・・忘れました。何で作ったんだろう・・・

ただ、技術ブログ系は はてなブログだよね というよくわからないミーハー心で作ったのは覚えていますw

このブログタイトル名になったわけ

プログラマー時代から自覚してたんですが、ネーミングセンスが皆無なのです。
なので、どこかからあやかって付けたりするわけですが、これはUNICORNというバンドの曲名からつけたはず・・・なんだけど、っぽい曲名が「ママと寝る人」しかない・・・(゜-゜)

まぁいいのです。未だに自分の職業名に迷子なので「テストする人。」が一番あってると思っています。

本題

さて、100個くらいテストのこととかコミュニティのこととか書いたり書かなかったりしていますが 何か変わったのでしょうか?

期間にして5年程度。

変わっていないこと

バグ出し がとてもうまくなった 」という自覚は全くありません。ずっと同じくらいの感覚です。

変わったこと

5年前の比較だと、色々ありすぎると思います。

いじめる気持ちから、私がどう動かしたいかどう動いて欲しいか

個人的によく人とお話するのが「テストって意地悪な気持ちでやるんでしょ?」というもの。
それについて、全く気持ちが反対になりました。

以前は「バグを出してやろう」みたいな気持ちでやっていたんですけど、
今は「まず自分が思うように動くこと、その次に こんな動き方もあんな動き方もするよねー。」とネガティブな感情での活動ではなくなりました。

操作とか、試しているテストは結果として一緒なんですが^^;心持ちが正反対になったんですね。

バグを探すから、プロダクトはどうあるべきかを考える

↑が変わると何が変わるかというと、要望とか、操作性とか、プロダクトそのものについて考えることが増えたのではないかと思います。(もちろん、その他にもたくさん要因やキッカケはあるのですけど) それについては、以前SQiPシンポジウムでも少しだけ紹介しました。 www.juse.jp

エンジニアのために工夫するようになった

↑が変わるとともに少しずつ変わったのは、Issue(チケット)の書き方(項目ではなく、ニュアンスや粒度)とか、とにかく「エンジニアが負担にならないためにどう動くと、エンジニアが心地よく動けるか」を考えていたように思います。(とはいっても、もともと私の性格が口が悪い、調子に乗る、悪態をつく、と問題ありだったので、エンジニアたちにとってはそう捉えてもらっていないかもしれません)

Issueの書き方以外にも、やれることはチャレンジしたりしなかったりしています(自分のテストスピードが落ちるものはあまりやりたくない・・・)

説明できることが増えた

「なぜこのテストをするのか」「なぜしないのか」「やるべきか・やらないべきか」「なぜやらなかったか」 今まで 何かを聞かれたときに言葉に詰まることも説明できることが増えたと思います。(あくまでも昔の自分に比べて)

  • テストはやれるならやった方がいい
  • 不安だから多ければ多い方がいい
  • リリース後にバグがでたら、なぜそんな簡単なものも見れなかったのかに対する説明ができない

テスト神話に対する、今の自分の解答、わたしが働いている会社(やプロジェクト)で最適解の説明は できるようになってきたと思います。

QCDやチームの体制、プロダクトの性質で、自分の見解が言えるようになるのはテストをする上で強みになったと思います。
ただ、予算・工数ありきでをベースに考えているところがあるので、もっと必要な部分は、テストを増やすべきだと言えることもできないといけないのかなーとも少し思っています。(テスト軽視になるのも困るだろうし)

テストできる人。なのか

まだまだできないことが沢山(なにしろ、バグを出すのは最初からあんまり変わってない気がしている)あるので、まだまだ「テストできる人。」とは言えません。

200エントリーのときは、もっといろいろできるようになっているといいなぁ

コードを書かないテスターがテスト自動化にどのように介入するか

9日目です qiita.com

qiita.com

わたしの仕事

テストチームが組織としてあるわけではないので、「テスター」と名乗っています。
最近でいうと、「探索的テストを得意とするQA」というのが近いかもなぁと思っています。

何をしているのか

では、普段している内容です。

  • 画面詳細設計書レビュー
  • 探索的テスト
  • スクリプトテスト

探索的テストとスクリプトテストは、私は厳密に切り分けて考えていないことと スクリプトテストで使っている仕様書も、かなりざっくり(いいように言うと、高位レベルテストケース・・・といっていいかなぁ)したものを 使っています。完全に属人化しているテストです。

わたしは、細かいテストケースも書いていませんし、エビデンスのように「テストした形跡」をほとんど残していません。 不具合やカイゼン案はすべてIssueに記載していますので、問題点はすべて残しています。それらを以てエンジニアと合意をとっています。

わたしたちがやっているテスト自動化(テストコード)

わたしたちの会社では、プロダクトを作るエンジニアがテストコードも書きます。 (SETチームはいません) 現在はテストコードやどのテストレベルに対して書くかは、各プロダクトチームのエンジニアにおまかせしている状態です。

テスターはテストコードを書くべきか

今年発売された、こちらの本に紹介してありました。

初めての自動テスト ―Webシステムのための自動テスト基礎

初めての自動テスト ―Webシステムのための自動テスト基礎

これからはテスターも得意とする分野でテストコードを書いた方がよいよね(ざっくり)という内容もありました。
そして、そう思っているQAエンジニアも多いと感じています。

私も、テストコードやプロダクトコードは読めるに越したことはありませんし、テストが書けるのはよいなと思っています。

なぜテスターがテストコードを書かないのか

わたしはテストコードを書いていません。

一時期E2Eのテストコードが書けるとしあわせになれるだろうと、 Turnip+ Selenium の勉強をして、インストールおよび少し書くところまではしましたが 結局定着しませんでした。

何がだめだったか

「テストコードを書く脳」と「テストをする脳」が全く別物だったことと、
そのスピード感とスキルが違いすぎて、運用に乗せられませんでした。

(大前提に、そもそも私はエンジニアをしていた時代に、スパゲッティーコード製造機で、プログラムコード書くのが本当に苦痛だったんでした)

探索的テストが得意なエンジニアは、テストコードを書くのは難しいのではないかと思います。
(または超高速でかけてしまう探索的テスターもいちゃうのかもしれません)
動いた反応を見て、次々に関連付けや過去の経験から次のテストをおこなうため、 コードに落としていくのは勝手が違いすぎるんですよね。(なので、実現できる人はめちゃくちゃ凄いと思う)

テスト手順書をきちんと落とし込めるテスターであれば、得意になる可能性はぐっと高くなるのではないかと思います。
それでも、設計とプログラミングコードを書くときに使う脳が別 っていうタイプの人であれば
難しい感覚はわかるかもしれません

では、どうすればよいか

だいぶ言い訳くさい内容になってきましたが、今、わたしが考えているものは次のような構想です。

  1. どこを自動化するか、場所やボリュームを選定する  プロダクトに対して、テストコードを書くべき機能や内容をエンジニアと決めたいと思っています。
    現在もいくつかしていますが、もっとわかりやすく、テストのピラミッドを使ったり、テストレベルなど見えるようにしたいなぁと思っています。

  2. 必要なテストデータの選定をする  「十分なテストケース」はエンジニアの勘と経験に頼っているままにしているところがあります。  そこにテストの知見を入れられるといいなぁと思っています。

  3. 各人が「すべきテスト」誰がどのテストをするか見えるようにする  現在は「テストをしている」というざっくりとした意識と、Issueの内容しかエンジニアと共有できていないのですが
     各々が「しているテスト、していないテスト」誰がどういったテストをしているかをはっきりさせるとお互いが安心できると思います。

エンジニアと話してみた

このエントリーは数日前からコツコツ書き溜めていたのですが、
昨日(12/8)わたしの上長で兼マネージャー兼エンジニアと話す機会があって、↑の話になりました。

で、できそうなことがあったので追加。

4.お互いに最小限のコストからはじめられるところを探る  私はテストができますし、エンジニアはコードを書いたり、環境を用意したりが得意です。

 バグの再現手順をテストコードに書けないか?という話があがったのですが、いきなりテストコードを書くのはハードルが高いです。
 でも、バグの出た箇所だけなら、ボリュームは多くありません。ですので
 ■わたしができること
  * Issueを書くことができる。再現手順をテストシナリオのフォーマット(Turnipのようなイメージ)で書くならできそう
■エンジニア
  * Issueのテストフォーマットからテストコードを書くならコストがそこまでかからないかもしれない

 ということになりました。やっぱり会話大事。近く、わたしたちのテスト自動化はまた新しい道を進み始めるかもしれません。

で、さらに「初めての自動テスト」を読んで、

これらをユニットに落とし込めるかをエンジニアと話し合う→勝手に落とし込んでいる

状態がお互いにしあわせかもしれないなぁと思いました☺

勝手な結論とまとめ

  • 得意分野を活かすテストをする
  • 自分が持っているテストやバグの知見をエンジニアに共有する
  • 足りないテスト、できているテストをエンジニアに共有し、合意をとる

STAC(システムテスト自動化カンファレンス)に参加します

明日開催される、STAC(システムテスト自動化カンファレンス)に、エンジニア2名と参加します。

九州から遠征しますので、この機会に沢山の方とお話したいです。
アドバイスください!
見つけたらぜひお声かけください:) @rinaにリアクションしてもらえたら、全力で会いにいきます!