バグレポートは伝え方が9割(※個人の感想です)

こんにちは。カルバートです。

GW前に参加してきた、「"Issueの書き方と伝え方"勉強会」の内容と、当日感じたことを書きます。

connpass.com

 

当日のツイートまとめ

togetter.com

 

エラーと欠陥と故障と不具合/バグの違い

JSTQB用語を学ぶときの最初の障壁(※個人の感想です)、エラーや欠陥などの用語の違いについて、秋山さんのスライドがとてもわかりやすかったです。

https://image.slidesharecdn.com/20180421-aster-180420130433/95/20180421-issue-4-638.jpg?cb=1524229592

エラー:てへぺろ→人間だもの間違うことはあるよね

欠陥:家のヒビ→てへぺろ結果埋め込まれてしまったもの(ディフェクト)。経年劣化などで表面化してきたものはフォールトと呼んで区別する場合もある

故障:期待と違う結果→ヒビのところから家が壊れた、ディスプレイの画面が乱れた

不具合/バグ:故障が表出した(人間が観測できた)もの→レポートの対象になるのはこれ

 

私のまわり(おもにWEB系ドメイン)では、これらの概念を特別に区別して扱っていることはないのですが、厳密な分析を行ったりする場合には、区別して整理する必要がありそうですね。

 

「報告する人」と「報告を受ける人」は対立構造になりがち

今回は4名の方が発表されましたが、バックグラウンドが皆様それぞれに異なっており、注意すべきと考えているポイントも異なっていると感じられたのが印象的でした。

 

本来、不具合/バグを報告するレポートは、「サービスが期待する振る舞いをしていない」という事実を伝え、サービスを改善するために書かれるべきだと思います。実際、レポートそのものは事実を伝えるべく書かれるのですが、内容がネガティブなものにならざるを得ないため、「報告する人」から「報告を受ける人」への攻撃と受け止められがちなのかなと感じます。

 

「報告する人」の視座

秋山さんやリナさんの発表では、「報告する人」の立場から、テスト担当者と開発担当者が明確に別れている前提で、どのように感情を損なわず、お互いの納得感をもって、事実を記録し、情報の同期を適切に行うかという趣旨のお話をしていただきました。

 

リナさんのケースは個人的にとても衝撃的で、自分なりに表現すると、映画の中の理想の世界でした。黒い白鳥なんてお話の中の世界なんだから、現実を見なさい。白鳥は白いのよと教わってきた人が黒い白鳥を見たときの衝撃という感じでしょうか(伝われ)。

関係性ががっちり構築されていると、こんなにも理想的な立ち回りができるのだなあ。。。と感じた発表でした。普通の人にはマネできないと思います。

 

「報告を受ける人」の視座

一方、渋谷さんの発表では、「報告を受ける人」の立場で、様々な考え方を伺うことができました。僕自身の経験でいうと、とある案件の本番導入に「報告を受ける人」の立場で立ち会ったことがあるのですが、それはもう地獄でしたね。「おまえらの作ったサービスがちゃんと動かないから大変なことになっている!どうしてくれる!」という感情が篭ったレポートを毎日何十件も読んでいました。ただ、その感情の先に、「サービス提供者として気づけていなかった、隠れていた要件」が存在していたりするので、二度と思い出したくない反面、自分の原点のひとつになっている経験でもあると感じています。

 

みっきーさんの発表は時間の関係で深く議論できませんでしたが、また別の機会があると嬉しいです。

 

結局は人が相手なんだし、思いやりが大事

バグレポートに限らないのですが、結局人間である以上、耳の痛い情報を受け取るときにネガティブな感情が発生してしまうことは避けられないのかなと思います(人間というものがそういう風に実装されてしまっている)。

その特性(仕様)を理解して、「報告する人」と「報告を受ける人」がお互いに気持ちよく仕事をするために、まず「伝え方」を工夫することが大事なのかなと感じた1日でした。

 

 

発表資料

www.slideshare.net

 

www.slideshare.net

 

 

不具合票あれこれ - Google ドキュメント

 

