ソフトバンクの通信障害がヤバかったそうなので、SUPER FRIDAYのテストを考えます。

この記事は「ソフトウェアテスト Advent Calendar 2018」24日目の記事です。

@YasuharuNishiさんからのバトンです。

オカウチワニだよ。

来年の2月にはJSTQB AL(TA)の試験がありますね。

受験される方、年末はいかがお過ごしされますでしょうか？

夏に比べて連休から試験日までの期間が離れているので、

まだ良いかなと思う人もいるでしょうし、
平日が時間取れないからこの機会に一気に詰め込むワニもいると思います。

TAはテスト技法をちゃんと使いこなせているかも試験範囲です。
学習サイトやテスト技法の解説ページで例題が出ているので、

それをお題として勉強すると答えもあるので良いですね。私もよくそうやって勉強します。

・・・ですが、ある程度をこなすと、例題が枯渇してしまいますね。
ただ例題という形ではありませんが、日常にもテストのお題はたくさんあります。

以下、一例です。

ソフトバンクには、SUPER FRIDAYというキャンペーンがあります。
ソフトバンクユーザー限定で毎週金曜日に特定の飲食店で無料でサービスを受けられるアレです。
吉野家の牛丼だったり、サーティワンのアイスクリームだったり、ミスタードーナツだったり・・・。
ワニの週末の楽しみの１つでもあります。

ではこのSUPER FRIDAYのサービスを行う上でどんなテストが必要でしょうか？

商品を受け取れるかはデシジョンテーブルでテスト設計してみましょう。
2018年12月は、ファミリーマートでファミチキがもらえます。
仕様はコチラ。

----

・クーポンは、ソフトバンクのスマートフォンをお使いのお客さまが対象となります。
　ただし、法人のお客さま、503LVをご利用のお客さま、シンプルスタイル（プリペイド携帯電話）でご契約のお客さま、ワイモバイルをご利用のお客さまは対象外となります。
・クーポンの利用は、おひとり様毎週1回限りとなります。
・クーポンは必ず、レジ従業員にご提示の上、使用してください。
・クーポンは配信週の金曜日(07:00～23:59)のみ利用できます。必ず23:59までに提示してください。
・一部の店舗では利用できません。また、一部10:00～17:00のみ利用可能な店舗があります。
・ファミリーマートのファミチキ1個がもらえる日程は、12月7日,14日,21日,28日のみとなります。
・他の商品との引き換えはできません。
・商品の在庫状況により、同額相当の別商品等での対応となる場合があります。その際、免許品、専売品（酒類・煙草など）及び再販商品（新聞・雑誌・書籍など）、カード類（QUOカード・テレホンカードなど）、切手、収入印紙、ハガキ、商品券（ビール券など）のご購入、又は公共料金・貸付金・宅急便などのお支払いにはご利用できません。
・クーポンの再発行、譲渡、換金はできません。
・クーポンは印刷しても利用できません。
・クーポン発行ページへのアクセスには通信料がかかります。
・キャンペーン内容や特典は変更になる場合があります。
印刷しても使用できません。

----

合計13項目にも及ぶ仕様があります。

条件となるものもありますし、条件にならないものも混じっています。
まずは整理してみてください。

デシジョンテーブルでの整理以外にも、実際のテストを行う上ではこんなことも確認しておいた方が良いですね。

・503LVをご利用のお客様は利用が出来ないそうです。
　この機種はWindows Mobileのスマートフォンのようですね。503LVがWindows Mobileだから例外扱いかもしれません。
　今後ソフトバンクでWindows Mobileのスマートフォンが増えるようであれば、利用できないことのテストが必要になるかと。
　これを理解しているだけで次のキャンペーンでテスト対象の選定がしっかりできます。
　（他にもワイモバイルだとか、シンプルスタイルだとか・・）

・「お客さま」と「お客様」の２つの表記があります。何か違いがあるのかもしれませんし、ただの誤字かもしれません。

・「一部の店舗では利用できません。また、一部10:00～17:00のみ利用可能な店舗があります。」とありますが、端折って確認をすると、"また"を"or"の意味で誤解するかもなぁ。

・印刷しても使用できないことを2回も言うってことは、それだけ誤解されやすいのかな？

日常にもテスト設計や実施を考える上でのお題はたくさんあります。
一時的にテスト業務から離れることがあっても、こんな感じで日々鍛錬を忘れないようにしておきたいですね。

それでは、良いクリスマスをお過ごしくださいませ。

明日は最終日、@kjstyleppさんの記事に続きます。

