yoshitake_1201’s diary

テストのこととか、ペンギンのこととか書きます。

テスト観点の共有会はとてもたのしい #Fusic #wacate

この記事は?

qiita.com

Fusic Advent Calendar 2019 16日目の記事です。
わたしとチームメンバーがやっている「テスト観点共有会」を紹介になります。 やっていることや目的、やってて楽しいことをまとめました。
この会はとても楽しいですよ。

テスト観点共有会とは?

チームメンバーとテスト観点*1について語り合う会です。 チームメンバーとテストの認識を合わせる目的でやっています。
会では、1つのテーマを選び、そのテーマについて「テスト観点」を語り合います。 私達はWebシステムを開発しているので、取り扱うテーマはWebシステムに関わるものになります。 例えば「電話番号」「メールアドレス」「PDF出力」「SPA(Single Page Application)」「アカウント登録機能」「ログイン画面」などです。

テスト観点を話すだけでなくそこで出た観点をまとめ、最終的には、テストデータ*2を添えたリストを作っています。

共有会のやりかた

会は「テスト観点を出す & まとめる」フェーズと「テストデータを出す」フェーズの2つにわかれています。
それぞれ以下の流れで進行します。

  1. ① テスト観点を出す & まとめる
    1. テーマを選ぶ
    2. 観点を出す(出した観点は箇条書きでメモする)
    3. 出した観点を階層をつけて整理する
    4. 2と3を繰り返す(深堀りしたり広げたり削ったりする) > 参加者全員の納得が得られれば観点出し終了
  2. ② テストデータ出し(リスト作り)
    1. ① のテキストをスプレッドシートに貼る
    2. 適当に体裁を整える
    3. テストデータを考えていく
    4. 参加者全員の納得が得られればテストデータ出し終了

例えば「電話番号」をテーマにしたときは、以下の感じになりました(抜粋)。
■ ①が終わったタイミング
f:id:yoshitake_1201:20191216223032p:plain

■ ②が終わったタイミング
f:id:yoshitake_1201:20191216223104p:plain

※ 画像のモザイク部分にはテストデータが記載されています。

共有会をやるときに大事にしていること

共有会をやるときには、以下に注意してやっています(運用ルールからそのまま抜粋)。

  • 観点出し中に出た意見を否定しない
    • とりあえず記入する
  • 観点出し中にテストデータ思いついたら書いても良い
  • 観点出し中に無理にテストデータを考えない
  • 「これは当然やるでしょ」なものこそ書く
    • 共通認識を得るためのものでもある
  • 「テストデータFail想定のもの」は対象の行のテスト観点に関わりが深いものを書く
    • どの行にも共通したテストデータが入るのはなにかおかしい

この観点共有会は「自分の中に持っているもの」だけでなく「世間一般ではどうなっているだろう」や「どんな規格があるのか」を調べたりします。 当たり前と思っているものこそ調べてみる。というのも大事にしています。

やってよかったこと

いっぱいあるのですが、特によいことは「話が脱線する」ことです。
主にテスト観点出しのフェーズで起きるのですが、「こんなバグがあったよ」という話から「そういえばこのときこんなバグもあったな」と他のバグの話になったり、「こんなニュースや規格があるよ」とWebページを調べていたら全然関係ない記事が目についてそっちの話題になったりします。
この脱線によって、新しい観点に気づいたり、まとめたリストを見たときにその会のことが思い出しやすくなります。

もちろん規格や定義も調べるので、そのテーマについても新たな発見があったりします。
たとえば、電話番号の市外局番について。
私は「2桁から5桁」と思っていたのですが、実は先頭の0は「市外局番」ではなく「国内プレフィックス」なので「市外局番」は「1から4桁」だったと初めて知りました*3

また、参加者の年齢がバラけていることもあり、お互いに学ぶことがあります(特に時事ネタ)。
そしてこの会には弊社のシニア・プリンシパルエンジニアも参加してくれるので開発時の視点や考えも教えてくれます。
いろいろと異なる視点での意見が出るのでとても良いですね。

おわりに

この共有会を少しカスタマイズして、WACATE 2019 冬の夜の分科会でやらせてもらいました。
そこでは「テスト観点を出す」フェーズしかできなかったのですが全然違うロールの方とやったので「そんなところが気になるのか〜」と勉強になりました。
そっちは別途記事にしようと思ってはいますが、とりいそぎ資料だけアップしました。
参加してくださった方が、分科会の記憶を思い出す材料にしてもらえると幸いです。

speakerdeck.com

このブログや↑の資料だけでは、楽しさや良さはなかなか伝わらないと思っています。
なのでテスト観点の共有会をやったことがない方はぜひ自分のチームでやってみてください。

*1:この記事では「テスト観点」を「テストするときに気になること/テストすること」という意味で使っています。

