第141回テストラジオ(2020/9/27)を聞くとき用のサポートブログ #テストラジオ

testradio.fm

twitcasting.tv

第141回テストラジオで以下2つの話をしました。
・「第◯月曜と△週目の月曜日の違い」
・「グラフを描画するシステムで遭遇したバグ」
ですが、どちらの話も「画像を見ながらじゃないと絶対伝わらない！」と思ったので、とりあえずの解説画像を作成しました。
第141回のテストラジオを聴くときはぜひ以下の画像を眺めながら聴いてください。
※ ラジオの内容をまとめたブログは別で書く予定です。
※ このブログはあくまで第141回テストラジオを聞く時のサポート用です。

■ 第◯月曜と△週目の月曜日の違いの話

竹屋さん(@takeya0x86)が情報をくれたのでその話をもとになそさんとお話しました。
手元にカレンダーを用意して聴いてもらえると、わかりやすいと思います。

・竹屋さんの話

月が変わったから見つかったバグは昔遭遇した事があって、「第○月曜日」と「第△週目の月曜日」の違いで発生するやつだった。コード書いたのがたまたま日曜日始まりの月だったから気づかなかったというやつ。 https://t.co/0fQEWGNoP1

— 竹屋 (@takeya0x86) 2020年9月21日

「9月の第3月曜日」を選択したのに9/21じゃなくて9/14（9月3週目の月曜日）になってしまったというやつでした #テストラジオ

— 竹屋 (@takeya0x86) 2020年9月21日

・竹屋さんの話からの雑談

---

■ グラフを描画するシステムで遭遇したバグ