【読書メモ】【第2部】カイゼン・ジャーニー たった一人からはじめて、「越境」するチームをつくるまで

読みました。内容が濃いので部ごとにメモ取っていきます。ネタバレもあります。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

マインドマップ

合計127のノード（気づき）がありました。第1部と合わせると217！まだ咀嚼出来ていないところはあるのですが、そういうプラクティスがまずあるということを知れただけでも大きいですね。

この本で得たもの

第2部　チームで強くなる

　第1部のラストから1年後ですね。せっかく一緒に活動してくれていた他部署のメンバーは転職。リーダーと始めたカイゼン活動は暗礁に乗り上げたところで、「こんなんでは、ダメだぞ」と1部ラストで酷いこと言ってくれた蔵屋敷という先輩にスカウトされて、スクラムを始めることに。

　なんかこんな感じですよね。会社って。新分野に飛び込まざる得ないこともあったりで急な人事があったりとか。ただトップ側の勝手な意向というわけではなく、憧れの蔵屋敷にスカウトされるほどに芽が出てる、信頼される実績を出せているというところなのでしょう。

いきなりスクラムをやれと言われた江島はキックオフMTGを開始します。

突貫でスクラムを勉強し、外部の勉強会にも参加し、2週間で内容を要約する資料をつくり、今、ここに臨んでいる。まだ、見聞きしたことをすべて理解出来ているわけではない。だから、僕自身が腹落ちしているわけではない。

　経験が足りないと不安になりますね。経験則だけでもなく、原理、原則だけでもなく、他人に教える、教えられることで磨かれ促進されることは「建設的相互作用」と第1部のコラムで紹介されています。

＊「建設的相互作用」の引用元は『教育心理学概論(新訂版)』とのこと。

  価値観の違う、生まれも育ちもスキルも違うメンバーとどう手を取り合うか

　チームで、未知のスクラムという体制での開発に個性的なメンバー、スタートから1ヵ月遅れで参加してきた関西弁のスクラムマスター（登場当初は「何も仕事していないのでは？」と言われる）、価値観のぶつかり合い、お互いの期待の不整合、問題はないと言っていたメンバーの急な失踪、終盤での新人の加入・・など、色々な課題（どれも人間らしく生臭い）が毎話発生してはチームで解決を進めていきます。第2部ではチームの話もあってスクラム色はバリバリですね。。この為、横文字も増えていきます。。

　この本はスクラムの導入書ではないので、用語に対して深い解説はないです。あまりイメージ持てていないと、読むのに苦労するかもしれません。ワニも腹落ち仕切っていない用語やプラクティスはありますが、なかなかどうして、そのプラクティスのエッセンスの伝え方が上手いんですよね。「ふ～ん」で終わらせない、知的好奇心をくすぐる料理の仕方という感じで。 

頑張れば出来る？

　第14話「問題はありませんという問題」という話の中に「ファイブフィンガー」というプラクティスが紹介されています。個人がスプリントや今の仕事の状態を、自分の考えで表明するプラクティスです。

5本：とてもうまくやれている

4本：うまくやれている感触あり

3本：可もなく不可もなく

2本：不安は少しある

1本：全然ダメで絶望的

　この話のなかで、チーム唯一の外国人ウラットが指1本を上げる。すぐさま他のメンバーから「問題がないと言っていたのに、1本なの？」と聞かれるシーンがあるのですが、主人公がウラットの代弁をします。

「がんばれば、やれるから、困っていない、でしょ」

　すごくドキッとさせられたんですよ。ホント自分にもある経験で、まじめな人だとつい言っちゃいそうだなって。

がんばればやりきれる、だから困ってはいない。でも、いつまでもがんばれるわけではない。

 　この物語を通してみれば、少し俯瞰して見れれば、そんなアドバイスが出来るのかも知れないのだけれども、これが当人だけでなくチーム全体で根を上げにくい空気感になっていたら・・誰にとっても辛いだろうな。この後別のメンバーが俺が手伝うよ！と言ってこの話は終わりますが、自分だったらどう解決させていたのだろう？

　第14話だけ取り上げましたが、この話以外にも立ち止まる、価値観を共有する、進むべき先をむきなおすと言った、チームを醸成する上でのプラクティスもたくさん載っています。

 感想

　第2部でやっとアジャイルらしいプラクティス（多少乱暴な言い方ですが）が多数登場します。モブプログラミング、バリューストリームマッピング、インセプションデッキ・・。これらを物語を通して一気に知識を詰められる出来になっているのは、ホント良く出来ていると思います。チームの解散までで第2部は終了で、第3部ではより大きな組織、チームを巻き込むことになりそう。いろいろな部署にちりぢりになったメンバーがまたどんな形で出てくるのか、新しい登場人物も期待です！