参考書籍 

ソフトウェアテスト293の鉄則

ソフトウェアテスト293の鉄則

 

 

余談

秋山さんから、デザートをいただきました。ありがとうございます!とても美味しかったです!

f:id:trickmr:20180513154027p:plain

 

信頼度成長曲線は信頼できるのか。

こんにちは。カルバートです。

先日、信頼度成長曲線を語る夕べに参加してきました。

kataruyube.connpass.com

 

信頼度成長曲線とは

信頼度成長曲線とは何なのか。自分の理解の範囲で言い換えると、

いつまでテストすればいいの?を数学的に予測するやり方です。

そもそも未来を予測することはできるのか?という難しい問題提起に対して、偉大な先人たちは様々な数学的モデルを考案してきました。ロジスティック曲線やゴンペルツ曲線など、様々なモデルが存在します。いずれも、自然界の事象を数式でモデル化することで、未来の予測に活用しようとしたものだと理解しています。

 

ソフトウェアの不具合検出に、その技法は応用できるのか

「語る夕べ」に参加したうえでの個人的な感想は、「理論上不可能ではないが、実務に応用するためには前提条件を整えるコストがかかりすぎて、難しいのではないか」でした。ざっと調べた限りなので間違いがあるかもしれませんが、たとえば生物の発生にロジスティック曲線を適用する場合、外部の環境(気候や食糧など)が一定しているという前提が満たされている必要があります。ソフトウェアテストにあてはめた場合、「不具合は偏在しない」「不具合の発見されやすさは常に一定」といった前提が必要になってきます。テストレベルが低ければ部分的には応用できるかもしれませんが、それらだけ切り出して分析することでテストの収束が予測できるかというと、また別の話なのかなと思いました。

 

綺麗なグラフを見たら建設的に疑おう

当日は、みっきーさんの(つらい)経験をベースに、信頼度成長曲線をそれっぽく見せるための様々なテクニックをお話しいただきました。いくつかは自分自身も経験したことがあるものでした。

未来を数学的に予測するための道具が本来の使われ方をせず、綺麗な数字をステークホルダーに報告するためだけの存在になってしまっている(ことが多いらしい)という話は、なんとも悲しいものです。そんな作業をするために、人生の貴重な時間を使いたくはないものですね。

信頼度成長曲線に限らず、グラフを見たら根拠を建設的に疑う。自分がグラフを書くときは、根拠が誤解なく伝わるよう務める。そんなことが大事なのかなと感じたイベントでした。

 

参考にした書籍 

予測のはなし―未来を読むテクニック

予測のはなし―未来を読むテクニック

 

 

当日のツイートまとめ

togetter.com

第4回 テスト観点を語る夕べに参加しました

こんにちは。まつやま改め、カルバートです。

第4回 テスト観点を語る夕べに参加してきました。

当日のtogetterはこちら。

togetter.com

 

はじめに

まずは登壇者のなそさんが作成されたマインドマップがどーん!

めちゃくちゃ文字が綺麗で、美しいマップです。

何を食べたらこんな綺麗な文字が書けるのでしょうか…羨ましいです。

 

参加型ワークショップ 

当日はまず前回のおさらいから始まり、その後はにしさんのファシリテートを受けて、なそさんのマインドマップに加筆修正が行われていきました。

 

そのサービスのコアバリューは何か

今回のワークショップでは、connpassというサービスを題材に、サービスのコアバリューを列挙し、それを親要素としてテスト観点をブレイクダウンする手法が取られました。ここで重要なことは、機能や操作(※)といった、ソフトウェアの構造上の「わかりやすいポイント」に最初に飛びつかないことです。

(※ connpassの例でいえば、「検索」や「申込」などが該当すると思います)

 

僕はこれまで、要求や要件を親とするアプローチや、機能や操作を親とするアプローチを多く経験してきましたので、これは個人的に新鮮でした。

 

いつでもどこでも

