2020/10/3 JaSST Online Bergamot に参加した感想 #JaSSTOnline

■ この記事

2020/10/4に行われたJaSST Online Bergamot に参加したときのメモ & 感想です。
うろ覚えなので、何か間違ったことが書かれているかもしれません。
その時はごめんなさい。

jasst.jp

■ S1: 「探索的テストセッション」の内容

• セッションの流れ
  • 「LIFULLさんの新人研修用システム(SNSっぽいサービス)」をnemorineさんが1時間探索的テストをした動画を流す
  • その動画をみんなで見る
  • 実行委員 & 質問者(3人)が気になったタイミングで動画を止めて質問をする
    • 動画の止めた方は早押しボタンを押す
  • nemorineさんが回答する
  • セッションの時間は2時間(前半1時間、休憩5分、後半1時間)
    → 動画が30分ぐらいたったところでちょうど1時間ぐらい
    → 残り30分も後半1時間(プラスちょっと)で終わった
• nemorineさんがテストしたときのメタ情報
  • チャーターは用意していない
  • 仕様書は読み込んでいない(3分ぐらい読んだ状態)
    ※ 仕様書に引っ張られず初見の状態でやりたかった(と言われてた気がする)
  • テスト始める前の予定は「学習30分、探索30分」
  • 実際には学習に40~45分ぐらいかかってた
    ※ここでいう学習を「システムの全体像を知る、出来具合を感じる」という意味合いに感じた(よしたけの感想)
  • nemorineさんはこの動画では操作や感想を喋りながらテストをしていたが、普段はここまでの発話はしていない

■ セッション中のうろおぼえメモ(カッコ内敬称略)

・ 個人的にナイスと思った質問

• 「20分ぐらい触ったときどんな気持ちになってましたか？」
  • 「1時間で動画を取り終わらないといけないけど、意外と時間がかかって焦ってきてました」
• 「既存のサービスにすごくにてるシステムと思うですけど、他のサービスと比較しながらテストしてますか？」
  • 「そうですね。比較できるサービスは比較しながらテストしてます」
• 「探索的テストしているときにビジネスとして成功するかも見てますか？」
  • 「普段は見ないです」
  • nemorineさんのお仕事的にはその観点は難しいらしい
• 「削除したときの動作で『まぁ良いか』って言ってましたが、なんで『良いか』と思ったんですか？」
  • 「気になったけどスルーしちゃってた、削除はずっと気になってたけど…」
  • 触った感じ結構バグが出てたから、動画の時間を考えて少し浅めにテストしようとしてた(OSTでnemorineさんが教えてくれました)

・ 良いなぁと思ったフレーズ

• 「最初に動かすときは普通のユーザーが動かす形で通したい」(nemorine)
• 「なるべく初見の状態でシステムと対話しながらやっていきたい」(nemorine)
  • 今回探索的テストしたときに話されていたときの発言(だったと思う)
  • チャーターがあれば探索的テストというわけではなくて、システムの動きを見ながらやっていくのが探索的テストと考えている(nemorine)
• 「仕様書が怪しくなってくる」(nemorine)
  • 数字の境界値？が仕様書と実装で違ったときに言われていた
  • 「ただの独立したバグ」と捉えずに「このレベルで、仕様書と実装で齟齬がある」という事象(？)として捉えた印象を受けた(←よしたけの感想)
• 「操作を間違えた現象は大事」(miwa)
• 「その瞬間しか再現しないバグもある(時間が経ったら再現しなくなるバグもある)」(miwa)
  • バグが起きたとき(& 再現方法がわからないとき)にどうする？っていう質問の流れだったと思う
  • だからそんなときはすぐに開発者(プログラマー)を呼んでログを見てもらっている(miwa)
• 「探索的迷子」
  • nemorineさんが学習し終わってぐらいのタイミングでどこを(なにを？)テストしているかわからなくなったときにmiwaさんが言った発言(だったはず)
  • miwaさんが言ったわけではなくて、miwaさんの「迷子」というフレーズを拾ったコメントだったかもしれない
  • 「nemorineさんの頭の中にはシステム(or テスト)の全体像みたいなものができあがって、終わったところがわかっている状態なのかな？」っていった感じの質問も印象的だった
• 「仕様書を見ると仕様にひっぱられる」&「仕様書も疑って良いんだよ」
  • nemorineさんが仕様書を見ないようにしてたのに対するのmiwaさんの発言
• 「自分も信じられないんだよ」
  • 仕様書も疑って良いんだよ〜のくだりでmiwaさんが言っていた発言

・ 探索的テストをやるタイミングについてのメモ

けっこうバグが出ていたので、この状態で探索的テストするのか？といったコメントやちょっとしたディスカッションがあったのでそのメモ

• 対応について
  • この状態なら先に「スクリプトテストを通す」(nemorine)
  • ここでいう「スクリプトテスト」は「テストケース/テスト項目所/チェックリスト」といった仕様書と照らし合わせる意味合いのものと思う
  • もし複数人でテストできるなら1人はスクリプトテスト、もう1人は探索的テストといったアプローチをする(nemorine/OTSでの回答)
  • 開発者に差し戻す(講演中に流れたコメント)
• バグが多い状態での探索的テスト
  • バグが出すぎると探索まで行きつかないので、まだ早い
  • 探索的テストは思考(対話)を継続させるのが大事なので、バグが出すぎるとそっちに気を取られてなかなか難しい

■ 自分たちのチームだったらどうするか？

