QAエンジニア教育用ボドゲ第2弾 バグラビリンス 原案

どうも、FF7のリメイクが待ち遠しいオムそばです。
体験版はパーフェクトな完成度でした。

さて、今回は、"その言葉、なんですか？"に次ぐ、QAエンジニア教育用ボードゲーム、その名も"バグラビリンス"について原案がまとまったので書いていきたいと思います。 

■どんなゲーム？

不具合がいくつも存在する未完成の迷路を、不具合を改修していきながら制限時間内に完成させる、協力型のゲームです。
プレイヤーは迷路の管理者1名と、探索者複数名に分かれてゲームをしていきます。
探索者は、迷路のスタートからゴールに辿り着くための道のりをチェックし、それができない場合は、明確な理由を添えて管理者にインシデントレポートをあげます。

※細い線は通れて、太い線は通れません。

インシデントレポートは、例えば「F2 の床色が黄色のため、初期状態では先に進めなくなる」のような形で指摘します。
管理者はその指摘を受けて、不具合か仕様かを判定し、不具合であれば改修点を明示します。
なお、管理者側は不具合の箇所が書かれた答えの情報を所持しており、インシデントレポートがそれに合致しない場合は「仕様です」と答えることとします。

管理者が持つ回答。これは管理者だけが見てよい。

制限時間内に「終」まで辿り着ければ迷路製作成功となり、辿り着けなければ迷路製作失敗となります。
ゲーム終了後、振り返りを行い、どんな不具合があったか、どんなインシデントレポートが良くて、どんなインシデントレポートに改善すべき点があったか、プレイヤー全員で話し合います。

■教育的効果

本ゲームは、迷路の管理者を"開発者 兼 PM"、探索者を"テスト担当者"として見立てています。
本ゲームをプレイすることで、以下の効果が得られることを期待しています。

• テスト対象に対する視野を広げ、視座を多く持ち、視点を鋭くする
• 簡潔で具体的なインシデントレポートをあげられる
• 様々な不具合のパターンを知る

■今後の展望

迷路は全部で5個くらいを想定しており、その中で、異なる仕様をいくつか用意しようと考えています(同じ迷路でも、最終的な形が異なる場合がある)。
また、迷路のギミックも、"自動的に矢印の方向に進まなければならない床"や、"一定数以上○を所持していないと通過できない壁"、"左に曲がれないステージ"など、色んな要素を盛り込む予定です。
さらに、探索者の手助け要素として、シミュレーターを用意する予定です。シミュレーターは、迷路を進める間、現在スイッチがどの状態にあるか、○をいくつ所持しているかなどを視覚化することができます。

今のところ、2020年冬頃を目標に製作を進めております。
値段は、3,000〜4,000円くらいになると予想しています。

お楽しみに！

サンタさんからの早めのクリスマスプレゼント(難解なインシデント)

この記事は、ソフトウェアテスト Advent Calendar 2019 - Qiita 11日目の記事です。
前の方(yuki_shiro_823さん)の記事はこちら。

yuki-shiro.hatenablog.com

どうも、マックスレイドバトルを楽しんでいるオムそばです。
キョダイマックスの姿はメガ盛りのオムそばになります。

今回は、昨日の朝までは、QaTANや"その言葉、なんですか？"についての記事を書こうと思っていたのですが、サンタさんから早めのクリスマスプレゼントとして、難解なインシデントをいただいたので、急遽そちらに記事を変更することにしました。

■事象(何が起きたのか？)

弊社、メーラはOffice365のOutlookを使っています。
その弊社宛に、パートナーからメールが届きました。
内容は何のことはない、普通のメールなのですが、どうも最後の文章がおかしい。
それがこちら。

-----------------------------------------------------

-----------------------------------------------------

御覧のように、「し」と「く」の間に、URLらしきものが埋め込まれているのだ。
これについてパートナーに問い合わせたところ、不思議な回答が。