*2:この記事では「テストデータ」を「テスト設計やテスト実行時に参考にしたり使用するデータ」という意味で使っています。

*3:総務省 電話番号に関するQ&Aを参考にしました。

「うまくいったらどうなるの?」と「なんでそれやろうと思ったの?」

この記事は?

自分用の備忘録です。 あのチームのフレーズ「うまくいったらどうなるの?」このフレーズをうまいこと使えなかったんですよね。 使ってはみるけどなかなかしっくりこないというか。

ですがJaSST'19 Kyushuの講演で改めてこのフレーズの話を聴け、そしてその後いろいろ妄想をふくらませた結果ちょっとだけ理解できました。 これがわかったことは個人的にはすごいことなので、忘れないうちにメモっておこうと思います。 (わかった気になっているだけかもしれないけどw)

「うまくいったらどうなるの?」

speakerdeck.com

スライド14ページより。
f:id:yoshitake_1201:20191205190437p:plain

「うまくいったらどうなるの?」
これは↑のスライドで紹介されているあのチームが使っているフレーズです。 使うと以下のような良いことが起きるそうです。
・ゴールがわかる
・確かめる方法がわかる
・ゴールまでのステップがわかる
・うまく迷える

あのチームのフレーズは、普段マネをして使っているんですが、この「うまくいったらどうなるの?」はなかなか使うことができませんでした。 言いはするけどしっくりこない…その良さを実感できない、という感じでした。

「なんでそれやろうと思ったの?」

そこで「うまくいったらどうなるの?」を使う状況を想像してみました。 そして自分だったらその状況で何を言うかなぁ?と言葉を考えてみました。 それが「なんでそれやろうと思ったの?」です。

「うまくいったらどうなるの?」と「なんでそれやろうと思ったの?」。 これらのフレーズを使いたいのは「目的がわからないとき」だろうなぁと想像しました。 目的(ゴール)を明確にして、目的の話や、そのゴールにたどり着くまでの話をしたいんだろうなぁと。

そこまで考えて「ゴールを聞きたいんだったらどっちでも良いんじゃない」と思いました。 でもそれぞれの質問が全く同じものとは思えなかったので、もうちょっと考えてみることにしました。

「うまくいったらどうなるの?」と「なんでそれやろうと思ったの?」の違い

先ほどは「自分が質問する立場」になって考えたので、今度は「質問される立場」になって考えてみました。 すると答えが微妙に違うことに気づきました。
「うまくいったらどうなるの?」と聞かれると「うまくいったら〇〇になりますね」と返答するんですが、 「なんでそれやろうと思ったの?」と聞かれたら「〇〇したかったんですよね」と過去形で返答してるんですよね。

この違いはなんでだろう?と考えると、以下の2つがあるのではないかなぁと思いました。
① 「こうしたいと思った時点」の過去に引っ張られている
② 「否定されるんじゃないかな〜」という不安

①はまぁおいておくとして、②について。
②は自分の思考の癖も強いと思います。 「なぜ」が強いワードだからなのか、なんなのか 否定されそうな気がして弱気になって返答する状況が思い浮かびました。
まぁそれがなんでなのかはさておき、「なんでそれやろうと思ったの?」と聞かれると過去形で返事をする可能性があるとわかりました (もちろん、過去形ではなく「〇〇したいからです」と返事するケースもあったんですけどね)

ですが「うまくいったらどうなるの?」だと過去形になることはなかったんですよね。 たぶん、取り組んだことが起きた時点、未来の時点で物事を考えているからと思います。

「うまくいったらどうなるの?」はうまくいった未来だけ聞きたいわけじゃない

そして妄想続けるうちに「うまくいったらどうなるの?」と聞かれたときに、「うまくいった未来だけ返答してハイ終わり!」とはならないと気づきました。 「うまくいった未来」を聞いてるんだから、当然「うまくいかなかった未来」も気になりますよね。 それにもしかしたら「うまくいったら未来」のビジョンが違っているかもしれないので、そこで疑問も出てくるかもしれません。

あのチームが使っているフレーズです。 何気なくシンプルに見えるけど、その実はそんな甘いもんではないと思いました(笑)

ここまで考えてようやく「うまくいったらどうなるの?」の良さがなんとなく理解できました。

フレーズはきっかけ

「うまくいったらどうなるの?」はキッカケだと思います(フレーズ全般に言える気もしますが)。 その返答からもっと聞きたいことが生まれて、お互い認識があっていくのかなぁと。 このフレーズの素敵なところは「うまくいったら」と領域を意図的に狭めているんですよね。 意図的に狭められると、その反対のことも気になるし、他にはもっとないか?と気になってくる。 とてもいいフレーズだなぁと思いました。

そしてそんなことを考えていたら、子供の頃に見た「はごろもフーズのCM」が浮かび上がってきました。 水面に水滴が落ちるあれです。 イメージはこんな感じ。