最近自分が遭遇した、グラフを描画するシステムのバグについてなそさんと話しました。
miwaさん(@miwa719が気にかけていた「元のロジックを期待しているところが心配になる」を地で行く現象でした。

9月にテストしたから見つかったバグの話、面白かったです。10月にテストしたら別の問題が出るのかな？と思いながら聴きました。元のロジックを期待して使ってるところがないのか心配になる（他の機能がうまく動かなくなるのを想像した）ので、バグを直すときプログラマーに質問しそうです。 https://t.co/OJlXEsBepJ

— miwa (@miwa719) 2020年9月14日

・変更前/変更後の仕様

---

・元からある「値の補正機能」

---

・起きた不具合

---

・その原因

---

第139回テストラジオ: 8月にテストしたら見つからないけど9月にテストしたら見つかるバグ #テストラジオ

testradio.fm
twitcasting.tv

第139回テストラジオ(2020/9/13放送分)で「8月にテストしたら見つからないけど9月にテストしたら見つかるバグ」という話をしました。
せっかくの良い体験だったのでブログでも紹介します。
※ システムの詳細やロジックについて、少し脚色しています。

■ 前提

ラジオと同様にこのブログでもクイズっぽく紹介します。
どんなバグが出たのか、どんなバグが出そうか、どんなテストをするか、ぜひ考えてみてからブログを読み進めてください。

• システムの概要
  • ブログのような記事を書くWebシステム
  • アクセス数のランキングを表示するページがある
  • ランキングについて
    • 「先月公開された記事」が対象
    • 「先月のアクセス」が対象(今月のアクセスは対象外)
    • アクセス数の合計が多い順に3位まで表示される
    • ランキングには、順位、記事のタイトル、アクセス数の合計、が表示される
    • 月初め(1日)にランキングを作成するプログラムが実行される
    • 先月の記事が3件未満の場合、表示されるランキング数が減る
      (なし、1位のみ、2位までの表示になる)

---

■ 遭遇した現象

正解は「8月31日に作成した記事がランキングに表示されない」というものでした。
なぜこのバグが起きたのか簡単に解説しますね。

ランキングを表示するためのロジックはざっくりと以下の流れになっていました。

1. 先月の最終日を取得する
2. 取得した日に該当する、先月の記事を抽出する
3. 先月の記事へのアクセス数を取得する
4. アクセス数の上位3つを抽出する

この流れの中で「1. 先月の最終日を取得する」という動作になっているはずの部分が「当月の最終日を取得する」となっていたそうです。
しかし、その後実行される「2. 取得した日に該当する、先月の記事を抽出する」は正しく動いていました。
なのでこのプログラムを9月に実行すると、
・Step.1で「30」が取得される
・Step.2で「8月30日までの記事」が対象となる
・結果: 31日の記事が対象にならなかった。
というわけです。

もしこのテストを8月に行った場合、8月の最終日は31日で7月の最終日も31日のため、同じテストではこのバグを見つけることは難しかったと考えます。
ですが、このバグを知る前でも、2月やうるう年は気にするので「2月のテストがしたいです」と相談して、環境を用意してもらってテストをしたときに見つけれただろうなぁと思います。

■ このバグを見つけたときの話

ラジオの中で自分は「とりあえず7/31、8/1、8/31、9/1の記事を作ってテストした」という発言をしています。
これはテスト技法「境界値分析」を使ったアプローチですね。
それぞれ以下を狙ってテストデータを作りました。

• 7/31: ランキングに表示されない
• 8/1: ランキングに表示される
• 8/31: ランキングに表示される
• 9/1: ランキングに表示されない

このテストをしたら「8/31が表示されない」という結果を得たので、追加で以下の以下のテストデータを作ってテストをしました。
中央値や境界値3つ考えるというのを意識したデータですね。

• 8/2: ランキングに表示される
• 8/15: ランキングに表示される
• 8/30: ランキングに表示される
• 2019/8/15: ランキングに表示されない
• 2021/8/15: ランキングに表示されない

この5つをやった結果、期待どおりの動作結果になりました。
このことから自分は「ランキングが1 ~ 30日が表示される実装になっている」と推測して 「31日の記事がランキングに出ないバグ」と報告しました。
推測は原因と近かったですが、想像外だったので原因を知った瞬間「なるほど〜〜〜〜」とテンションがあがりました（笑）

■ おわりに

蓋を開けてみるとシンプルな不具合でした。
でもこんな形でクイズ形式で出されると戸惑っいますよね。
なそさんもラジオのときは大変そうでした（笑）

ぱいんさん(@pineapplecandy)はピンときてたみたいですね。
さすがです！
自分も次からはピンと来ると思います。

8月で起きず、9月で起きるでピンときた😊システム時間いじるのは手間ですからねえ。避けがちですな。そこから、プラグイン作ろうまで持ってったのはよしぺんさんとこは良い組織だなあ #テストラジオ https://t.co/mdQC6cbANm

— ぱいん🍍 (@pineapplecandy) 2020年9月17日

「日付」を取り扱うときは、自分がプログラムを書くときも、テストをするときも苦手意識があります。
特に日付をずらしてテストしないといけない場合などはテストしづらいことが多いですしね。
でも苦手と感じるからこそそこに不具合が潜んでいることが多いのでテストしていくべきだなぁと思います。
今回のでまた日付について学べたのでよかったです。

さて、この不具合の話、実は続きました。
続いたと言ってもこれまで話してきたプロジェクトで何かがあったわけではなく、「日付に関わる現象」に他にも遭遇したという感じです。
この件について第141回テストラジオで紹介します。
また、「8月にテストしたら〜」の回に頂いた反応についても話していますので、ぜひ聴いてもらえると幸いです。

2020/09/27 20:30ぐらいからツイキャスで放送される予定なので、よろしくお願いします。
Naso@SatoHiroyuki (@hiroyuki3gou) 's Live - TwitCasting

■ (余談①)ラジオでは言わなかったもう1つのバグ

「31日の記事がランキングに表示されないバグ」についてこれまで書いてきましたが、実はもう1つ似たようなバグがありました。
実は「31日のアクセスがランキングに集計されない」というバグにも出会ってたんですよね。
このブログ「システムの概要」にある『「先月のアクセス」が対象(今月のアクセスは対象外) 』という部分です。
例えば「8月30日の記事」に対して「8月30日にアクセスが5回」と「8月31日にアクセスが3回」あったとしても、「8月30日の記事のアクセスは5回となる」という現象です(本当ならアクセス数は8回となる)。

これも先程紹介した記事の集計ロジックと同じような処理をしていたのが原因だったようです。
この現象に遭遇した当時「31日だけなんでだろう？不遇でかわいそうに」と思いながらバグ報告をしました。

この不具合、気になっている方もいたんじゃないかなぁと思っています。

■ (余談②)ラジオの中で使った「スモークテスト」

スモークテストは自分のチームでは「テスト初期にとりあえず動いているか(基本動作ができるか)確認するテスト」という意味合いで使っています。
登録画面だったら「登録できるか？」、メールを送信する機能がだったら「メールが送信できるか？」を確認するといったことをしています。
ちなみにJSTQBでは以下のように定義されています。

定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。

https://glossary.istqb.org/jp/search/%E3%82%B9%E3%83%A2%E3%83%BC%E3%82%AF%E3%83%86%E3%82%B9%E3%83%88

■ (余談③)2、4、6、9、11月に見つかる

このバグ、9月だけじゃなくて2、4、6、9、11月に見つかるバグなんですよね。
この5つの月は31日がないので。
ラジオの中でなそさんが「西向く侍か！」と言ってましたが、「31日がない月」の覚え方として有名みたいです。
自分はこの覚え方は知らなかった。。。

ラジオの中ではカットされてしまったんですが、自分は↓の記事で紹介されている「じゃんけんのグー・げんこつでの覚え方」で覚えてました。
みんないろいろと覚え方を考えるんですね。

netwadai.com

■ 参考: 中央値や境界値3つを考えるについて

以下の資料を参考にしています。
・「ワークを通してじっくり考える同値分割＆境界値分析」井芹久美子さん
http://jasst.jp/symposium/jasst18kyushu/pdf/S1.pdf

zoom: 参加者の画面共有をDefaultで許可する方法

zoomのミーティングのデフォルト設定方法を探して迷ったのでメモ。
このリンクからできる。
https://us02web.zoom.us/profile/setting?mid=&from=client&&tab=meeting

※ 設定方法

1. ↑のリンクを開く
2. 「ミーティングタブ」を開く
3. 「ミーティングにて(基本)」内の「画面共有」のトグルをONにする

---

※ アプリから表示する方法

1. 「設定」を開く
2. 「一般」内の「さらに設定を表示する」をクリックする

---

zoomの設定はクライアントアプリ上でできるものとWeb上じゃないとできないものがあるという備忘録。
全部クライアントアプリ上でできると便利だなぁ…

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

仕様の整理や共有にデシジョンテーブルが役に立ちまくっている。やっててよかった！
ソフトウェアテスト練習帳 にとても感謝。

— yoshitake (@yoshitake_1201) 2020年3月17日

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

・ 問題

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

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

・ 自分の解答

表1

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

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

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

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

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

②「結果」に条件を書く

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

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

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

表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

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

テスト設計技法の適用・・・その前に from kauji0522

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 さんのものをお借りしました。

テスト観点の共有会はとてもたのしい #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. 参加者全員の納得が得られればテストデータ出し終了

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

■ ②が終わったタイミング

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

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

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

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

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

やってよかったこと

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

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

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

おわりに

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

speakerdeck.com

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

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

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

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