yoshitake_1201’s diary

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

デシジョンテーブルを使って仕様共有するための工夫

今年の1月からソフトウェアテスト技法練習帳にチームで取り組んでいます。
2月 ~ 3月にかけて第2章デシジョンテーブル編をやっていたのですが、ちょうどその期間に実業務でデシジョンテーブルを活かす機会がありました(↑のツイートはその時のもの) 。 自分が理解するためだけでなく、お客さんとの仕様確認でも使えるようにパッと見てわかりやすくなることを考えて作ったら意外と好評でした。
なのでこの記事ではその時期にしたポイントをまとめました。
下記の問題に対して、実際にデシジョンテーブルを書いて説明します。

・ 問題

あるショッピングサイトでは1回の購入金額や会員の種類に応じて割引を行っています。
以下に条件を書きます。
この条件と割引率を表すデシジョンテーブルを作成してください。

■ 条件
・ 会員について
 ・ 「会員種別」として「一般会員」と「有料会員」の2つがある
 ・ 会員には「会員区分」があり「なし」「個人」「小口」「大口」がある
 ・ 会員は「一般会員」「有料会員」どちらであっても、会員区分のいずれか1つを運営会社から指定される
・ 1回の購入金額に対する割引率
 ・ 「会員種別」に関係なく、1回の購入金額の合計が20,000円以上の場合は25%OFFになる
 ・ 「有料会員」は1回の購入金額の合計に関係なく15%OFFになる
 ・ 「有料会員」で「大口」の場合は30%OFFになる
・ 複数の割引率が同時に適応されることはない
・ 割引率が1番大きいものが適応される

・ 自分の解答

f:id:yoshitake_1201:20200516221417p:plain
表1

※ JIS X 0125「制限指定」との対応は以下のようになっています。
・Y: ○と表記している
・N: -と表記している
・X: ○と表記している

・ わかりやすくするためのポイント

以下の3つがわかりやすくするために自分が気をつけたポイントです。
① 「条件」と「結果」の並びのルールを合わせる
② 「結果」に条件を書く
③ 「条件」を全て書き出す

① 「条件」と「結果」の並びのルールを合わせる

f:id:yoshitake_1201:20200516221500p:plain

表1左側、条件と結果部分の順番についてです。
金額や年齢など、数字が出てきた場合は並び順を統一したほうが良さそうというものです。
「大→小」「小→大」が1つの表の中に混在すると、表を見るときに一手間増えると考えました。
例えば、条件: 「大→小」結果: 「小→大」という並びが混ざっていると、項目を探すときそれぞれどっちの順番か気にしちゃいますよね。
どちらかに揃っていれば気にしなくてよくなるので、条件と結果同じルールで書いたほうが見やすいかなぁと思いました。
ちなみに自分は「大→小」となるように書くことが多いです。

②「結果」に条件を書く

f:id:yoshitake_1201:20200516221525p:plain

結果にある(カッコ)の部分です。
ここに条件を書いておけば、テーブルを書くときは間違いに気づきやすくなる、テーブルを見るときは条件がパッとわかるかなと思って書きました。
表を作って時間が経った後、表を見返したときに役立つとも思います。

③ 「条件」を全て書き出す

自分の表は、「1列全てがハイフンにはならない」というのが特徴です。
JIS X 0125「制限指定」的にいうと「1列全てがNになる書き方をしない」になるのかな?
それぞれの条件内で最低でもどれか1つが○になるように条件を書き出してます(排他的論理は(EXOR)的なイメージ)。

f:id:yoshitake_1201:20200516221549p:plain
表2

比較対象として、この問題をJIS X 0125の「制限指定」で表してみました(表2)。
比較すると表1の方が行数が多くなっています(「会員の種類: 一般会員」「会員区分: なし」「購入金額: 20,000円未満」があるかないか)。
見た目の違いはそれぐらいですが、この2つの表の「N」の意味合いが微妙に違うと自分は感じています。

例えば「会員区分のN(表1では-)」について考えてみます(ややこしいのでここからはNとだけ表記します)。
表1、表2どちらも「N」には「その項目ではない」という意味があると思います。
ですが表2のNo.7, 8, 15, 16では「大口、小口、個人がすべてNだから、このパターンは会員区分: なしとなる」というように、全部が「N」であることにより新しい意味が生まれています(と自分は感じてます)。
表1の書き方では、1つの条件の中でどれか1つが必ず「Y」となるので、「N」の意味は「その項目ではない」の1つだけです。
このちょっとした違いが、パッと見のわかりやすさにつながっていると思います。