水面に水滴が落ちると、周りに水滴(水)が跳ね上がりますよね。 この最初に落ちる水滴が「フレーズ」。 水滴が水面にあたると、さらに水滴がたくさん出現する。 この水滴が水面にあたるのが「フレーズに回答する」ことで、たくさん出現した水滴が「他に気になる質問」なイメージです。

「水面に水滴が落ちる」映像はこっちではありません(笑)

おわりに

自分はとりあえずマネをするのが好きなので、何か話を聞くと、特に考えずにマネして使うことが多いです。 フレーズは平たく言ってしまえば「言うだけ」なので、マネしやすい!。 そして使ってみるとそのフレーズの効果を体験したり、「なんでこのフレーズ使ってるのか」がわかるのでとても楽しいですね。

あ、ここまで書いてきましたが、実際のところは全然お門違いなのかもしれません(笑) その場合はとてもかっこ悪いんですがまぁ良しとします。 今回いろいろ考えたことで「うまくいったらどうなるの?」の理解が進んでかなり使い勝手がよくなったので。 このフレーズは本当に便利だなぁと思いました。 (使うとめちゃくちゃ考えるて疲れちゃうんですけどね。でもしっかり考えるのは大事です)
このフレーズを使ってうまく迷っていきたいですね。

「『パスワード変更ページでパスワードを変更したら、他のブラウザでそのパスワードでログインできない』ということがある」

この記事は?

qiita.com

ソフトウェアテスト Advent Calendar 2019の1日目の記事です。
この記事では私が最近体験した「とある不具合報告から調査(テスト)をしてみた話」です。
自分ならどんなテストするかなぁ〜?どこを狙うかなぁ〜と思いながら、読んでもらえると嬉しいです。

「『パスワード変更ページでパスワードを変更したら、他のブラウザでそのパスワードでログインできない』ということがある」

先日こんな報告がありました。
「『パスワード変更ページでパスワードを変更したら、他のブラウザでそのパスワードでログインできない』ということがある」

■ パスワード変更ページとは?
パスワード変更を行うためのページです。
このシステムでは、システムログインページにある「パスワードをお忘れの方はこちら」の「こちら」部分をクリックするとパスワード変更メール送信ページに遷移します。
このページでメールアドレスを入力すると「パスワード再設定ページURLが掲載されたメール」が入力したメールアドレス宛に送信されます。
このパスワード再設定ページでパスワードを入力するとパスワード変更でき、加えてパスワード変更を行ったブラウザではそのままログインされるというものです。

f:id:yoshitake_1201:20191201210111p:plain

報告を受けたとき、追加情報で以下を教えてくれました。
 ・ 絶対起きるわけじゃない
 ・ もう一度設定したらログインできるようになる

この報告を最初に受けたとき、軽く調査をしたのですが再現させることができず。
「報告者のパスワードの打ち間違いじゃない?」と結論づけていました。
しかし、ぽつぽつとこの報告がくるので、テストチームでもう一度調査することにしました。

テストチームによる調査開始

調査は私とsae氏の2名で行うことになりました(sae氏は私と同じテストチームのメンバー)。
バラバラにやっても効果が薄いだろうなぁと思ってペアテストを行うことにしました。

このとき、最初に我々が狙ったポイントは以下の2つでした。
 ① 特定のブラウザ(Iから始まって途中がEのやつ:以下IE)でやってみる
 ② パスワードに使われる文字の組み合わせに注目する

①の理由: このシステムでは ①のブラウザはテストのスコープに入っていなかったから。
②の理由: テスト実施中に使わない文字が使われているんじゃないか?という2人の意見の合致。

別のバグがみつかる

調査してみましたが、現象を再現させることはできませんでした。
しかし調査の途中で「パスワード変更のメールが2通送信されることがある」というバグに遭遇しました。
「あーあとでチケット登録しておこう」と思ったのですが、なんとなく…このバグに違和感を覚えました。
特に根拠はありませんが「これ何かにつながってるんじゃないか?」そうこじつけて、このバグの調査を始めました。

別バグ「パスワード変更のメールが2通送信されることがある」の調査結果

f:id:yoshitake_1201:20191201211344p:plain

