【勉強会レポート】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 おすすめで同じ人が表示される これはなかなか見つかりませんでした。同じ人をフォローできる時点で、そういう仕様なのかな?と思ってしまいました。

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

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

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

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

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

【探索的テスト】ウォーリーをちょっと探してみた

まつやまです。

探索的テストについて、「ウォーリーを探せ、をやりこむと分かるよ」というアドバイスをいただきましたので、まずはちょっとだけ探してきました。 図書館の児童書コーナーで。

赤いシマシマパターンを探す作業

まずはウォーリーの特徴である「赤いシマシマ」を探します。 ウォーリーはそれなりに簡単に見つかりました。

ウォーリーの特徴は「赤いシマシマ」だけではない

この絵本には、ウォーリー以外にも「似たようなキャラ」が登場します。ほぼ服装は似ていますが、ウォーリーは「男性」「メガネをかけている」などの特徴があり、場面内に本人はひとりしか登場しません。

いちどにメモリに残せる情報は少ない

これはぼくの頭の癖なのだと思いますが、ウォーリーを探す際、「ウォーリーの特徴をすべてインプットしてから探索する」のではなく、「最も特徴的な特徴をインプットして、手当たり次第探索する」「最も特徴的な特徴に合致した場合、次の条件を適用する」となりました。 探索の順序としては、「まず赤いシマシマを探す」「次に、ウォーリーか否かを判断する」となりました。

これは自分の思考を振り返ってみて、とても面白いなと感じたところです。

ウォーリーを探している間、他の情報は見えなくなる

ウォーリーを探せ!の世界では、だいたいあちこちでトラブルが起こっています。絵画が水を吹き出していたり、川に人魚がいたり、鉄道から牛が脱走したり。けれども、「赤いシマシマ」を探している間、これらの情報は全く頭に入ってきません。視界には入っていますが、認識できません。

ページ上部の本文で「ほふくぜんしんをしているひとをみたよ!」と言われない限り、匍匐前進をしている人にも気づけません。ところが、本文を読んだ瞬間、逆にそこが浮かび上がって見えるようになります。これがすごく面白い。

ウォーリーをちょっと探してみて学んだこと

身の回りで起きている様々な事象に対して、いちどに認識できる範囲は驚くほど狭く、また、何かしらのキーワードで意識を傾けないと、情報はそこに存在しているだけで、認識できないのだと体感しました。

探索的テストでチャーターを設定する意義が、ちょっとだけわかった気がします。

ということで

これからもウォーリーを探し続けてみたいと思います。ゴールは「やり込んだ」と思える程度で。

レビューを語る夕べ 第3回 簡易まとめ

先日参加した「レビューを語る夕べ 第3回」をまとめようと試みていますが、時間がかかりそうなため、簡易まとめを出してみようと思います。 登壇者の方の解釈と異なる可能性がございますが、ご了承ください。


レビューを語る夕べの狙い

レビューのスキル教育において、特に暗黙知の継承をどうしたら良いか考えたい


インプット資料

togetter.com


当日話されたこと

  • レビューをする際、成果物の一部を主観的に「怪しい」と感じることがある/感じる人がいる
  • 主観的な「怪しい」を感じ取るための(プロセスの精度を上げるための)オレオレ技法がある
  • 逆に、ゲーティングのレビューなどでは主観の影響をなくすためのオレオレ技法がある
  • 「魂」や「熱意」など、ロジカルに説明することが難しいと感じるものがある
  • 指摘事項を指摘するべきタイミングは、個人によって解釈が異なる
    • たとえば例外に関する指摘について、ソフトウェアの設計レビューで行うものだと考えているか、テスト設計のレビューで行うものだと考えているかといったことが個人によってまちまち(この認識がずれた状態でWモデルを採用すると失敗する)


感想

  • ひとくちに「レビュー」といっても、参加者のバックグラウンドが様々異なるため、フォーカスしづらい
  • ある程度ペルソナ的なものを用意して、議論のスタートを揃えたほうがいいかも?


当日のハッシュタグまとめ