nemorineさんの今回のアプローチは、「1つの機能を深く」よりも「多くの機能を広く浅く」といった視点だなぁ感じました(もちろんシステムのメイン機能を優先されていました)。 おそらく「動画時間(1時間)という制約」「けっこうバグが多かった」というのを気にされていたんだろうなぁと思いました。 講演中も「この状態なら一旦スクリプトテストにかける」って言われていましたし。自分も「探索的テストにはまだ早い」という印象でした。

コメントでも「この状態なら開発に差し戻す」というのが流れていました。 そのアプローチができるのははとても素敵だなぁと思うんですが、自分たちのチームで考えてみると、この状態でテストを継続することが多々あるなぁと思いました(理由はこのブログでは割愛)。 せっかくなので自分たちのアプローチを少し書きます。

こういった状態でのアプローチは「目についたバグはすべてIssue登録(チケット登録/バグ票登録)してしまう」といった方針が多いです。 ですがこのアプローチは1人でやるととても大変です。 大変なポイントはいくつかありますが、自分が考える1番大変なことは「テスト実行の思考」と「Issue登録」で頭の切り替えが発生することだと思います。 バグバグしている状態でテストをすると切り替えが頻発するので、なかなかに大変なことだと思います。

なので、自分たちが今回のような状態のシステムを探索的テストをするときは、チームメンバーのsaeさんとペアテストという方法をとります。 役割分担はsaeさんが「テスト実行」自分が「バグを登録する」という感じです。 こうするとsaeさんは思考を継続した状態で深くテスト実行に向かいやすくなるし、見つけたバグも同時にIssue登録できるので、2人で別々にテストするよりも格段に良いと自分は感じています。 ペアテストをするときは、隣りあって話しながらテストするので、情報共有も楽ですし。

↑だけ読むと「自分はバグ登録だけしている」と思う方もいるかもしれませんが、そんなことはないです。 自分はバグ登録に集中しているわけではなくて「Issueを登録しつつ、少し離れた視点でシステムを学習している」状態になっています。 なので、saeさんの情報や出ているバグから気になることがあると「あ、〇〇も試してほしい」とか「こうしたらどうなる？」といった感じで自分が気になるテストをsaeさんにやってもらいます(「それ今やってる」って返ってくるときもよくあります)。 また、何かよくわからない現象(例えば、nemorineさんのセッションだと一覧がループ表示になったとき)とかは、自分もバグ登録の手を止めて、そのバグの原因を探すべく2人で深くテストをします。 バグ登録する側も学習しつつ状況に応じてテスト実行に加勢するという感じです。

こうすることで、先にあげた「思考の切り替え」が1人でやるときよりも小規模になり、また思考の手助けがほしいときはすぐに増員できるので、1人よりもだいぶ楽にそしてたくさんの学習をしながらテストをすることができているなぁと思いました(とはいえ、全く疲れないなんてことはなくて、ペアテストが終わった後はお互いに疲弊しています) 。 探索的テストは本当に頭を使うので、今回のnemorineさんは1人でしかも発話もしながらと本当にすごいかったです。

余談ですが、今回↑の文章を書いているときに「深い視点で考える」saeさんと「浅い視点で考える」自分とで、2つのアプローチを同時に行えていることに、改めて気づきました。 良い機会となりました。

※ (参考)以前ペアテストについて書いたブログ
ペアテストを1ヶ月間やり続けてみてよかったこと - yoshitake_1201’s diary

■ 質問者として参加した感想

• 早押しボタンのおかげで動画を止めやすかった
  • はい！って声を出すよりも動画を止めやすかった(音のせいにできる)
• ボタンの音が配信に載っているのが良かった
  • ボタンを押したことが全体に伝わる
  • ボタンに不具合があったら質問者にもそのことが伝わる
• 他の方の質問にのっかりやすいのも良かった
• 質問のあとに実行委員長が補足質問をしてくれることが多かった
  • おかげで質問しやすかった
  • 変なこと言っても救ってくれる安心感がありました
  • ありがとうございました
• コメントスクリーンで質問が流れるので、その質問を選択することもできる
  • 別画面に質問があっても、それを見るのは難しいだろうなぁと思ったので、この機能はとても良かった

■ 全体の感想

• nemorineさんが何を気にしているのか(視線/視野？)が、録画越しでもなんとなくわかった
  • ここにバグがあるけど、nemorineさん今は気づいてないかも、っていうのをなんとなく感じた
  • 自分もこう言う感じなんだろうなぁと思った
• 以下を同時にやっているnemorineさんとてもすごい
  • 収録中: 思考を維持しつつ、バグのメモとりつつ、気になったことを発話
  • 講演中: 当時を思い出しながらの質疑応答
• 探索的テストはとても頭を使う(ものだと思う)ので、本当にすごいなぁと思った
  その上わかりやすいし…すごかった。講演中の動画がもう1回みたい
• コメントスクリーンが良かった
  • 参加者のコメントがコメントスクリーンで配信映像に乗るのでおもしろかった
  • コメントに書かれている観点についても、色々考えることができたので良かった
• 質問が良い感じの休憩になっていた
  • ずっと見続けてしまうと自分は本当に疲れてしまうのでありがたかった

---

「実験的な試み」と会の始めに言われていたけど、コメントスクリーンや質問者オプションはとても考えられていて素敵だなぁと思いました。質問者も三者三様の質問だったので面白かったです。miwaさん、かみむらさんの質問の観点素敵でした。勉強になりました。

人がテストしているのに対して何も言わずに見るという経験がなかったので、とても新鮮でした。人がテストしていたらその場で話しちゃうし。考えてみたら「自分がテストしている」のを見ることもないですね。今度やってみようと思いました。1時間は大変なので30分ぐらい。

参加できてよかったです。ありがとうございました。

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