コアバリューの例としてなそさんが挙げられたキーワードに「いつでもどこでも」がありました。connpassは勉強会ポータルですから、いつでもどこでも好きなときにイベントを登録できること、参加申し込みができること、キャンセルができること、あるいはサイトに繋がるといったことが重要なバリューになります(と、この勉強会では解釈しました)。

 

コアバリューを分解する

次に、コアバリューを分解していきます。ここでひとつ、注意点があります。それは、いきなり具体的なキーワードを書かないということです。子ノードを作成するときに、「いつでもどこでも」から連想する具体的なワード(例:ログイン機能)を書きたくなってしまいますが、一歩立ち止まって我慢が必要になります。子ノードを作成する目的は、今すぐにわかりやすいテストケースを作成することではなく、親ノードの持つ「意図」を分解することです。

 

 「いつでもどこでも」を親とするならば、次の子ノードの例は「いつ」と「どこ」になります。これ以上いきなり細かくしてしまうと、MECEや継承関係が後から確認しづらくなってしまいます。

 

思考がアンカリングされていることを意識する

子ノードを出すときのもうひとつの注意点として、思考のアンカリングがあります。今回は、「いつ」というキーワードの意図を紐解いていくと、トラフィックが増えたとしても、それに耐えられること」という意図が浮かび上がってきました。このとき、参加者は全員「トラフィックの増加って、つまりどういうことだろう?」と、具体的なユースケースや、システムのアーキテクトを想像しはじめます。

 

僕の場合は、「某人気イベントに人が殺到したけど、あの重たさは許容範囲内だったんだろうか」とか「トラフィックと一口に言ってもいろいろあるし、内部構造を知っているか知らないかでも気にするポイントは変わるな」といったことが頭に浮かびました。

こういった状態では、脳は「トラフィックが増えたとき」のことをどんどん深く考えてしまいます。それは決して悪いことではないのですが、この状態で他の「意図」について考えようとしても、「トラフィック」思考にどうしても囚われてしまいます。これが「思考がアンカリングされている」状態です。

 

この対処としては、アンカリングされている間は頭が空っぽになるまでアウトプットを続け、空っぽになったと思われるタイミングで次に移ることが有効だそうです。このメソッドは、ブログを書いたりするのにも使えそうですね。

 

ここまでのまとめ

・コアバリューを起点に、子要素をブレイクダウンする

・子要素をブレイクダウンするときは、いきなり具体例に飛びつきたくなる誘惑と戦う

・思考がアンカリングされていることを意識する 

 

当日はこのほかにも色々お話があったのですが、一旦ここまででまとめとさせていただきます٩( 'ω' )و  

 

(WIP)2012年以降に出版された「ソフトウェアテストやQAの話題が載っている書籍」の一覧

まつやまです。

TestingCommunityJPでの会話を発端に、2012年以降に出版/改訂された「ソフトウェアテストやQAの話題が載っている書籍」の一覧を作ってみました。カッコ内は出版日です。ほぼAmazon調べです。

TDDや自動化関連が若干多い印象があるものの、そもそも書籍自体が少ないように感じます。情報のありかが、書籍からWEB上へと移行していっているのかもしれませんね。

一覧は、適宜アップデートしていきたいと思います。

※4/24追記:「テスターちゃん1,2巻」「システムの問題地図」を追記しました。 ※5/2追記:「エキスパートが教えるSelenium最前線」「WEB+DB PRESS総集編[Vol.1~102]」を追記しました。

ソフトウェアテスト

QA

  • カイゼン・ジャーニー(2018/2/7) ※「QA担当」が明確に存在する組織のお話です
  • ベタープログラマ(2017/12/15) ※21章は丸ごとQAの章です
  • ジョイ・インク(2016/12/20) ※「QA担当」が明確に存在する組織のお話です


TDD

テスト自動化

CI/CD

  • [改訂第3版]Jenkins実践入門(2017/5/24)
  • Javaビルドツール入門 Maven/Gradle/SBT/Bazel対応(2017/2/8)
  • Gradle徹底入門(2014/11/5)


Amazonでは「継続的デリバリー」が2017年出版という扱いで出てきたのですが、かなり古い本のはずなので、割愛させていただきました。