加えて表2単体では「一般会員」「会員区分なし」といったワードが出てきていません。
なので、この表だけを見たとき仕様がわからないかもなぁと思いました。
もちろん表2を書くときは、どこかにそのことを書くと思いますけどね。
条件の行に埋め込まれていたほうが見落としもないかなぁという所感です。

おわりに

今回業務で役に立ったシチュエーションは、お客さんと仕様の確認をするときでした。
複雑なことを共有するときは、文書より図や表のほうがわかりやすいことが多いと思います。
その表を読む全員が勘違いしないように、そしてできるだけ直感的にわかりやすくを目指したら表1のようになりました。
今回デシジョンテーブルを勉強しているときに、たまたま実務でも活かすことができてラッキーでした。

あと、テスト対象によってはこのルールを崩して書くときもあります。
テスト対象によっては並び方を変えたほうが読みやすいときもありますし。
自分の書き方だと行数増えちゃいますしね。
コンパクトにしたいときは向かないと思います。
状況に応じて、目的にあった1番良いものを書けるようになりたいですね。

他の人はどんなこと気にしながらデシジョンテーブルを書いてるんだろう?と気になりました。

参考にした資料

gihyo.jp

www.slideshare.net

ペアテストを1ヶ月間やり続けてみてよかったこと

この記事は?

2019年12月、ある案件でずっとペアテスト*1をやり続けてみました(経緯は割愛。たまたまが重なりました)。
結果、ペアテストはとても良いものであることを体験できたのでここに具体的に良かったことを書きます。

ペアテストを行ったテスト対象

あるCMSに3つの機能を追加することになり、その追加される機能のテストをペアテストしました。
1つの機能に対して、テスト実行、修正 、修正確認合わせて1週間かかりました。 追加される機能の詳細は以下です(※ 本筋とはほぼ関係ありません)。

・ CRUDを行うもの
・ 1つの機能に対してページが4つある(「一覧ページ」「登録ページ」「編集ページ」と「公開側のページ」)
・ 編集ページには登録したものを削除する「削除ボタン」がある
・ 登録ページ
 ・ 入力フォームが5 ~ 10個ほどある
 ・動的にフォームを増やす機能や画像などのファイルをアップロードする機能もある

やってみてよかったこと

以下の5つのよかったことがありました。

  1. 役割を分担できる
  2. 疑問をすぐに解決できる
  3. 良いテストを思いつきやすい
  4. サボれない(ちゃんとやる)
  5. サボれる(やりすぎない)

それぞれの補足を以下に書きます。

① 役割を分担できる

  • 1人: テストし続けることができる
    • 思考が途切れない
  • 1人: チケット登録を次々できる
    • チケットを書き終わったあともテストの思考に戻りやすい
      └ 隣にテストモードの人がいるから
    • チケットを書いている間も、テストの状況を知れる
      └ 何かあったら「ん?」「あれ?」と隣で言うから
    • 少しだけテストモードじゃないから、ちょっとだけ外の視点から意見できる

② 疑問をすぐに解決できる

  • 複数のテストパターンを思いついたら分担できる
    • 1人でやってると時間がかかるけど2人で同時に試せるので速い
    • 短い時間と手数で確認できるから、もっと他のテストができる
  • わからないことがあったらすぐ聞ける
    • どっちかが知ってればすぐ解決できる
    • どっちも知らなければすぐ他の人に聞ける

③ 良いテストを思いつきやすい

  • 操作や動作結果に対して、ディスカッションしながらテストができる
  • 1人だったら思いつかないことが、その場ですぐ思いつきやすい

④ サボれない(ちゃんとやる)

  • 「このパターン気になるけど…時間も微妙だし明日でいいよね?」
    • 「だめです」と注意され逃げられない

⑤ サボれる(やりすぎない)

  • やりすぎそうなときはやらない
    • 細かすぎるパターンをやろうとすると「それいる?」と注意される
  • やりすぎる前にちゃんと休憩できる
    • 「ここまでやってしまおう」と無理しようとすると、そういうときはお互いに注意される

おわりに

ペアテストは、テスト状況や認識を常に合わせることができとても良いなぁと思います。 短い時間に集中してやることはたまにあったんですが、基本的にペアテストをし続ける、というのはなかなかおもしろい体験でした。

でもペアテストやるととても疲れますね。 1人でやるときとは違う疲れ方をする気がします。 考えてることや考え方がいつもと違うんでしょうね。  