togetter.com

第1回 テストもぐもぐ会

とりあえず言いたいこと

オムそばさんの企画力すごい

とりあえず言いたいこと その2

お料理がすごく美味しかった

トゥギャりました

togetter.com

「テスト」にまつわるお題

めっちゃ真面目なお題ばかりでした。すごい。

色々なお題がありましたが、「テストにまつわるお悩み」が多かったですね。

  • いまからテストを学ぶ新人に伝えたいこと
  • テスト管理ツールについて意見交換したい
  • テストって楽しいの?
  • XXなことがあって正直つらい
  • QAが増えなくて悩んでいる

などなど。

プロジェクト全体の見通しが悪いことで自分のロールがわかりづらかったり、自分がコントロールできない領域に対してもどかしさを感じていたり、単純に作業感がすごくて精神的に辛かったり、いろいろお悩みがあるのだなあ。。。と感じました。

僕が用意していったお題は完全に休日向けで、遊び要素しかないものでしたので、また別の機会にもぐもぐお話しできればと思います。

個人的に面白かったこと

ブロッコリーさんやなそさんの話のアプローチがとても面白いなと感じました。 「立ち返りの問い」を投げることで、お題を出した人のお悩みを深堀りし、「お題の再設定」を促していらっしゃったと感じます。

個人的に面白かったこと その2

僕自身は、バグを検出すること自体に快感を覚えるタイプの人間なのだということをあらためて自覚しました。

電源がない会場でメモを取るときは、ポメラを使っています

まつやまです。

先日のテスト酒場で「ポメラ使ってます!」というお話をしたところ、「それ良いかも!」というコメントをいただいたりしました。 誰かのお役に立つかもしれませんので、こちらに書いてみたいと思います。

ポメラとは?

www.kingjim.co.jp

テキストでメモを取ることに特化した端末です。

テキスト入力&保存以外の機能としては、フォルダ作成機能・ファイル名編集機能・英和&和英辞書機能などがあります。

どんなところが良いの?

  • 外部電源を必要としない&それなりに長持ち

ノートPCに比べて圧倒的に長時間使えます(レッツノートとは良い勝負かも)。 僕が持っている機種(DM100)は、単三電池を使いますが、最新機種は内部バッテリーで動くようです。 勉強会の会場は、電源がない場合も多いと思いますので、そんなときに重宝します。

  • 軽くて薄い

(僕が持っている機種(DM100)の場合)重量が400g&厚さ2.5cmなので、持ち運びがとても楽です。 ノートPCに加えてポメラを持っていったとしても、特に邪魔になりません。

微妙なところは?

  • 本体がお高い

最新機種を見てみたところ、¥49,800しますね。正直、お高い。 僕が持っている機種(DM100)は¥20,000くらいだったと思いますが、古い機種の取り扱いはなくなっているようですね。

  • ちょっとタイピングしづらい

ノートPCに比べるとキーの幅が狭いため、どうしてもタイピングはしづらいです。

まとめ

最新機種を買おうとするとさすがにハードルが高いかなという印象ですが、「電源の心配をしなくて良い」という安心感は案外大きいです。量販店だとデモ機が置いてあったりしますので(だいたい電子辞書のコーナーにいる)、ちょっと触ってみてはいかがでしょうか。

書きたいことの圧縮版

まつやまです。JaSSTで一気にお知り合いが増えまして、嬉しい悲鳴をあげております。 書きたいことが色々とありすぎて、ちゃんと書こうとするとずいぶんと先になってしまいそうですので、ざざっとダイジェスト的にまとめておこうと思います。

テストコミュニティのSlackを作っていただきました

yoshikiito.net

なんだかすごいことになっています。以下は伊藤さんのブログからの引用です。

Slackのほうの「はじめまして」用ルームでも出てきましたが、「テストについて、品質について、普段話せる人がいないので、社外で交流したい」という方が一定数いらっしゃるようです。Twitter上なんかだと、テストや品質について話をしている人が目立つこともあって、いたるところに居るような錯覚をしていました。