プロセス改善

  • システムの問題地図(2018/2/17)
  • TPI NEXTⓇ ビジネス主導のテストプロセス改善 (2015)
  • ソフトウェアプロセス改善手法SaPID入門(2014/3/1)


非機能試験

なお、近日中に「安全なWebアプリケーションの作り方」(2011/3/1)のUPDATE版が出るそうです。 blog.tokumaru.org

SWEBOK

  • ソフトウェアエンジニアリング基礎知識体系 ―SWEBOK V3.0―(2014/11/21)


SQuBOK

  • ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)(2014/11/29)


共通フレーム




- 共通フレーム2013(2013/3/4)

雑誌

gihyo.jp gihyo.jp gihyo.jp gihyo.jp gihyo.jp gihyo.jp gihyo.jp

資格関連

【ゲームのはなし】DANCE RUSHで遊んできました

まつやまです。

KONAMIの新作ゲーム、DANCE RUSHで遊んできました。

 

www.youtube.com

 

筐体はかなり大きめ。フットパネルが非常に広く、派手です。とても目立ちます。

料金は、100円2曲とちょっとお高め。

(設置面積あたりの単価を考えると、やむを得ないとは思います)

 

遊んでみた感想

ルールがシンプルで、かなり遊びやすいです。

画面奥から迫ってくる表示に合わせて、両足でステップ&体を上下させるだけです。

今のところは極端に難しい譜面もなく、ちびっこでも遊べる設計になっています。

(わかる人向けに書くと、SDVXとチュウニズムとDDRとダンエボを融合させて、ライトユーザー向けにチューニングした感じ)

 

ただし、曲が少ない&解禁が重い

稼働してあまり日数が経過していないこともあり(?)選べる曲がとても少ないですね。

ゲーム内でポイントを貯めないと遊べない曲も多いのですが、従来の機種に比べて、解禁までに必要なプレイ回数が非常に多いと感じました。

 

 

今後期待したいこと

まだまだ曲が少ないので、どんどん増やしていただきたいですね。

あとは、極端に難しい譜面が増えないと嬉しいです。難しい譜面が出始めると、一気にマニア専用機になってしまうんですよね。。。

(わかる人向けに書くと、難易度が緑と黄色しかないので、いずれ赤譜面は解禁されるものと思います)

 

とりあえず

Gimme a Big Beat 

を手に入れるまでは頑張ろうと思います。

【勉強会レポート】D3:グルメなテスト自動化&テスト設計モデリング に参加してきました

まつやまです。本日は「グルメなテスト」のイベントに参加させていただきました。

会場は床が芝生のようになっていて、とてもリラックスできる空間でした! 

イベントは、3名の方が1人ずつ発表される形で進みました。
発表テーマは以下のとおりです。 

発表テーマ

「Flakyなテストとその判別方法の解説」(ブロッコリーさん)
「お弁当QAのあみだくじ 〜時系列のイベントを洗い出す〜」(EgaSaさん)
「明日から始めるSelenideによるブラウザテスト 2018年版」(島根 義和さん)


ここからは、各発表ごとのまとめを書いていきます。


「Flakyなテストとその判別方法の解説」(ブロッコリーさん)

発表資料

https://speakerdeck.com/nihonbuson/flakytests

ブロッコリーさんは、JaSST'18 Tokyoの基調講演をはじめ、合計3回に渡ってJohn Micco氏の講演を聞き、さらには直接John Miccoに会いに行って質問をされたそうです。(すごい情熱だ) 

JaSST'18 Tokyoの基調講演などに参加された方にとっては既知の情報を含みますが、Googleではほぼすべてのテストが自動化されており、結果がDBに(一定期間)保存されています。

テストは大きく分けて「Presubmit Testing」と「Postsubmit Testing」の2つに分かれます。前者はコミット単位のテスト、後者は複数回のコミットをまとめた単位のテストです。

テストには多くのリソースを必要とするため、すべてを実施することはできません。そこで、テストを減らすための取り組みを行なっています。