パートナー「いや、別にこっちで見ると普通だけど？」

？？？

いやどう見てもおかしい。
と思ったが、すぐさまパートナーからキャプチャが送られてきて、確かにそれを見ると、「よろしくお願いします。」と書いてある。URLは埋め込まれていない。

さらに混乱することに、Outlookでも、メールの一覧表示では、普通に表示されるのだ。

-----------------------------------

-----------------------------------

その後、色々と調べてみると、以下のような事実がわかった。

• 送信元はGmail
• なぜか「し」と「く」の間に見えないハイパーリンクが埋め込まれていた。
• ソースは以下のような形になっていた。
  

  <div>以上、よろし<span></span><a href="http:///" target="_blank"></a><span></span>くお願いします。</div>

■結末

解析を進めた結果、本件はGmailで特殊な操作をすると起きる事象であることがわかった。
手順としては以下の通り。

1. Gmailの本文に、適当なハイパーリンクを作成する
2. そのハイパーリンクの文字列を全文カットする(backspace等で削除してはだめ)
3. カットした状態でメールを送信する

正確には、手順2の時点で、すでに事象が発生している。(見えないハイパーリンクが埋め込まれている)
どうやら、Gmailは、カットした際に、文字列とリンクを完全に削除するわけでなく、リンクの残骸が残るようだ。

<a href="http://xxx">ほげほげ</a>

となっているところを、カットした際に、「ほげほげ」の部分だけ抜き出してしまっていると。そうすると、以下のような残骸が残る。

<a href="http://xxx"></a>

※見た目上は何もない。
Office365で同様の手順を実施してみたが、再現しなかった。
マイクロソフトは削除と同じ動きになっているようだ。

久々に、見たこともない事象にぶち当たり、興奮しながら事象の切り分けをしていった結果、こんな時間になってしまった。

さて...この事象、これはGoogleに報告すべきなんだろうか？

テスト実行者に注意してほしい点

この記事は、ソフトウェアテストの小ネタ Advent Calender 2019 4日目の記事です。
前の方(ブロッコリーさん)の記事はこちら。

nihonbuson.hatenadiary.jp

どうも、ポケモンのソードを買って3歳の娘とプレイ中のオムそばです。
主人公の服装や、ポケモンのニックネームなど全て娘に決めてもらってます。
最初のポケモン「ヒバニー」のニックネームは"うさぎ"になりました。

今回はテスト実行管理者から見て、実行者に注意してほしいと思う点をいくつかあげてみました。

■例の件

実行者「この前見つけた不具合の件ですが...」
管理者「ごめん、それ何の件？」

テスト実行者が、テスト管理者に相談にあがるときに、よく見かけるやり取り。 
注意してほしい点は、管理者は実行者のことを四六時中見ているわけではありません。

実行者のコミュニケーションラインは、大抵の場合、管理者との一対一の線しかありません。
それに対し、管理者のコミュニケーションラインは、配下にある各実行者との線や、管理者の上の立場にいる人との線というように、一対多の線になっています。

管理者とて人間です。数日前のことは忘れていきます。
コミュニケーションラインが多ければなおさらです。

管理者が自分との会話を全て覚えていると過信せず、具体的な言葉に置き換えて話しかけましょう。〇〇画面で××になった件、とか。

■古(いにしえ)のメモ

結果:OK
備考:不明なエラーが発生したため、要確認。

備考欄にある、いつ書かれたかわからない不穏な記述。

この結果はOKが先で、さらに確認が必要なのか？
それとも確認した後でOKとしたのか？
この記述では全くわかりません。

結果を整理していく中で見かけることが多いのですが、実行してから日にちが経過した後で聞いても、本人が忘れているケースがままあります。
こういったものがテスト終盤で掘り出されると目も当てられません。

"いつ誰が記述したか"や、"確認の結果を追記する"など意識して行いましょう。