*1:このブログでは「2人で1つの画面を見ながらテスト実行すること」ぐらいの意味です

「ー」をF8キーで変換するとWindowsでは「-」Macでは「ー」になる

この記事は

「ー」をF8キーで変換するとWindowsでは「-」Macでは「ー」になるということを調べた記事です。
もうちょっと読みやすく書きます。
「全角ハイフン」をF8キーで半角カナに変換すると、Windowsでは「半角ハイフン」、Macでは「半角ハイフンではない半角カナのハイフン」になるということを調べた記事です。

-ー----
↑のハイフンたちは左から以下の順で並んでいます。

・Mac: 直接入力した半角ハイフン  
・Mac: F8で変換した半角カナのハイフン  
・Mac: F10で変換した半角ハイフン  
・Windows: 直接入力した半角ハイフン  
・Windows: F8で変換した半角ハイフン  
・Windows: F10で変換した半角ハイフン  
※ F10キーで変換した場合は、どちらのOSでも「半角ハイフン」になります。  
※ Mac:F8以外のハイフンはすべて同じハイフンです。

ファンクションキーによる全角/半角の変換

好みにもよりますが「ファンクションキーによる全角/半角の変換」を使う方は多いと思います。
エクセルやワードなど、日本語を入力する作業が多い業務の方ほど使う割合が多い、というのが個人的な印象です。

ファンクションキーによる変換は、F6 ~ F10に割り当てれています。
全角入力中にF6 ~ F10を押すとそれぞれ以下のように変換されます。

・F6: 全角ひらがな
・F7: 全角カタカナ
・F8: 半角カタカナ
・F9: 全角英数字
・F10:半角英数字

Mac: F8キーで「-」ではなく「ー」になると気づいた経緯

「半角ハイフンが許可されているはずなのに、入力するとエラーになる」
こんな報告をもらったのがきっかけでした。

以下報告をもらってからのなんとなくの流れです。

1. みんなで確認したけど再現しなかった
2. 再現した手順を聞いたところ「F8キーで変換している」ということがわかった
3. Macで確認すると再現した
----
4. 後日、↑のことをチームメンバーのK氏に共有した(K氏は当時別の案件をやっていた)
5. K氏:「その変換、私ならF10でやるけどなぁ」と指摘した
6. 吉武のMacでF10キーで変換すると、半角ハイフンになったことを確認した
7. WindowsでF8キー、F10キーで確認すると、どちらも半角ハイフンに変換された

このような流れがあり、最終的に以下のことがわかりました。

----オチ(それぞれのOSの仕様)----
・Macで全角ハイフンをF8キーで変換する      → ー (半角ハイフンではない)
・Macで全角ハイフンをF10キーで変換する     → - (半角ハイフン)
・Windowsで全角ハイフンをF8キーで変換する  → - (半角ハイフン)
・Windowsで全角ハイフンをF10キーで変換する → - (半角ハイフン)
----------------------------

おわりに

私は「ファンクションキーの変換機能は使わない派」だったので、そもそもこの事象の再現方法に気づけませんでした。
経緯の3番(再現手順)がわかったときに「これが原因ならこれまでにもっとこのバグに出会ってそうだけどな〜」と疑問を持ってました。
そこですぐに調査しなかったのは反省ポイントです(やらなかった理由は割愛)。
でも、その後いろいろと知ることができたのでよかったと思っています。
みんなに感謝でした(実はこの流れは自分たちも含めて10人ぐらい関わっている)。

この現象は「普段やらない操作」と「先入観/思い込み」がかなり関わっていたので、自分個人では見つけられなかった自信があります。
こういうのは個人の特性で、自分ではなかなか気づけないかなぁと思います。
最近気づくようになったと思ったけどまだまだでした。
せっかく気づいた(気づけた)ので、この体験と思考を大事にします。

おまけ

IMEやOSのバージョン絡んでるのでは?と以下を試しましたが、どの条件でもMacのF8だけが特殊な動作でした。
 └ 確認したIME: MS標準、Mac標準、Goggle日本語入力, ATOK
 └ 確認したOS: Windows10, Windows7, macOS Catalina, macOS High Sierra
MacのF8で変換した「ー」の文字コードを調べてみると、Shift-JIS 1バイトコードのB0になっていました。
画像は http://charset.7jp.net/sjis.html さんのものをお借りしました。
f:id:yoshitake_1201:20200128234306p:plain

テスト観点の共有会はとてもたのしい #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した
  • 個別連絡できない人もいたので会場で待った
    → (結局誰も来なかったので良かった!)

おわりに

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