取り組みには「Greenish Service」と「Skip Tests」の2種類があり、前者は確率論で「テストしなくてもおそらく大丈夫」を判断し、後者はテストの「成功/失敗」に着目し、その状態変化の頻度(回数)が多いものを「あてにならないテスト」としてあぶり出しています。

Googleのテストケース及びテスト結果は、非常にシンプルな構成のテーブルに格納されています。特に、テスト結果のカラムに格納される値で、それが開発者の責任なのか、インフラなどコードが関係ない部分での責任なのかを分類できるようになっています。

ブロッコリーさんも強調されていましたが、Flakyなテストを抽出するためのSQLは非常にシンプルで、技術的にはおそらく1年目のエンジニアでも書けると思います。(ここまでシンプルな設計に落とし込めたところがすごい)

ということは、うまくやればGoogleの良いところを、明日から自分の仕事場にも持ち込めるかもしれない。そんな希望が垣間見える内容だったと感じています。

なお、Flakyテストのチュートリアル資料は公開されています。
https://github.com/jmicco/JaSST_tutorial

 

「お弁当QAのあみだくじ 〜時系列のイベントを洗い出す〜」(EgaSaさん)

EgaSaさんによると、現在スウェーデンで開催されているICST(International Conference on Software Testing) 2018は、講演の動画が無料で公開される予定だそうです。これはやばい。

閑話休題。お弁当QAモデルというのは、WEBフロントなどのテストを素早く行うためのモデルだそうです。一般的なモデリング技法は非常に重たい(実務で使うには時間がかかりすぎる)ため、このようなモデルを採用しているとのこと。

今回は「お刺身モデル」の紹介をしていただきました。書き方はかなりシンプルで、左端にステークホルダーを書き、横軸に時系列の線を引きます。そこに、イベントを斜めの線で差し込んでいきます。

その後、「コンフリクト」や「イベントが発生しない場合」などの要素を追記して、最後に、モノサシなどで時系列をトレースしながら、テストケースの設計を行っていきます。手書きでやるのがおすすめだそうです。

(と、今日の時点では理解しましたが、正直曖昧です。また後日この内容で記事を書ければと思っています)
このモデルを採用するメリットは、まず手軽であるということと、手軽であるがゆえに、メンバーに使ってもらうハードルが下がるということです。特に、非エンジニアの方には刺さりそうだなー!と感じたので、見よう見まねで明日から使ってみようと思います。

 

「明日から始めるSelenideによるブラウザテスト 2018年版」(島根 義和さん)

今日の内容を復習するために「Selenide」でぐぐったら、発表者ご本人の記事がHitしました(^^;)

JShellを使ってSeleniumで対話的にブラウザ操作を行う
https://qiita.com/shimashima35/items/918b26c4260e764ce90a

Javaで簡単にUIテストを書けるSelenideを使おう~Selenideの概要とテストの保守性を上げるPage Objectパターンの紹介
https://codezine.jp/article/detail/10335

内容はSelenideのチュートリアル(ライブコーディング)でした。

私は、Seleniumは触ったことがあるのですが、Selenideは(名前は聞いていて興味はありつつも)まだ触ったことがない状態でした。

チュートリアルでは、REPLツールであるJShellを用いての、対話的なスクリプトの実装&実行を行ってくださいました。(ビズリーチさんのWEBサイトを操作する実演もありました!)

開発者ツール起動からの、byidでUI上の要素を指定、といった作業は経験していますので、このあたりはすんなり理解できたと思います。$で値を取れたり、何となくいろいろ便利なんだな?という程度のイメージはできました。

「お刺身モデル」と同様、やはり実際に使わないとちゃんとイメージできないので、これも一度使ってみようと思います。テストだけではなく、様々な用途に応用できるとのこと!

 

まとめとか感想とか


JaSSTの内容は本当に濃くて、噛み砕いていくとまだまだいくらでも味わうところがありますね。Flakyなテストにマヨネーズをかけて(?)美味しい料理にして下さったブロッコリーさんは本当に素晴らしいです。