■私がルールだ

結果:OK
備考:手順の3番ができなかったため、別の操作に置き換えて実施し、OKとした

テスト手順は、その過程も含めて意味があることが多いです。
手順や期待値の曲解、こういったものは決して自己判断で結論を出してはいけません。
テストケース通りにいかない場合は必ず管理者、もしくはテストケースの作成者に確認を取りましょう。

なお、このパターンはわかりやすく備考欄に記載してありますが、備考欄に書かずに、別の操作に置き換えて実施するケースも、よく見かけます。
これは後日、別の人が同手順でテスト実施して不具合が発生した時に、ヒアリングしてようやく発覚します。

大抵の場合、大きな問題に広がります。なぜなら、テスト結果が一切信用できないものになるからです。

曖昧なものを曖昧なまま進めるとろくなことになりません。

確認を取らなければ、その決断をした結果の責任は、自分が背負うことになります。気をつけてください。

これらは私が10年テストの現場を見てきて、よく見かけるものをピックアップしました。
若い世代がやりがちのように思えるかもしれませんが、年齢問わず、どの世代でも、これらの問題を引き起こしているのを見かけます。

テスト実行者の方が、この記事を見て、よりよいテスト実行ができるようになっていれば、幸いです。

『新元号対応で求められる開発、展開と運用における対応』を聴いてきた

どうも、東京駅の日本橋口のわかりにくさに驚いたオムそばです。
八重洲口出るまでどこに日本橋口あるか書いていないんだもん…。

今回は、経済産業省と日本マイクロソフトが共催している、新元号対応に関するセミナーを受けてきました。

www.microsoftevents.com

内容については、こちらのブログに綺麗にまとめられていたので、引用させていただきます。去年からやっていたんですね。(知らなかった。。。)

qiita.com

私は一応テスト屋さんを名乗っているので、テストに関わりそうな部分を中心に、情報を抜き出してみました。
主に自分のメモ用に…。

■新元号対応に関するメモ

• 新元号の発表は2019/4/1。改元は2019/5/1
• 新元号の合字(㍻ みたいな二文字以上を一字で表した文字)符号位置は「U+32FF」で予約済。
• 他の合字(㍾～㍻)と合わせて並べ替える際は注意が必要。
• 新元号での一年目を和暦で表す場合、デフォルトは「〇〇元年」になる(例：平成元年)。ただし、元年となるのは、文字列に「年」が含まれている場合のみ。2019/5/1 のような場合にはつかない。
  ※今までは「〇〇１年」だった。
• シフトJISにおける新元号対応は行わない
• 新元号対応フォントは
  - MSゴシック
  - MS明朝
  - MS Pゴシック
  - MS P明朝
  - Meiryo UI
  - Yu Gothic UI
  - 他
• 元号対応する対象製品は「2019年5月1日時点で延長サポートを終了していない製品」かつ「現時点で和暦に対応している製品」
• 元号が切り替わるタイミング(4/30 - 5/1)においては、カレンダーやスケジューリング機能を持つアプリは注意。また、うるう年などの特殊日も要チェック。
• レジストリをいじれば現時点でも仮置きでテストは可能。ただし、あくまでも仮でテストする場合の話であり、恒久対応はレジストリを書き換えるだけではできない。
• 既に新元号対応に関するプログラムは順次リリースされている。継続的にアップデートをしてほしい
• オフライン環境や、長期間更新未実施の環境については、速やかにアップデートをしてほしい

なお、資料は後日経済産業省のホームページに掲載されるとのこと。

(2019/02/27 追記)

資料掲載されてましたー。URLを貼っておきます。

http://www.meti.go.jp/press/2018/02/20190207002/20190207002.html

ここに書いたことはそちらに全部書いてあるので、全量見たい方はそちらをご参照ください。

COUNTIFの ここがすごい