いろいろ試してみるとこのバグについて以下のことがわかりました。
現象:「パスワード変更のメールが2通送信されることがある」
 ・メールアドレスを入力後Enterキーを押すとメールが送信される(仕様)
 ・Enterキーを押したときのみ再現することがある
 ・メール送信ボタンをクリックしても再現しない
 ・IEでしか再現しない(他のブラウザでは再現しない
しかしこれ以上何も見つからなかったので、改めてアカウントを登録してからテストを再開することにしました。

アカウントを新しく登録すると…

f:id:yoshitake_1201:20191201211814p:plain

このシステムでは、システム管理者が管理画面のアカウント登録ページから新規アカウントを作成します。
そこでちょうど開いていたIEで管理画面を開き、新規アカウントを登録しました(まだシステムに登録されていないIDを使用)。
このとき「さっきのEnterで二重登録されるバグ、これでも起きないかな?」と思ってEnter押してみました。
すると…あら大変。
同じIDのアカウントが2つ登録されることを発見しました。
そこでこのシステムの開発担当者Jに声をかけたところ、快く急いで来てくれました。
このバグの調査も兼ねてそのまま3人でペアテストをすることにしました。

アカウントが二重登録されるバグ

f:id:yoshitake_1201:20191201212902p:plain
会員登録ページでは「既に登録されているID」は登録できない機能が実装されていました。
登録済みのIDを入力して登録ボタンをクリックするとエラーで弾かれるのです(既に登録しているIDを入力してEnterキーでも同様)。
なので、一度アカウントを登録→もう一度同じIDを入力して登録ボタンをクリックをした場合、エラーで登録できないという結果になります。
しかし、この「新しいIDを入力して、Enterキークリックすると二重登録される」は↑の機能では弾くことができていないことがわかりました。

このアカウントはログインできるの?

f:id:yoshitake_1201:20191201213507p:plain
意図せず同じIDで作られたアカウントに対して、「このIDでログインするとどうなるんだろう?」
そんな興味がわいてきました。
そこでログインを試した所、普通にログインすることができました。
このときデータベースを調べた所「作成された順序が早い方」でログインされていることがわかりました。
これが判明して少しの間があった後、言葉は違えど同じことを3人は言いました。
「これパスワード更新されたときってどっちのアカウントが更新されるんだろうね?」

調査結果

f:id:yoshitake_1201:20191201213932p:plain パスワード変更メールでパスワード変更を行うと、「作成された順序が遅い方」のパスワードが変更されていることがわかりました。
なので、二重登録されたアカウントでパスワード変更を行うと、新しいパスワードではログインできなくなるのです。
そう。
つまり最初の報告である「パスワード変更するとログインできなくなることがある」というバグの原因は、「二重登録されたアカウントにのみ」再現するバグだったのです。
まとめるとこんな感じ。
 ・IEでアカウント登録すると二重で登録されることがある
 ・このアカウントは登録順の早いでログインされる
 ・このアカウントでメール変更を行うと登録順の遅い方でログインされる

ちなみに調査をすすめると以下のこともわかりました。
 ・ 頻度は小さいけどIEだとボタンクリックで二重登録されることがある(めっちゃ頻度低いけど起きた)
 ・ パスワード変更前のパスワードを入力するとログインできる

なので、この「アカウント二重登録バグ」を解決してもらったところ、「パスワード変更するとログインできなくなるバグ」は起きなくなりました。
(もちろん、メールが二通送信されるバグも直してもらいました)

なぜ最初のテストで原因のバグを見つけれなかったのか?

理由は「このブラウザでテストしていなかった」につきます。
もしテストしていたら見つけれた自信はあります。
しかし、テスト前を思い返すと「このブラウザテストする?」「いや対象外なんでいいですよ」といった会話をしていました。
当時の自分は「リソースもないしな…」とそのまま飲み込みました。
今の自分なら「いやいや、IEもやったほうがいいよ!」と言ったり、こっそりやったりすると思いますが、当時は他の事情もあったのでやらなかったと思います。なので防ぐことは無理だったでしょう。

見つけるのに手間取った理由

① 「パスワード変更」という事象に囚われすぎていた。
この部分ばっかり探していたのでなかなか見つけることができなかったです。
原因と事象が離れているというのは難しいですね。

② もう一度設定したらログインできるようになるという報告
この報告、実は状況説明が足りていなかったのです。
このシステムは「パスワード変更を行うと、行ったブラウザでは自動でログインされる」仕様なんです。
ここで報告の「もう一度設定したら」というのは、「ログイン後の画面で」パスワード変更するとログインできるようになるというものでした(後から気づきました)
ログイン後画面ではパスワード変更したときは「登録順の早い方」になっていたようです。
f:id:yoshitake_1201:20191201215026p:plain
なので、ログイン後にパスワード再設定すると早い方でログインできる。
そしてユーザーも一度パスワードを忘れてしまっているから、今度はパスワードを忘れない(にくい)。
このことからこの事象はセルフで解決されていたわけです。
ここの読み違いは難しいですね。

なんで見つけることができたの?

この調査をしたのは2019/10/30(水)の午後でした。
ではその午前中に何をしていたのかというと、JaSST'19 Reviewの予稿集をsae氏と読んでいました(JaSST'19 Reviewは11/1開催)。
この予稿集の中でmiwaさんの「違和感のつかまえ方」のスライド59 が印象に残っていました。
speakerdeck.com