関連記事

【読書メモ】【第1部】カイゼン・ジャーニー たった一人からはじめて、「越境」するチームをつくるまで - オカウチワニのニワ

【読書メモ】【第1部】カイゼン・ジャーニー たった一人からはじめて、「越境」するチームをつくるまで

読みました。内容が濃いので部ごとにメモ取っていきます。ネタバレもあります。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

読もうと思った経緯

カイゼンジャーニー、ぽちった。
楽しみ！

— あさこ (@acha_821) 2018年2月8日

概ねこの情報だけで本書を知り、購入しました。特に立ち読みや前評判とかを調べたわけではなく。結果的に買って大正解ですね。アンテナを伸ばしていたことと、ワニの嗅覚は大したものです。自画自賛ですけど。。笑

マインドマップ

合計90のノード（気づき）がありました。第1部50ページでこれだけの情報量なので、この後にも期待ですね。

この本で得たもの

　本書は各部の中に小説がついていて、物語ベースで進みます。物語の合間に著者物語の登場人物から解説が入り、テンポが絶妙です。第1部を読み終えたまでではまだアジャイル色はほとんどありません。IT企業をテーマに、自分はこの会社にいるべきではないと思った主人公の江島が、ある外部のイベントで、石神という講演者に出会う。講演に心打たれた江島は懇親会で直接石神と話をする機会を得るが、

「それで、あなたは何をしている人なんですか？」

という問いに何も答えられないところから、1つの答えを見つけるまでが第1部として描かれています。

第1部　一人から始める

　第1部の段階では開発プロジェクトがテーマというわけではありません。外部のシンポジウムに参加したり、技術書から得た話を一方的に「ああするべき、こうするべき」と言ってきた主人公が、自分のキャリアを語るものを作れていない現実に打ちのめされ、まずは一人でカイゼンを進めることを始めます。

　カイゼンに使うプラクティスも「タスクマネジメント」、「ふりかえり(会)」など特になんなく取り入れられるところからです。ただしそれらをまったく1から説明することもなく、アドバイスもヒントレベルに留まっているように感じました。

　しかしながら実際にこの本からアクションを取ったことも考えられ、「2回目のふりかえり」、「ふりかえりのふりかえり」という一歩踏み込んだところまで解説があります。ですがあくまでヒントレベルなんですね。そこから何を感じ考え、自組織に適用させるかを考えさせられます。

 　物語の余計な脱線もなく、挿絵やマンガもありません。翻訳本のようなクールなテイストで、冗長な比喩表現もなくサクサク読めます。

1人で頑張ることを薦めているわけではない

　さすがに主人公も途中で1人で（個人ごととは言え）カイゼンを継続することに疲れて、やめてしまいそうになります。そこの解説が一番胸を熱くさせてくれたので、引用します。

行動を変え、新たな一歩を踏み出すのに「遅すぎる」ということはない。行動を始めるべきだと気づいたそのときが、その人にとっての最速のタイミングだ。

変化は一人から始められる。その次は、その変化を目の当たりにした二人目がきっと出てくるはずだ。（中略）いつだって始めるのは自分一人からだ。だが、君はいつまでも一人と言うわけではない。

　どんな活動も1回で1人でやることはなんとか出来るかもしれません。それを継続させることは本当に難しい。変化が起こらない時期が続くと投げたしたくなりますね。それでも歯を食いしばって続けることで、その人のブランドとなり、投げ続けた石は波紋ではなく、波になっていく。

活動を継続することで声をかける人が出てくる

　活動を始めてからおよそ半年でやっと興味を持ってくれた他部署のメンバーが出てくるのですが、社内展開を積極的に行ってなかったとはいえ、なかなかリアルな描写だと思いました。背景として正論めいたことを頭ごなしに言い散らかしていた主人公だったというところもありますが、なかなか協力者が出てくることって少ないんですよね。自発的に。

　協力してくれるメンバーも良い感じにリアルな距離感があるんですよね。部署も違うことから朝会にときどき顔を出すにしてもお互いのやることに「へー」とか「ふーん」ぐらいのことしか言えないっていう。だけど、プラクティスには賛成しているから時々は顔を出すわけで。

さて、この部の最後は社内で現在までの活動報告をする勉強会が成功して終わります。集まったみんなから拍手も上がるし、中間管理職で理解がないと思っていたメンバーも参加してくれて褒めてくれたし、自分なりの何者かの答えも持てた。