実際には、職場でもんもんとしたまま、同じ思いを持つ仲間を求めている人がいるということ。なら、場があったほうがいいなと。作ってから気づきました。

この感覚はまさに自分自身が抱え続けてきた悩みで、テストについてはもう何年も「ぼっち」で仲間を求めていました。 転職して、QAと呼ばれる方が世の中にいることを知って、少しずつ「分かり合える人」が身の回りに増えてきたように思います。 これは僕なりの越境だったのかもしれません(何となくいい言葉で締めたかった)。

インフラ勉強会

個人的に、いまものすごく注目しているコミュニティです。

· / インフラ勉強会 Wiki

とにかく参加者の方の熱気&盛り上がりがすごいです。毎日でも参加したくなるくらいです。 いまも、インフラ勉強会にROMで参加しながらブログを書いています。

断片的に覚えていた知識が線になって繋がっていく感覚があって、とても楽しいです。

カイゼン・ジャーニー

たしかデブサミが開催された頃に買った本です。 2/27にワークショップが開催されたので参加してきたのですが、こちらも著者のお二人の熱気に圧倒されまして、何とか社内でも読書会を開けないか企画を考えています。

JaSST 1日目

  • 「NGTの記法を応用した不具合分析からのテストの補強」

フレームワークを用いてつながりの無い要素をつなげ、検知しづらい不具合を検知する手法のお話です。こちらも是非実践してみたい内容でした。

JaSST 2日目

状態遷移図を用いて仕様を見やすくする手法のお話でした。数学的な抽象化を用いた記法や、独自言語のお話もあり、こちらもしっかり時間をとって復習しなければ、、、と思う内容でした。「ツールに読ませるためにデータ化する」というのは、やはり大事な考え方だなと感じました。

  • 「組織改善のためのPMOのあり方とPMOの育成に関して」

PMOの分類や育成についてのお話を伺うことができました。PMOってどうしても事務屋さんなイメージがつきまとうのですが、何だかなあ。。。と思います。本来もっと魅力的でリスペクトされるべき役割であるはず。

  • Clova Friends

まさかの抽選に当選してしまいまして、Clova Friendsをいただいてしまいました。Google Homeとはちょっと異なる特性を持っていて、特に、ちょっとした人間くささみたいなものを感じることがあります。意外な言葉に反応してくれると本当に面白いですね。マンガネタは結構刺さりました。

基調講演と同様、辛辣な正論を真正面からお話しいただいたという感想になりました。テストを書くということをきちんと学ばなければ、という思いをあらためて持ちました。

今回のJaSSTで最も「ついていくのに必死(というかお話についていけない)」セッションになりました。トップ企業のコンテキストを理解したうえで聴講しないとダメ。それでも、ハッシュタグの実況解説のおかげで、最後まで諦めずに聞くことができたと思います。

最後の山口さんのコメントは、とても印象的でした。

「他人の答えを借りる前に、自分たちで何をやるべきかをきちんと具体的に考えて、それをきちんとやりきることが大事でしょう。私たちが特別だとかそういうことじゃない(意訳)」。

他人から借りてきた答えは便利な道具ですが、その便利さに呑まれないよう自戒したいです。

技術的な活動いろいろ

そんなわけで、インフラ勉強会を聴講したり、コード書いたり、ターミナル触ったり、いろいろやっています。 もうちょっと時間配分を上げていきたいところです。あと、注力するものを絞ったほうが良さそう。

テスト観点を語る夕べ

kataruyube.connpass.com

2ヶ月ぶりの「語る夕べ」に参加してきました。会のコンセプトどおり、「ビジネスとしてどうすれば効率的か」とかそういった範疇を飛び越えて、「どうやったら気持ちいいか」「テスト観点を出す作業はアート」といった形で話が発散していきました。自分の常識が足元から崩れていく感覚がとても楽しかったです。いくつか質問もさせていただいて、自分の思考プロセスを知る良い機会になったと思います。立ち止まって振り返る(分析する)って、やっぱり面白いなと思います。