「想定外の問題を見つけるのではなく想定を広げる」(スライド59より)
f:id:yoshitake_1201:20191201204632p:plain

私はモノマネしたくなるタイプなので、この言葉をマネして「メールが二通送信されるバグ」の想定を広げていこうとしていました。
このモノマネがあったから、原因を見つけることができたと思っています。

こう聞くと「こじつけ」や「偶然が続いていただけじゃない?」と思うかもしれません。実際そうなのかもしれません。
でもこのことがきっかけでバグを見つけることができたので、とても良い経験となりました。 想定内のこと(既に見つかったもの)を拡張して、新しい問題を見つける体験をできたと思うのです。
(もちろん、バグの原因が見つかって、そして無事なおってよかったです)

同じバグでも見つけ方がかわる

今回は「パスワード変更」から想定を広げていきました。
その結果見つかった原因は、自分が想定できるバグ(普段のテストをやっていると見つけることができたバグ)と同じ原因でした。
もし、この想定できているテストをやっていれば「パスワード変更できないバグ」には出会わなかったかもしれません(出会う前にアカウント二重登録バグがなおっている可能性が高いので)。
しかし状況の違い、アプローチの違い、考え方の違いなどから「全く違うアプローチ」で想定できるバグを見つける、というのはなかなかに面白いものでした。
原因がわかってしまえば「そりゃそういう動作になるよね」となっちゃいますが、それがわかるまではなかなか大変ですね(笑)

次この事象に出会ったら?

もし、またこの「パスワード変更ページでパスワードを変更したらログインできなくなることがある」の調査をすることがあるなら。
自分は今回の経験から「IEでアカウント登録して二重登録されないか」をテストすると思います。
自分にとっては、今回の経験からこのバグはもう「想定内のこと」になっているのですね。
そう考えると自分の成長を感じれる気がします。

でももしそれでも再現できなかったら?

そのときはまた違和感をつかまえにいくんだろうなぁと思います。

一応

DBで重複不可にしておけば、というご意見がありそうなのですが、別の事情でできなかったんです。
こんな感じで「全部は書けていない」「そして一部脚色した部分」もあります(大筋は変えてないけど細部は少し変えた程度)。 そのあたりはご了承ください。

connpassでは中止操作をする前に、イベントタイトルやイベント情報を編集したほうが良い

この記事は?

q-te.connpass.com

今週の火曜日(2019/8/27)、19:00 ~ 上記の勉強会開催予定でした。
しかし悪天候で電車が止まるかなぁといった心配もあったためイベントを中止しました。
ふりかえってみると中止の判断は正解だったなぁと思っています。

ただ主催イベントを中止するのが初めての経験だったので、ここに気をつけること(特にconnpass操作)について書きます。

connpassで中止操作する「前に」やったほうが良いこと

以下2点です。

  • イベントタイトルに【中止】などの文言を入れる
  • イベント本文にもでかめに【※ このイベントは中止になりました】などの文言をいれる

connpassでの中止操作について

f:id:yoshitake_1201:20190830194219p:plain

イベントの編集画面のヘッダー部分に「イベントを中止する」ボタンがあります。
クリックすると、こんな感じのModalが出てきます。

上記にも書かれているんですが、イベントを中止してしまうと編集操作が一切できなくなります。
■ できなくなる操作
- イベントタイトル
- イベント本文
- 参加枠や会場などなどの編集

↑以外は、普通にイベントが終了したときと同じようにやることができます。
以下の操作はイベント中止後も問題なくできます。

  • イベント関係者へのメッセージの送信
  • 申込者の管理(CSV出力など)
  • イベント統計の閲覧

今回中止を決定した後やったこと

  • connpassのイベントタイトルに【中止】と入れた
  • 参加者に中止連絡を送った(connpassの機能で)
  • Twitterで中止の拡散した
  • 参加者が10名程度だったので、connpassに連携しているアカウントを調べてDMした
  • 個別連絡できない人もいたので会場で待った
    → (結局誰も来なかったので良かった!)

おわりに

せっかく企画したイベント(勉強会)を中止するのは結構勇気がいると思います。
安全第一だと思うので、強行しない姿勢は大事と思います。

JaSST'19 Tohokuに参加してから3ヶ月経とうとしている #jassttohoku

この記事は?

2019/5/31に行われたJaSST'19 Tohokuに参加してきました。 本当は参加レポートを書こうと思ったんですが…タイミングを逃し(笑)
なのでこのブログでは、JaSST'19 Tohoku参加後、取り組んでいることを書きます。

イベント概要

開催日: 2019/05/31(金) jasst.jp www.aster.or.jp

リスク分析をチームで始めた

始めようと思ったきっかけ

www.slideshare.net