この記事は、ソフトウェアテストの小ネタ アドベントカレンダー 13日目の記事です。
前の方(NAKAKEROさん)の記事はこちら。

keronical.hatenablog.com

どうも、忘年会ラッシュ中のオムそばです。
歳を重ねるごとに増えていってる気がします。

さて、今回は、テスト管理をExcelでやっている人向けに、COUNTIF関数の素晴らしさについて、記事を書こうと思います。

■COUNTIFのここがすごい

例えばこんなテストケースがあったとする。
Excelのスーパー関数であるCOUNTIFさんなら、このテストケースをこんな感じに集計できる。

• ①OK, NGの件数などカウントできる
  =COUNTIF(D:D,J3)
  
  
• ②COUNTIFの親戚であるCOUNTIFSを使えば複数条件に合致するセルをカウントできる
  =COUNTIFS(D:D,"<>未実施",E:E,M4)
  
  
• ③範囲指定ができる(以上、以下、含む、含まないなどが可能)
  =COUNTIFS(G:G,">="&N8,G:G,"<="&N9)
  
  
• ④ワイルドカードが使える
  =COUNTIF(C:C,"*"&P4&"*")

これ一つ使いこなせれば、大抵のテストケースは集計可能だ。
まだまだExcel管理の多い世の中なので、覚えておくと便利です。

テスト実行進捗管理における躓きポイント

※本記事は、ソフトウェアテスト Advent Calendar 2018 の6日目の記事になります。
前日の記事は、___rina___さんによる、受託開発テスターと受託リモートワークテスターとWebサービステスターの違いに関する記事でした。

underscore42rina.hatenablog.com

どうも、今年もソフトウェアテストのアドカレに参加しているオムそばです。
これをキッカケにブログの更新を始めたので、書き始めてちょうど一年になりますね、時間が経つのは早いなぁ...。

さて、今回は、ソフトウェアテストのアドベントカレンダー 6日目の記事として、テスト実行進捗管理において、私や周りの人がよく躓いていたポイントをまとめてみようと思います。

■躓き1:「1ケース1時間かかるから、1日8件消化できる」

※この項目における1人日は、8時間とします。

テスト実行進捗を管理しようとしたときに、陥りがちなミスがこれ。
1ケースの消化見込みが1時間だからといって、1人1日8件進むと見積もってしまう。
これは大きな誤りで、蓋を開けてみると、遅延や残業の嵐になることでしょう。

テストは(他の作業もそうですが)単純にOKがついていくものではありません。障害の発生や起票、疑問点の発生やヒアリング、問い合わせ対応等々、実行する以外の作業が多数あります。
「それらを加味したうえで1hと見積もっている」という方もいるかもしれませんが、作業が詳細化されていないことに繋がり、結果、見積もりが粗くなることでしょう。粗い見積もりは、テスト期間が長くなればなるほど、差が広がります。

対策としては、例えば「テスト実行6h、不具合対応やその他作業2h」と置いたり、そもそもの見積もりを1人日6時間で見積もったりするとよいでしょう。
あえてその他作業を作ったのは、いわゆる"ゆとり時間"(バッファ)です。

 

■躓き2:「進捗率100%だからオンスケです(そのうちNGは25%)」

進捗率を測るとき、大抵の場合、実施率にはOK、NGが含まれます。そうすると、報告の仕方によっては、一見オンスケに見えることがあります。
しかし、もしも計画の中に、「NG箇所の再テストが考慮されていない」としたら、非常に危険です。

状況にもよりますが、大抵の場合、「NGが発生したら、発生したテストフェーズ中に改修し、再テストすること」が求められているはずです。
不具合が起きて、そのテストが問題ないことを確認せずに次のフェーズに行くことは、大きなリスクとなります。

■躓き3:「今日テストする予定だったのですが、テスト環境が止まっていて進めません」