そこに久々にあった尊敬している先輩から一言、こんな言葉で締められています。

「こんなんでは、ダメだぞ」

こんな奈落に落とすようなラストだなんて。卑怯ですよ。。笑

続きが気になって仕方がない。

 感想

　シンポジウムやカンファレンスに参加するようになって来た人には、主人公の立ち居地も理解でき、感情移入しやすいと思います。組織がー、会社がー、ではなく、出来るなかでまず自分が動くことがなにより。「許可を求めるな。謝罪せよ」の精神だそうです。　

ちょうどブログ記事を書く様になってきたのは、昨日今日の話ですが、本書を手に取る前だったりします。運命的なものを感じますね。

関連記事

【読書メモ】【第2部】カイゼン・ジャーニー たった一人からはじめて、「越境」するチームをつくるまで - オカウチワニのニワ

【読書メモ】マインドマップから始めるソフトウェアテスト

読みました。

マインドマップから始めるソフトウェアテスト

読もうと思った経緯

社内で割りとマインドマップとソフトウェアテストの話を聞くことが多く、最低限の知識を身につけておこうかなと思ったので。マインドマップとワニが出会ったのは2008年ごろと思うのですが、しばらく嫌いだったんですよ。絵を描くことが目的の１つと思っていたから。

マインドマップ

合計66のノード（気づき）がありました。マインドマップに落としていく中でちゃんと読めていないところが見えたり、疑問点をそのままにしなかったりとなんとなく読んでいるよりは大分スッキリ読めた印象。「ローリングウェーブの計画」とか単純にまったく知らない知識にも出会えました。

この本で得たもの

新しいものを使うことに抵抗はない人間なのですが、ソフトウェアテストにマインドマップを使うことに抵抗がありました。正直。それはワニの中でマインドマップというものが「知識として知っているが、業務として使うもの（正式なアウトプット）としては、認められにくいような風潮」、「周り(目の見える範囲)にマインドマップを使っている人がいない」、「個人的なアイデア出しは良いとして、定量的に効率アップを証明しにくい」、「業務中に絵を描くのは抵抗がある」といったところでしょうか。直接的に怒られることはないですが、認められにくい環境ではあったと思います。最近はそのマインドは大分薄れてきましたが。話長くなりそうなので、この話は別途。

マインドマップで新しい"気づき"を発見する

　ベテランのテスト技術者が暗黙的に出来ているテスト分析と同等のことを行う為にマインドマップが有効と書いています。テスト分析と書くと意味が広いのですが、仕様書からのコピペでテストケースに落とし込みをすると、テストケースの質が仕様書記述に左右される。ベテランのテスト技術者はそこを勘と経験で補って、テストケースを作成できるが、初心者には簡単には出来ない。簡単に教えれるものではないので、マインドマップを描くことで自然と行えるようにするものとのこと。

マインドマップは新しい技術ではないので、そこで嫌悪感を持たない

　今やマインドマップの名前を聞くことも珍しくはなくなりましたが、そもそもマインドマップは歴史の浅い技術ではないそうです。1960年代にトニー・ブザンによって考案されたもので、50年近い歴史があります。会社でもしマインドマップを誰かに推奨する時はこの情報も与えると良いかもしれませんね。良くわからない横文字の時点で嫌悪感を持つ人もいるので。

きれいなマインドマップが目的ではないので、絵や色、書き直しにとらわれない（そんなことを考えている暇があったら、1枚でも多く書く) 

 　手書きで描くと余計にですが、書き直しが難しい以上、心理的にきれいな、完全なマインドマップを描かねば・・という心理に陥りがち。本書でも要所要所でその心理的プレッシャーを和らげる解説が豊富です。例えば、メイン・ブランチ（中央のテーマから一番最初に延びるブランチ）を描くのに抵抗があれば、先にメイン・ブランチの候補リストを別紙に書き出して眺めてみるとか。

　初学者にとって、合っている、合っていないを自分で判断することが難しいものや、マインドマップのような答えが不定なものは、"正誤の確認作業が出来ない"→"不安になる"→「うーん、よくわからん。使うのをやめよう・・」となりがち。そこまでの配慮、解説が出来ているのはニクい本ですね。

　各テストプロセスに対してのマインドマップ導入例もメイン・ブランチからステップバイステップで解説されているので、それを参考にまずは同じ題材でマインドマップを描いてみる。自分の業務に置き換えてどこから導入出来そうか考えてみるのも面白そうです。知識を知っていることと使えることはまた別ですからね。

 感想