基調講演で株式会社Freeeの小山さんから「リスク分析」のお話がありました(講演資料P53 ~ P64)。
講演を聞く前までの自分の活動を振り返ってみると、これまで個人では、プロダクトリスクやプロジェクトリスクを自分の頭の中でなんとなく考えてはいました。
そしてその結果、なんとなくテストやる順番を変えたりもしていました。
チーム(テストチーム2名体制時)では、不安に思ったらその時会話 & 共有をしていました。
それはそれでとりあえず良かったんですが、個人のしかも頭の中でなんとなくやっても、何も残らないなぁと講演を聞いて改めて思いました。
せっかくならなにかやった結果残したほうがいいですし、頭の中から外へアウトプットすることでより整理できると思いますし。

なので、講演を聞いた後テストチーム(現在は3名体制)でリスク分析を時間を取って始めることにしました。

やり方

リスク分析のやり方(フォーマット)は小山さんの公開資料のものを参考に「リスクの分類(種類)」と「いつ起きるのか」を付け加えてみました。 残りの項目は丸パクリです(笑)。
小山さんの講演資料ではFreeeさんで使っているリスク分析のフォーマットを載せてくださっていたので、どうやるのか具体的にイメージしやすくとてもありがたかったです。
以下使っているフォーマットです。
テスト開始前にテストチームで集まって「なにか不安なことない?」と雑談しながら不安(リスク)をシートに書く → なんとなく発生確率と影響度を書いてみる → それぞれのリスクに対するアプローチを決める と言った流れで行っています。

f:id:yoshitake_1201:20190826095708p:plain

やってみた結果

チームでリスクを確実に共有できる時間がある、共有できる、というのがとても良いですね。
不安を共有する際、他のメンバーが同じことをあげると「やっぱりそこ不安だよね」とリスクに対する認識が強まりますし、違うことをあげると「あ、そこ気になるのか」と視野が広がりますし。
それから、ここであがったリスクに対策をしていたおかげで、実際にリスクが発生したときに、事なきを得たことがありました。
そういうわかりやすい結果が得られるとやっていていい感じがしてきますね。
今後も続けていこうと思います。

テスト技法練習帳やってる

f:id:yoshitake_1201:20190826095852j:plain

当日(以降も)話題になっていましたが、実行委員の方が「テスト技法の練習帳」を作り、参加者に配ってくださいました。
いろいろと裏話も聞いたのですが…半年以上かけてここまで作るとは…ありがたいかぎりです。

そしてせっかくもらった練習帳。
飾っておくにはもったいないので、ぼちぼちとやっています。
やってみると、なかなか難しいですね。
「自分ここまでわかってなかったのか〜」とちょっとショックでした。 問題には回答例も書かれているのですが、そこで自分と違う視点の答えがあるので良いですね。
よく考えさせられます。
問題の他に「ブレイクタイム」というTipsもあるのですが、「仕様書の記載にはテストに必要な情報が足りていない場合があります」(練習帳P27より)といった始まりから、具体的な例をあげて説明をしてくれているのもとても良いです。

テスト技法の勉強会やる

q-te.connpass.com

ワークショップでテスト技法を学び、改めて大事だなぁと思ったので勉強会をやることにしました。
自分の中でまとめてアウトプットしたいなぁとも思っていたので。

1回1テーマ、1 ~ 2ヶ月に1回ぐらいのペースで開催していけたらなぁと思っています。

当日を思い返して

濃い1日でしたね。
しかし基調講演、事例発表、ワークショップ、参加者の方との交流、どれをとっても良いことばかりでした。
講演者の方々、実行委員の方々、当日話してくれた参加者の方々、ありがとうございました。

テスト開始前に「テストの問診票」に答えてもらっている #テストラジオ #108回のネタ

twitcasting.tv

8/11(日)のテストラジオに出演したのですが、そこで自分がやっている「テストの問診票」という取り組みについて話をさせてもらいました。
このブログではそのテストの問診票について少し説明します。

テストの問診票とは?

Googleフォームのタイトルです。
私がプロジェクトに参加するタイミングは、テスト対象がほとんどできあがり、テスト実行を開始するちょっと前、ぐらいがほとんどです。
なので、テスト実行開始前(数日前 ~ 前日まで)には必ず、プロジェクトの背景や、開発したもの(テスト対象)などなど、テストに必要な情報を教えてもらうミーティングを開いてもらっています。
そのミーティングで話してもらう内容を事前にGoogleフォームに書いてもらっているのですが、このGoogleフォームのことを「テストの問診票」と呼んでいます。

なぜ作った?

上記のミーティングは30分 ~ 1時間で行っています。
一応質問リストを用意して、その場で聞いてはいたのですが、話が脱線したり、用意していた質問よりも気になることを聞いたりで、時間が過ぎていき、全部を聞けずということがしばしば(後から聞くんですけど…)。
また、その時初めて聞く話が多いので、思考や疑問が追いつかなかったりも…。
そしてそれを解決するためには、とりあえず事前に質問しておいたらいいのでは?と思い、今年の2月ぐらいからぼちぼちと始めてみました。