お刺身モデルはまずは手軽に試せそうな印象がありました。Selenideはこれまで携わってきた自動化スクリプトの延長線上に存在することがイメージでき、学習のハードルがぐっと下がりました。

普段一人で勉強していると、何となく勉強のための勉強というか、変に(ネガティブな意味での)意識高い系に陥ってしまうことがあるのですが、外部勉強会に参加するたびに、そこのベクトル矯正といいますか、むきなおりができて、明日のための燃料がチャージされるイメージがあります。

私はまだ社外での発表をあまり行なっていないのですが、もしそれが誰かの燃料になるのであれば、機会を増やしていきたいと思います。

 

イベントページ

https://d-cube.connpass.com/event/83288/

【ネタバレあり】FindingBugsで遊んでみた

まつ(@mty_mno )さんが公開された探索的テスト用アプリで、早速遊ばせていただきました!

http://milk0824.sakura.ne.jp/finding_bugs/testerchan.hatenadiary.com

自分の思考プロセスや操作の癖が垣間見えて面白かったので、簡単にまとめてみました。

(※実績解除のネタバレが含まれますので、実際に遊ばれてから読まれることをおすすめします。)

結果はこちら

見つけた順番 見つけたバグ コメント(どういう考えや操作でこれを見つけたか、など)
1 投稿で入力をしないとカウンターが現れない 事故です。
2 リストで月が1ヶ月前表示 これはすぐに気付きました。SYSDATEを体内に持っていることが自覚できたのは面白かったです。これが2番目に来た理由は、「まずは投稿機能を使ってみたいと思った」からです。
3 投稿で、投稿した後に文字が消えない これもすぐに気づきました。
4 リストで何度も「良いね!」ができる これもすぐに気づきました。押せるものはとりあえず繰り返し押してみよう、という思考で操作していたと思います。
5 画像がアップロードできない 「そろそろ画像アップロード機能も使ってみよう」で気付きました。チュートリアルにあったのに、見てませんでした。
6 おすすめで同じフォロワーをフォローできる 「とりあえずおすすめユーザーを全部フォローしておこう」の作業中に気付きました。
7 プロフィールでフォロー解除をキャンセルしてもフォロー解除される 「そろそろプロフィールも編集してみよう」で気付きました。自分で自分が面白かったのが、フォロー解除のキャンセルを先に行ったことです。これは理由が恐らく2つあって、単純にフォロー解除をされたくなかったのと、キャンセルを先に試してみたかったからです。
8 プロフィールで文字数オーバーでも名前を変更できる とりあえず文字数が絡むものは、最大桁数を入力したくなりますよね。
9 プロフィールで名前を変更してもヘッダの名前が変更されない 名前変更からの流れで、自然に気付きました。
10 リストで出したコメント欄を消せない フォローしたユーザーの投稿にコメントしようとして気づきました。状態を元に戻せるかなーというのは確認したくなりますよね。
11 リストで出した削除ボタンを消せない 状態を元に戻せるかなーというのは確認したくなりますよね。
12 リストで人の記事を削除できる あれ、自分以外のユーザーに削除ボタンが見えてるぞ?と気付きました。
13 投稿で文字数オーバーなのに投稿可能 「そういえばいちばん基本的なことをやってなかったなー」で気付きました。
14 2個目のコメントを書き込むことができない これも「とりあえず繰り返してみよう」で気付きました。
15 おすすめで同じ人が表示される これはなかなか見つかりませんでした。同じ人をフォローできる時点で、そういう仕様なのかな?と思ってしまいました。

ひととおり遊んでみた感想

何かの機能(≒観点)にフォーカスしている間は、「他の機能が目に入らない」という感覚がありました。

脱出ゲームのアプリを解いているときと同じ頭の使い方をしていたのかな?と思います。

あとは、どうしても機能に意識が行ってしまって、ユーザーとしてどう使うかといったところが疎かになってしまい、「探索的テストは、ユーザビリティのテストなどには向かないのかな?」などと思ってしまいました。※個人の感想です。

自分の行動を振り返ってみると、いろいろ気付くことがあって面白いですね。