　ソフトウェアテストとマインドマップについても紹介は念入りで、50/216Pも割いてある。ソフトウェアテストの意義の解説や例もわかりやすく、知識がまだまだの人が読んでもそこまで読むことに苦労しないのかなという印象でした。網羅的なテストプロセスの理解や、各プロセスでのマインドマップの使いどころ（と勘所）が理解出来て良い。10年以上前の技術本ですが、まだ中古では手に入るものです。

ワニがバグ票書く時に心がけていること

この記事は

qiita.com

24日目、12/24の記事です。

ワニはバグ票ワープラというコミュニティに属してはいますが、個人的に思っていることをつらつらとまとめてみます。2017年12月時点の所感です。来月や来年はまた違うことを思っているかもしれませんが、それはそれで良いと思います。

１．バグ票1枚で完結すること

一番心がけているのはこれですね。バグ票1枚でバグの報告が完結すること。「複数のバグ票にまたがって１つのバグを報告をしませんよ」ということではなくて、そのバグを理解するうえでの情報がすべてバグ票1枚に収まっているかどうかです。

バグ票を読む上での手間を減らしたいわけなんですね。

"期待する動作"の項目に「仕様と異なる」の一言書いてあったとしましょう。

こう書かれるとそのバグ票以外の参照ドキュメントが必要になり、開く手間、探す手間がどうしても発生してしまう。バグ票起票者が修正に必要な情報を知っていて教えないことに何のメリットもないんです。

自分の理解のチェックにもなるので、良いですよ。

けっこうミスするものです。人間って。

参照仕様のページ数の入力ミスだとか、リンクの貼り付けミスとか。

２．やったことを書く。書くことに躊躇しないキモチを持つ

発生しにくいバグに発生しやすい手順、発生しにくい手順があることがわかったら書こう。バグの原因を探す上でブラックボックスであっても、いろいろな実施結果があればそれがヒントになる。情報の与え過ぎはダメだけど。

とはいえ、あまり不確かなことを報告したくないのもすごくわかる話です。ひとつほころびがあると、他の記述もちょっと大丈夫・・？というような疑いをかけられてしまう。

じゃあその不安をどう拭えば良いのかと言うと、いきなりバグ票という本番に流す前に、周りのテストメンバーや開発と話をしてみる。自分が見えていなかった観点や切り口での話が聞けるかもしれないし、密に情報交換を図ろうという姿勢で口を開いてくれることもあるでしょう。一人で考えている時って恐ろしいほど視野が狭くなっていたりするので。

やった、やってない、発生した、発生していない、X回中Y回発生する、体感だが手順Ｚの方が発生しやすいなどの実施結果を、まずは自分でまとめてからコミュニケーション取ると良いですね。話しながらまとめるのはいきなりは難しいです。

【余談】

そんなことを言いつつも、ワニも結局のところ「再現性がないし、面倒だなぁ。これ以上やっても出なければ報告出来ないから、なかったことにしよう」と諦めた、諦めざるを得なかったバグ報告もあります。その後、同じようなシチュエーションに出くわすと、諦めた経験がつい顔を出して「どうせ再現しないから」と諦めることがクセになってしまう。

アプリの機能が出来ている出来ていない、品質の良い悪いをジャッジする人に心のカゲがあると、テストに支障が出ることは明白。なるべく心はクリアにして挑みたいですね。

３．ログがあれば良い、動画があれば良いに負けない

アプリの操作ログや動画が取れるならば、取る。ここに否定はまったくないのだけれども、それがあればバグ票としてOKかと言うと違うと思う。

操作ログ取得や動画をもれなく取れていれば、それは完全な情報源で良いですが、バグ票を読むのは人間。より伝わりやすい表現や方法があると思うんですね。野球で例えるとわかってくれる人とか、スター・ウォーズで例えるとわかってくれる人とか。

このプロジェクト、組織ではこの方が"より"わかってもらえるということがあるので、

過去の成功体験をごり押しし過ぎない心のやわらかさを持っておきたい。

まとめ

気になっていることを３つ書いてみましたが、バグ票を書く上でもコミュニケーション必要だぜ！一人で考え込まずに周りと話をしてみようぜ！という感じでしょうか。

この記事を読んで、なにか今一度バグ票を見つめ直すきっかけ、話のタネになればうれしいです。「ワニの言うことなんて全然間違ってるぞ、俺が考える心がけていることはこうだ！」とかね笑

それではみなさま良い聖夜をお過ごしくださいませ。

以上ワニ！