なんでGoogle フォーム?

答えるときに少し気分を変えてほしいなぁと思ったのがそもそもでした。
基本的にこの問診票は、開発者に答えてもらうのですが、開発中の思考から少し切り替えてもらえたら…と思ったんですよね。
そこから「業務中にGoogleフォームに答える」ってなかなかないよなぁ…と思ってとりあえずGoogle フォームにしてみました。

どんなことを質問している?

普段遣いのものから抜粋 & 質問文を少し変更したフォームの画像になります。
(フォーム自体はこちら

f:id:yoshitake_1201:20190825194709p:plain

質問の内容は大きく分類すると3つですかね。

  • 事務的なもの
  • プロジェクト全体に関わること
  • テストに関わること

それぞれの質問に一応意図があります。
テストラジオでも話していたんですが、「何件ぐらいバグが出そうか教えてください」という質問は、長期的にこの問診票を続けるといろいろ良い働きをしてくれるのでは…と思っています。

使い方

以下の流れで使っています

  1. テスト開始時期が近づく
  2. 開発者に問診票の回答URLを送る
  3. 開発者が回答する
  4. ↑の回答を参考にミーティングを行う

ちなみにですが、この問診票はあくまでも参考程度として使っています。
「このフォームにしっかりかっちり書かなければならない」というものではないです。
そういった意味を和らげたくて「問診票」という名前をつけました。 (すこし柔らかいニュアンスになりますよね)

やってみた感想

いい感じかなぁ〜と。
事前に情報をもらえるので、自分の中で情報を整理できますし。
そして個人的には、「バグ何件ぐらいでそう?」と「やらなくていいテストある?」という質問が良い働きをしているなぁと思います。
基本的に回答者の感覚で答えてもらっているので、数字や書き方などバラバラなのですが、「なんでその件数と思う?」「なんでそれやらなくていいの?」を聞くと、それぞれの考えや思いを知れるので。
そこで聞いた「なんで?」が割とテスト活動に生きている気がします。
まだ思いつきで始めた〜ぐらいの感じなので、今後続けてもうちょっと具体的に良い点、悪い点をブログに書こうと思っています。

問診票については なそさんもテストラジオでフィードバックや考えを話しているので、ぜひ108回目聞いてみてください(笑)

(おまけ)Slackに通知する

Googleフォームはスクリプト(Google App Script:通称GAS)を埋め込むことができます。
なので、フォームに回答して持ったときはSlackに通知するようにしています。
これがなかなかに便利です!

qiita.com

この方の記事がとてもわかりやすいので、ぜひ読んでみてください。
あと、自分もQiita書いてみたのでよければご参考ください。

qiita.com

SaPID Bootcamp2019.5 に参加して3ヶ月が経とうとしている #SaPID

この記事は?

2019/5/25 ~ 5/26に行われたSaPID BootCampの参加レポートです。 参加して3ヶ月ぐらい経とうとしてますが…(笑)
ただ3ヶ月たった今ふりかえってみると、やはり「参加してよかった」と思います。
なので自分のメモのためにも書きました。
ちなみにSaPIDとはなんぞや?的な詳細はこの記事では書いてません。
ポエムな記事です。

イベント概要

www.software-quasol.com

開催日: 2019/05/25(土) ~ 2019/05/26(日)
公式レポート

www.software-quasol.com

SaPIDとは?

問題解決・プロセス改善のための手法(フレームワーク)です。
以下、Software Quasolからの引用です。

”Systems analysis/Systems approach based Process Improvement methoD”の略語で、当事者自らが(最終的には仲間と共に)解決すべき問題点を特定し、現実的に解決、改善、そして革新を実現しながら段階的・継続的に自律運営へのゴールを目指す手法です。

SaPID → SaPID+→ SaPID3.0とアップデートされています。

SaPID Bootcampの内容

  • 1日目
    • SaPIDについてのガイダンス
    • STEP1:問題点洗い出し・引き出し
    • STEP2:事実確認・要素精査
  • 2日目
    • STEP3:問題分析・構造化
    • STEP4:改善ターゲット検討・特定
    • STEP5-1:改善対象の掘り下げ
    • STEP5-2:改善手段検討・決定
    • STEP6:改善目標の検討・決定

SaPIDは9つのステップに分けられているのですが、今回のBootcampでは、Step6の改善目標の検討までを対象としてワークショップが行われました。
(ちなみに、STEP7以降は以下の感じです。

  • STEP7: 改善計画立案
  • STEP8: 改善トライアルと評価・フィードバック
  • STEP9:全体適用→評価・ふりかえり&フィードバック

ちなみにSaPIDをやると以下のような問題構造図ができあがります。
見にくいですが、付箋が因果関係で結ばれています。
f:id:yoshitake_1201:20190819014300j:plain

なぜ参加しようと思ったのか?

私が「SaPID」というワードを知ったのは今から2年前の2017年6月でした。
たまたま…安達さんを紹介していただき、そこからSaPIDを知り、本を読んでみたのがきっかけです。
本の前半には「あるある」な現場の悩みが書かれていて、それを読んだときに納得感があったのを覚えています。
ただ当時は具体的な取り組み方はいまいちピンときてなかったのですが、本に書かれていた「最初は小さく速く改善のプロセスを回す」というのが自分に刺さり、それからSaPIDに少しずつのめり込んでいきました。
ただ、SaPIDの提唱されているフローを最初からやる機会や自分でやることがなかなかできなかったので、今回Bootcampに参加してみました。

  • SaPIDを手順通りにやってみたい
  • 今の自分の現場での悩みや問題を見える化したい

というのが大きな目的でした。

Bootcamp参加してみて

参加してよかった!というのがただただ正直な感想です。
Bootcampでは「自分が今現場で悩んでいること」を取り扱い、Bootcamp中に「自分が行う改善手段」を決めるので、現場に帰ってそのまま実践することができるのが良いですね。

またその「自分が悩んでいること」を考えている中、講師の安達さん、小楠さんからBootcamp中にいろいろと指摘をいただけるというのがさらに良いです。
なかなか自分の現場の悩みについて、指摘を頂く機会はないですから。
自分の出したカードや作った構造にぐさりとくる質問を投げかけてくれます。
とても頭を使いました。。。

もちろん、「SaPIDを手順通りにやってみたい」「今の自分の現場での悩みや問題を見える化したい」についても達成することができました。

Bootcampから現場に帰ってきて

戻ってきてすぐに(Bootcampの翌週に)社内のテストチームでとりあえずSaPIDやってみました!
今のチームメンバーは「私がこういうのやりたい!」というと、すっと協力してくれるので本当にありがたい限りです。

■ 社内に戻ってやってみてわかったこと
・自分はプレイヤー兼ファシリテーターは苦手
・取り扱う問題のスコープの大きさは本当に大事
・チームメンバー素敵
・SaPID面白い

これについては詳細な記事を別に書こうと思います。
Bootcampから戻ってきた翌週にSaPID試してみたんですが、自分が進行する側に回ると中々難しくてですね。。。
思い悩んでいたところSaPIDプレファシリテーターである @caori_tさんに会う機会があり、相談してみたところ、6月頭に九州員来られる用事があったので、そのついで来社していただきちょこっとファリテートしてもらうという、貴重な体験をしました!
その後の結果も踏まえて9月 ~ 10月ぐらいに詳細な記事をかけたらと思います。

3ヶ月(ぐらい)経った今思うこと

本当は参加後1週間以内にブログ書く予定だったんですけどね(笑)
まぁせっかくなので参加後3ヶ月経ってみての感想や経過を書こうと思います。

・参加したという結果だけが残っていないか?
Noです。
参加したこと、SaPIDのStep.6までを体験できたことで、日々の考え方や業務のアプローチが変わっていると実感しています。

何かしらかを聞いたり理解する時、頭の中で構造的に状況を把握できるようになってきた気がします。
また、人からある取り組みを聞いたときに「なぜやるの?」「それやったらどうなるの?」を自然に考え聞けるようになったと思います。

・SaPIDを実践できているか?
残念ながらNoです。 戻ってきてチームでやってみたんですが、取り扱ったスコープが大きすぎてですね。。。 そこで途中で終わってます。   ただ、その当時はチームができたてだったという事情もあり、「とりあえずチームでSaPIDしてみる」というミニマムな目標は達成できました。
今月8月にチーム再編が行われ、テストチームが正式に発足したので、そこでもう一度スコープを絞ってSaPIDをしてみようと思っています。
(これまではテストチームとして独立はしてなかったんですよね) ちなみに、チームでやってみたらこんな感じで…めっちゃでかくなってしまいました(笑)
スコープはしぼらないとですね。
f:id:yoshitake_1201:20190819014312j:plain

Bootcampに参加できたから、自分の中に「現状を構造化する」という感覚がかなり染み付いてきました。
整理しやすいのでかなり好きなアプローチです。
また、SaPIDには構造化だけでなく、構造化しやすくするためのアプローチ(テクニック)も盛り込まれているので、 日々の業務の中で「困っていること」がわかりやすく、また困っていることへの前後関係に気づきやすくなったと思っています。

正直あのタイミングで参加できて本当に良かったです。

一緒に参加して、意見や相談にのってくれた参加者の皆様、講師の安達さん、小楠さん、ありがとうございました!
日々色々取り組んで生かしていけたらと思います。