環境に対する考慮を忘れていて計画を立てた場合、こうなりがちです。
テスト環境がいつ構築され、リリースされるタイミングがいつで、メンテが入るタイミングはいつで、テストデータはいつ準備されるか、といった環境を加味したテスト計画を立てないといけません。
もちろん、緊急で止まってしまった場合はどうしようもありませんが。

■躓き4:「進捗遅れています」「理由は？」「よくわかりません」

「わからないこと」というのは、プロジェクトにおいてリスクに該当します。
わからないことにはある一定数、爆弾が潜んでいます。
それらの爆弾がないかを事前に把握して、回避可能か、爆発した時の影響はどれくらいか、爆発した後の対処はどうするか、などを考えておく必要があります。

爆弾があるかないかわからない場所を、実行者に歩かせない、もしくは自分が歩かないようにちゃんと確認しましょう。

テスト実行は、予期せぬ出来事の連続です。

その、"予期せぬ出来事"をいかに"予期してコントロールするか"、"予期せぬ出来事が起きても致命的な問題とならぬようにするか"が、管理者の腕の見せ所です。

全てのテスト実行進捗管理者が、これらの躓きを起こさないようになるといいなと思います。

明日はtakemikamiさんの記事です、お楽しみに！

"負荷テスト"ってなんだ

どうも、テスト設計コンテストに出るために錆び付いたテストスキルを整備中のオムそばです。
サビトレールを脳に浴びたい。

先日、負荷テストとストレステストに関する記事を書いたところ、思いの外反響がありました。皆様からコメントを多数いただき、そこから派生して別の場所で議論が生まれるなど、記事を書いて良かったと思うエピソードがたくさんできました。
さて、今回は、いただいた情報を元に、負荷テストについて改めて整理してみました。

■負荷をかけて何をしたいのか

負荷テストや、ストレステストなど、言葉の定義を考える前に、そもそも負荷をかける目的(負荷をかけて何をしたいのか)を整理してみます。

• 一定の負荷をかけて測定する(性能を測る)
• 通常利用で発生するレベル(予測、または仕様化されたレベル)の負荷をかけて挙動を評価する
• 仕様に定義されている以上の負荷をかけて、その挙動を評価する

■目的に対してテストの名前を当てはめてみる

書籍によって、多種類の負荷に関するテストがらありますが、JSTQBに準拠した形で表現すると、以下の三つに分かれます。

• 性能テスト(パフォーマンステスト):一定の負荷をかけて測定する(性能を測る)
• ロードテスト(負荷テスト):通常利用で発生するレベル(予測、または仕様化されたレベル)の負荷をかけて挙動を評価する
• ストレステスト:仕様に定義されている以上の負荷をかけて、その挙動を評価する

ここで注意ですが、人によっては、負荷に関するテストそのものを「負荷テスト」と呼ぶ場合があります。
つまり、上記三つを全てひっくるめて"負荷テスト"と呼んだり、性能だけ外出しして、"性能テスト"と"負荷テスト"の2分類に分けて呼ぶケースが多くあります。
合っている、間違っているは現場毎にで議論すればよいですが、達成すべき目的は見失わないよう注意しましょう。

■その他に見つけた負荷に関わるテスト

「この1冊でよくわかる ソフトウェアテストの教科書」によると、負荷に関するテストはストレステスト以外に、以下のようなテストに分類されています。

• ロングランテスト:長時間連続稼働させることによって処理能力や稼働率を確認するテスト
• ボリュームテスト:容量の大きいデータ、もしくは大量のデータを処理できるかを確認するテスト
• ストレージテスト:リソースが不足している状況下での動作を確認するテスト
• 高頻度テスト:一定時間内に、繰り返し大量の処理を行った際の動作を確認するテスト

 その他にも、システムにかける負荷を上げ続け、限界点を計る「限界テスト」や、負荷などによって障害が発生した後の挙動を検証する「障害テスト」などがあるみたいです。

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

ソフトウェアテスト教科書 JSTQB Foundation 第3版