ソフトウェアテスト・品質勉強会をもう一度行います! #test_study

今回、ソフトウェアテスト・品質勉強会を再演させていただけることになりました!

再演に至った経緯

実は、勉強会の発表についての解説記事で以下のように書きました。

耳を使うこと前提のスライドになっているため、この記事にいくら書いても、実際に受講しなければ伝わらないような内容になってしまっています…。

また、私自身「もっとこの勉強会を話して、色々な人に伝えたい!」という想いを持っていました。

今回、その想いを受け止めて下さり、場所を提供していただいたため、再演を行うことができました!

勉強会概要

  • 実施日:2018年2月27日

  • 告知ページ

connpass.com

募集は開始したばかりですが、既に多くの方から参加表明を頂いております!(ありがたや~)

気になるという方は是非、参加表明をしてください!

「ソフトウェアテスト・品質勉強会」のアンケートの回答

  • 先日の「ソフトウェアテスト・品質勉強会」で参加者にアンケートを書いていただきました。
  • ただし、それらのアンケートに答えられる場が無かったので、できるだけ回答して載せます。
  • 発表内容等はコチラ

nihonbuson.hatenadiary.jp

今回のような体験、ワークショップを社内のメンバーとやりたい、とずっと思っていました。例題集があったりするのでしょうか? 例題をつくるコツなどあれば、是非教えていただきたいです…!

  • 今回はほとんど、他の勉強会等から例題をパクりました。
  • ただ、私が例題を採用する時には、参加する人のレベルに合わせて、多少変更しています。
  • テストに興味が無い人に向けて行うには、社外勉強会で得たコンテンツをそのまま使わない方が良いことが多いです。
    • 特にJaSSTやWACATEなどで参加して知見を得ると、すぐに「社内に広めたい!」と思ってしまいますが、そこから社内向けに咀嚼するようにしています。*1
    • 例えば、社内に持っていくときには、極力テストの用語を使わないようにしています。難しい用語を持ってきた瞬間、拒否感を示す人もいると思いますので…。
  • ちなみに今回の場合は、そこまでテストが分からない人も対象にしていたので、コンテンツを社内に流用できる形になっていると思います。*2

テスト自動化をプロジェクトの中でどのように実現しているのか

  • 私の個人的な事例をここで紹介することはできません!(ごめんなさい!)
  • ただし、自動化をする時に参考になる資料としては以下の3つがあります。

1. いつどこをテスト自動化するべきか?

  • JaSST'16 Tokyoの講演資料です。
  • これからテスト自動化を始めようと思っている人には絶対に薦めたい資料です!

http://www.jasst.jp/symposium/jasst16tokyo/pdf/D4.pdf#page=5

2. テスト自動化の8原則

  • 今年の3月に行われた「システムテスト自動化カンファレンス2017」にて、このサイトが初めて紹介されました。
  • 実は最近、解説文も加わりました!

テスト自動化の8原則 - テスト自動化研究会

3. 初めての自動テスト

  • 発表中にも紹介した本です。
  • 自動テストを始めるにあたって最初に読むべき本といえます。

www.oreilly.co.jp

QAの育て方を知りたい

  • JaSST'17 Tohokuが「育成」をテーマにしていたので、色々と参考になるかと思います。

JaSSTソフトウェアテストシンポジウム-JaSST'17 Tohoku レポート

実際に1つの対象のテスト設計をしながら、なぜそうしているのかの解説をしていただきたい。

  • まさにそういう内容をしている、「テスト設計コンテスト」というものがあります。
  • 見学するだけでも勉強になると思いますよ。
  • 勝戦が2月24日にありますので、是非見学しに行ってみてください!

aster.or.jp

どの品質特性にあてはまるのか考えるのが難しく、うまくつかうのが難しいと思いました。

  • 品質特性については、先日のWACATEで小井土さんが話していただいたのが本当に参考になりましたので、そちらを確認してみてください。*3

www.slideshare.net

マトリクス、ディシジョンテーブルのテストの効率の良い実施方法などあれば知りたい。

  • ちょうど、自分自身も勉強している最中です。
  • 何かしら紹介できる形になれば、お伝えしたいです。

QAレビューの仕方を知りたい

  • 自分も勉強しているところです。
  • 1月16日にレビューを語る夕べがありますので、ぜひそこでお互いに情報共有しましょう!

kataruyube.connpass.com

テストエンジニアがいない組織の場合、開発者としてどこまでテストを行ったらよいか、気になりました。

  • おそらく、個々人のテストというよりも、組織としてどういう方針でテストをすれば良いか考えた方が良いように思います。
  • そういう話は、テスト戦略を語る夕べや、テスト網羅性を語る夕べでお話できると思いますので、そこで情報共有をしましょう!*4

kataruyube.connpass.com

JSTQBのFLは取ったのですが、ALへの壁が険しすぎます。そういう「脱初心者」の次ステップに参考になる話とかききたいです。

  • ちょっと自分もALを取っていないので、参考になる話ができる自信がありません…。(ゴメンナサイ!)
  • 将来、そういう人向けのお話もできるようになりたいです…!

ペアになって行うワークで、自社以外のテストについて聞いたり、コミュニケーションがとれてよかった。テストについて1人で勉強する気になれなかったが、今日の話をきっかけに勉強への意欲がかなりわいたので良かった。

  • 良かったです!
  • 発表中にもお伝えしましたが、テストについては1人で勉強するのが難しいと思います。社内や社外の仲間と一緒に勉強して、さらに良いテストができるようになりましょう!

テスト技法の話は巷でたくさん見聞きしますが、基礎的な部分を丁寧にしてくださる場があまりなかったので、色々、虫食いの知識を補完できたと思います。

  • 自分も最初は似たような状態で、ここ最近やっと全体感が分かってきた気がするので、それを伝えられて良かったです!

初めて外部の講座に参加したのですが、思っていた以上に楽しめました。

  • 前回の記事で書いたように、楽しんでもらうことを第一に考えた構成だったので、狙い通りの感想を頂けて嬉しいです!

本を読んで学習した内容も数多くありましたが、そこにプラスしていただけるような講義でした。

  • ありがとうございます!
  • (特に発表の前半は)本で読んだだけではなかなか理解しづらいところだったと思うので、参加して持ち帰って頂けたようで嬉しいです!

うちの会社の若手にもきいてほしい

  • ぜひぜひ!
  • 依頼があれば、出張でお話ししますよ!

*1:JaSSTやWACATEに参加している人というのはテスト好きばかりですから…。

*2:ただし、資料を読んだだけだと分かりづらいので、内容をちゃんと理解していないと社内に広めにくいかもしれません。

*3:きっとWACATEでの発表中のワークも踏まえて小井土さんの話を聞いていないと、品質特性の使いどころはわからない気がする。ただし、多分この質問者もWACATEに参加したので分かってもらえた気がする。

*4:勉強会告知ページが出来次第、追記して紹介します。

「ソフトウェアテスト・品質勉強会」での発表時に工夫したこと

先日、「ソフトウェアテスト・品質勉強会」で発表をしてきました。

connpass.com

connpass.com

発表資料

speakerdeckにupしました。

speakerdeck.com

発表時に重視したこと

今回は、「如何に勉強会を楽しんでもらうか」に重点を置きました。

そのため、色々な部分を工夫しました。

自分の頭で考えて、自分で手を動かす

ただ聞くだけの受け身になってしまうと、受講者の理解が進まないことが多いです。

そのため、今回は配布資料も用意し、所々穴埋めにしました。

speakerdeck.com

ちなみに、投影資料の一部で右下に数値を書いています。

f:id:nihonbuson:20171209175810p:plain

これは配布資料のページ数と紐付けています。

受講者に参加してもらう

例題を用意して考えてもらうだけでなく、受講者にも本当に参加してもらうようにしました。

そのために、2人組になってもらい、随所で意見交換をしてもらいました。*1

例えば、以下の例題(投影資料p16)

f:id:nihonbuson:20171209163052p:plain

これは3ステップで実施しました。*2

  1. 自分自身で考えてみる。考えた結果は配布資料のp13に書き込む。
  2. 隣の人と意見交換をする。(自分との意見の違いに気付く)
  3. 私が用意していた内容を伝える。(さらに自分との意見の違いに気付く)

これは、ただ単に説明を聞くだけの場合に比べて、圧倒的に理解度が異なります。

ちなみに、他人と意見交換すると新たな部分に気付けることがあります。

これを教育心理学の用語で「建設的相互作用」と言うようです。

先々月の「教育心理学Meetup」という勉強会でそのことを学んだので、早速活用させていただきました。

educational-psychology.connpass.com

納得感を上げる

より納得してもらえるように、できるだけ具体例を示したり、受講者の考えに寄り添った説明をしました。

例えば、以下の部分(投影資料p9)の具体例2

f:id:nihonbuson:20171209164133p:plain

もちろん、「デジタルニュースの普及」の一言で済ませても良いですが、 「オリンピックで日本人選手が金メダルという話題を次の日の朝刊まで待つことって無くなってきましたよね?」 と伝えたりしました。

また、以下の部分(投影資料p10)

f:id:nihonbuson:20171209164508p:plain

このページを示す前に、「テストの目的について隣の人に話してみて」という指示を出すのですが、その時に私は受講者の話に耳を傾けて意見を拾うようにしています。

そして、その中で出てくる

「きちんと動いているか確かめたいから」

というようなワードを拾ってきて、*3

○○を確かめたい→実装したものありきの話(受講者の考えに寄り添う)→実は「欠陥の作り込みの防止」という目的もある

というストーリーにすると、その後の話も絡めて、最終的に納得してもらえることが多いです。

目と耳を同時に使ってもらう

私は、スライドに詳細な説明を書きません。

また、基本的にスライドの説明をそのまま読むことをしません。

それは「スライドを読む」という目を使うことと、「私の説明を聞く」という耳を使うことの両方を実施してほしいからです。

ただスライドに書いてある内容を読むだけだと、受講者側の集中力も散漫になっていくと思っているのでこの方式を採っています。

一方で、耳を使うこと前提のスライドになっているため、この記事にいくら書いても、実際に受講しなければ伝わらないような内容になってしまっています…。

飽きさせないようにする&本当に伝えたいことを印象づける

聞いている人が飽きないように、また本当に伝えたいことを印象づけるために、言葉の強弱やスピードを調節しています。

例えば、以下の部分(投影資料p8)

f:id:nihonbuson:20171209165709p:plain

ここはあえて、「言葉の強弱をつけない(棒読み)」「速く読む」ようにしています。

そして、「なんだかよく分からないですよね?」と言っちゃいます。*4

一方で、次のページ(投影資料p9)

f:id:nihonbuson:20171209164133p:plain

ここでは、さきほどと真逆に「言葉を強弱をつける」「受講者の人が共感できるように語りかけるような早さで話す」ということを心がけてます。

こうすることで、私がより伝えたいのはp8よりもp9だということを把握してもらうようにしています。

twitter上で、今回の発表内容をマインドマップにしていただいた方がいましたが、私が伝えたかった内容を概ね書いて頂いており、きちんと伝わっていたんだなと感じました。

おわりに

この発表資料自体は随分前に作成しました。

ただ、上記で書いたようなこともあり、「ただ資料公開しただけだとあまり伝わらないな…」と思っていました。

そんな時に、アカツキ様から発表の機会をいただくことができました。

アカツキ様、発表の機会をいただき本当にありがとうございました!

もしも、今回の勉強会に参加していたり、この記事を見て、詳細な発表内容や発表方法について知りたい方がいましたら、連絡を頂ければと思います。

*1:「知らない人と2人組ということに抵抗感がある人がいるかもしれない…」と思っていましたが、アンケートを見たところ、そのような意見を書いた人はほとんどおらず、概ね好意的に受け止めてくれました。今回は参加者に恵まれました。

*2:なお、元々の発表でも同じようなやり方をとっており、私のやりかたは例題の文章を含めて完全なパクリです。

*3:だいたい「○○を確かめたい」「○○を保証したい」というワードは出てきます。

*4:本当は分からない訳ではありません。

テスト戦略を語る夕べ(第3回)の内容をまとめてみようとした #STS1031

告知ページ

connpass.com

目次

テストの在り方を変える軸

  • テスト戦略を考える上で、テストの在り方を変える軸というのが様々存在しているっぽい
  • それらを勉強会の中で話した結果、5個ぐらいはありそう。
    • 実際にはもっとありそう
  • 勉強会の中で軸までを考えたのは以下の5つ
    • 垂れ流し
    • 警察
    • 大富豪
    • コーチ
    • まつお(仮)
  • これら以外にも、「がんじがらめ」「執事」といったワードも出てきてた
  • 今回話した内容についてまとめてみます。

ケース1「垂れ流し」

  • 軸…コストとクオリティ
  • クオリティを維持してコストを減らすために、安いコストの人へ依頼する傾向にある。
  • これを行うと、一見目的が達成されているように見えるが、長期的に見るとコストがあまり変わらずクオリティが下がる結果となる。

f:id:nihonbuson:20171101214029p:plain

ケース2「警察」

  • 軸…規律(自律か他律か)とムダの許容度
  • ルールを作り、クオリティゲートによって監視するやり方。
  • 監視が強くなればなるほど、他律の組織になり、物事のムダが多くなる。
    • レビューでくだらない指摘をする必要とかも出てくる。
  • 監視が強い(他律&ムダが多い)状態をPMOはする傾向にある。
  • 逆方向(自律&ムダが少ない)状態になれば幸せなように見えるが、人月商売で成り立っているSI系がこの傾向に移るのは稀。

f:id:nihonbuson:20171101214804p:plain

ケース3「大富豪」

  • 軸…技術的先進性と定着度
  • 金にモノを言わせて解決するやり方。
  • そのまま放置すると技術的先進性は勝手になくなっていく。
    • 常にアップデートが必要。
  • 上手くいくと、技術的先進性を一定以上キープしつつ定着度が上がっていく。
  • ただし、ツールの導入に関わっていた人などがいなくなり、上手く伝承されないと、ツールが陳腐化し、定着度も高まらなくなる。
  • もしくは陳腐化したツールを意図も分からず使い続けて埋もれる。

f:id:nihonbuson:20171101234638p:plain

ケース4「コーチ」

  • 軸…学ぶ機会と納得感
  • 共に汗をかくタイプ。ちょっと離れてサポートする執事型はこれの亜流。
  • 学ぶ機会が増えることで、徐々に納得感が出てくるはず。
  • 学ぶ機会が増える方法の一つに、リリース間隔を狭める考えがある。

f:id:nihonbuson:20171101235154p:plain

ケース5「まつお(仮)」

  • 軸…信頼感(距離感の逆数)とサーバントシップ
  • 最初は縦割りで信頼感も無い状態
  • 信頼がお互いにできるようになると、さらにお互いを支え合うような仕事の仕方になる。
  • そこから組織が変わる(人が増えたりする)と、信頼感が減りC&Cになりがちだが、その時の経過からまたサーバントシップに向かえるようになるのが理想。

f:id:nihonbuson:20171102000026p:plain

感想

  • 今回は5つのケースを話しましたが、他にもまだまだありそうな予感です。
  • 自分の会社・組織ではどのケースに当てはまるのかorまた別のケースに当てはまるのか考えてみるのも面白いかも

勉強会中にホワイトボードに書いたメモ

明日はJaSST Kyushu

JaSSTソフトウェアテストシンポジウム-JaSST'17 Kyushu

  • そういえば、明日はJaSST Kyushuです。
  • 基調講演では、中野さんがQAの組織としての取り組み事例を話して頂けるようなので、今回の勉強会とも照らし合わせてみるのも良いかもしれません。*1

*1:気になった方へ。当日券もあるみたいですよ!

Veriserve - WebQA FunNight!! #01 #WQFN01

告知ページ

veriserve.connpass.com

はじめに

  • このイベントでは、テスト管理クラウドサービス QualityForward のアジャイル開発において、どんな取り組みを行ってきたか、「守」「破」「離」の3点に分けて紹介していました。
  • なお、最初の話と、最後の話は諸事情により記録できていません。*1ご了承ください。

目次

登壇者紹介

  • 開発:遠藤大介さん(ソニックガーデン)
  • テスト:大竹未紗さん(ベリサーブ)
  • PO:松木晋祐さん(ベリサーブ)

  • 以下の3点を行った。
    • 仕様を徹底的に議論する
    • 環境を最新に保つ
      • RailsのVersionをガンガン上げるとか
    • テストをちゃんと書く

仕様を徹底的に議論する

  • PO(松木さん)がまずやりたいことを持ってくる
    • ビジネス的に何を実現したいのかについて、松木さん流に話す
  • 中にはソフトウェア的に作るのが難しいことも
    • 開発者(遠藤さん)が「後々ガンになるよ」と伝えるようにしている
  • 要求に対して色んな実現方法がある
    • ソフトウェアにとって優しい、優しくない
    • ユーザーにとって優しい、優しくない
    • これらの調整がエンジニアの腕の見せどころ
  • 僕のオススメはこれ、と提案する
  • どちらかが折れるのではなく、対等に議論する
  • 週に2時間超のMTGをしているが、殆どがその議論

  • 松木

    • 変な仕様ってある?
  • 遠藤
    • いっぱいあるんですけど(笑)
    • テストスイートにタグを付けたいという議論とか。
      • 実際あった会話
        • 遠藤「何のために付けるの?」
        • 松木「目的のテストスイートを見つけるためにタグを付けたい」
        • 遠藤「タグの管理が破綻するよ」
      • タグのシステムは簡単なのですぐに作れるが、ユーザーは使いこなせないと思った。
  • 作るのもメンテも大変ではないやり方を選び続けて1年半経った

環境を最新に保つ

  • 技術は日進月歩
  • セキュリティ的に固くしようと考えると、フレームワークも最新にすることになる
  • 古いVersionだとセキュリティパッチも当てられない、使いたいライブラリが使えない
  • しょっちゅう、ライブラリを最新版に上げろと言ってる
  • 毎週リリースしているとリファクタするのを後回しにすると絶対にやらなくなる
    • →毎週リファクタをする
      • Redmine連携をした後に、JIRAなどにも対応できるようという要求があり、連携部分を抽象化した
  • ベリサーブ社内用のツールとして開発していたためシングルテナントで作っていたが、他の会社でも使いたいと言われた
    • →2週間でマルチテナント化した
  • 松木「ペースが落ちたことはない」

自動テストをちゃんと書く

  • カバレッジを100%を目指すのは辛い、C1を85〜90%でキープしてる
  • ライブラリのVersionを上げると挙動が変わるが、それを恐れてたらVerUpできない

    • 大事なのはすぐに気付けること
  • 今回開発したサービスだと権限毎のふるまいが違うので、その関係性を整理した上で自動テストを描いたりした。

  • 自分でできるところが守る、ただそれでも気付けないところはベリサーブさんに助けてもらってる

  • 松木「日付をまたぐテストの書き方についてなどは勉強になった。」

  • UIテストはどうやってる?

    • ブラウザで触った時の挙動については、Railsなのでcapybaraでやってる
  • ヘッドレスか実ブラウザでやるか?

    • 殆どがヘッドレス。たまに実ブラウザでテストする。
  • システムテストの成長系+αをプログラマに守ってもらってる

質問

Q 結構リッチなUIを使っていると思っているが、フロントエンド側は?
  • A フロントエンド側は書きづらい。例えば、スプレッドシートの自動化は流石にコストがかかるので、効率的な部分を優先にやっている。
Q リファクタリングの(時間的な)割合は?
  • A 空気を吸うようにやってる。ソニックガーデンの場合は、コードレビューを必ずやっているが、そこでも指摘があったりするので、リリース直前でもやってる
Q コーディングとテストコードの比率は?
  • A テストコードが1.5倍ぐらいある。テストコードの方が圧倒的に多い
Q マニュアルでテストすることはあるか?
  • A TDDに向いていないものもある。
    • 完成形が見えていないものとか。
    • そういうものは触りながらやる。
    • 逆に権限周りでガチガチに決まっている場合はテストコードを先に書く
Q テストコードとプロダクトコードは別リポジトリ
  • A 同じです。
Q CIってどこでで回ってる?master側?develop branch側?
  • A 手元では開発側で回してるし、masterでもstagingでも回してる
Q 環境を最新に保つとあったが、最新Versionの環境ではライブラリが使えないような場合はどうするのか?
  • A いくつかパターンが分かれる。
    • デグレって使えない
      • プルリクを投げて対応
    • 思想から外れるのでコードから外された。
      • 乗り換え先を検討する。(別ライブラリを探す)
Q 松木さんが「ペースが速い」と言っていたが、ペースの速い、遅いの判断はどうやって?
  • A 完全に松木さんの主観。
    • 今まで関わってきたプロジェクトと比較すると圧倒的に速い。
    • 速い場合、時間が経つと落ちてくるが、全然落ちない。
    • 最初からトップスピードで、その速度をキープしている感じ。
    • 逆にどんどん加速していくことも無い。
      • これ以上速くなるとPOが保たない
Q VerUpで不具合が見つかるタイミングは、自動テスト以外にあるか?
  • A ある。その時は、テストケースを足したりQAが観点として足したりする。
Q ドメイン知識が無い人がコードレビューをしていても回るか?
  • A いかに読みやすいコードを書くかを会社全体の流れとしている。
    • ビジネス的なものをコードレビューで見るのはそもそも難しい。
    • 「セキュリティ的に大丈夫かどうか」「読みやすいコードかどうか」を中心にレビューしている。
  • 権限周りのコードレビューだと松木さんに相談したり。
  • 松木「複雑な要求なのにコードが綺麗すぎるので、逆になんかあるのでは?と思ったりした。」

  • エンジニアが守っていた後に流す。テストエンジニアが破る。

バグランク

  • バグランクを予め決めている。
    • S セキュリティ、データ消失/破壊、システムの価値を致命的に損なう
    • A システムクラッシュ、復帰不能例外、システムの本質的な価値を毀損する
    • B 機能不具合、例外、ほか頻繁に利用されるケース
    • C 目立つ表示崩れ、軽微なユーザ期待との相違

テストサイズ

  • 変更内容によって、テストのサイズも決めている
Sテスト
  • 以下のような変更はSテストで対応
    • 軽微な変更
    • データの書き込みを伴わない変更
    • 表示される情報がユーザーにとってクリティカルでない変更
  • →製品知識が豊富なテスターのアドホックテストで対応
Mテスト
  • 以下のような変更はMテストで対応
    • 主要機能の追加や変更
    • データの書き込みを伴う機能
  • →テスト分析、設計、設計レビュー、実行、レポートのプロセスを通すようにして対応
Lテスト
  • 以下のような変更はLテストで対応
    • セキュリティ
    • データ毀損のリスクを伴う機能
    • ユーザーにとってクリティカルな情報を扱う機能の変更
  • →仕様、影響を網羅するためのモデルから作る

出来上がった最小の製品に対してリスクベースドでテストスイートを作る

  • 最初から1ヶ月ぐらい経ったときにまずは作った
  • 「ユーザーがどれ位ショックか」と「この機能はどれぐらい複雑か」の積でスコアを算出し、優先度を決めた

変更部分について影響範囲分析に基づくテスト設計と実行

  • 機能が加わったり、変更があったら、どれぐらい影響が表すかを図にしてまとめた
    • この機能を動かしたらどこに影響があるかについては矢印で表現した
      • 矢印の1本1本がテスト条件になっている
    • 例えば、ケースを作成した時に、「出力ができる」ものがあればエクスポートの機能に影響を与えるとか

Lテストの場合はPOと一緒に仕様のモデルを整理する

  • 「なぜこんな仕様になっているのか?」「どういう思想なのか?」を徹底的に共有
  • Lテストを実施する時は救援のQAも呼んで実施
  • ユーザー権限は非常にクリティカルなので、Lテストを実施した
    • 横の権限、縦の権限というモデルを一緒に作った
    • この仕様とモデルにおいては、画面、ユーザーメニュー、機能実行×権限の昇格&降格の組み合わせで網羅できることを発明した
  • 納得できる網羅を毎回発明している
  • このモデルを作ってテスト&修正を行った結果、その後、テストエンジニアのエースが1週間やってもバグを1件も見つけられなかった
Q Sテスト、Mテスト、Lテストの比率は?
  • A 5:3:2ぐらい

  • 製品に対しての問い合わせの対応は、QA側で行っている。
  • 開発側にはフィルタリングした情報のみ来る
  • 開発が集中にしてくれる環境になってる。
    • 遠藤「POからすると『作らないなー』と思ってそう。」
    • 松木「最初の3,4ヶ月は本当にそう感じた。今では慣れた」
      • 今回のサービス(テスト管理クラウドサービス)の提案を最初にソニックガーデンに伝えた時に「エクセルでいいじゃん」と言われた。
      • プログラマがガンガン言うことで内容が洗練されていく

おわりに

  • 最初にも書きましたが、これ以降は諸事情により記録が出来ていません。
  • ただし、ここに書いた内容以外にも様々な質問が飛び出して、大変面白い&タメになるイベントでした!

*1:最初は電車遅延で会場に間に合わなかったのと、最後はピザを食べながらだったのでPCを起動して記録していなかったためです

継続的E2Eテスト #Seleniumjp

スライド

www.slideshare.net

はじめに

  • 自動テストを継続的に行うのって難しいですよね?
  • 自動テストはキャズムを超えた
  • やり始めるのは簡単だが、継続していくというのは大変
  • 技術的な話というよりも、運用で気をつけてきた点を話す

継続のポイント

  • メンテナンスコストがかかる

メンテナンスコストがかかる

  • テストが動かなくなった
  • NGが多発する
    • テストの分析が走るはず
    • 分析そのものが時間がかかる
      • テストを諦めてしまう
    • SUT updateをする
      • これも時間がかかる
      • リリースサイクルが早いと、メンテナンスコストが追いつかない
    • テスト環境が変わる
      • これを意識しないと大変なことになる
      • 対応してSeleniumそのものバージョンを上げたりする
  • メンテナンスするものはたくさんある

メンテナンスを効率よくするために行っていること

  • 毎日動かす
    • リリースが毎月1回とかでも動かす
    • 動かしていないと大変
    • 変化に敏感になる
  • 不安定を排除する
    • 特にテスト環境
    • WindowsのOSを再起動する
      • 溜まっていくメモリを開放するため
  • 常に調査する
    • OSSのバグなどを敏感に知っておく
    • ナレッジ化して社内の人が知っておくようにする
  • 対応の速さ
    • テストが落ちた時に、次の実行までに解決するようにする
  • メンテナンスしやすい仕組みにする
    • OSSSeleniumでページファクトリーでメンテナンスしやすくするのもそう
    • Updateした時に動作確認をする場所が常にある

テストの価値が低下する と感じる要因

  • デグレが見つけられない
    • テスト設計・実装の見直しを積極的に行う
    • 実行頻度を開発プロセスと同期する
      • 開発者が意識していくと、「テストが○時に動くので、それまでにMRを通そう」となったりする
  • NGが多すぎる

    • 環境起因でのNG
    • メールの表題が毎回同じだと、鈍感になったりする
  • 自由にテスト実行ができない

    • テスト実行環境を複数用意する
    • 自分で直した時に確認できるようにする

テストが継続しない最大の要因 = 担当者がいなくなる

  • 「部署は残っているのですが、担当者がいなくなったので一から作り直しています」とかある
  • 自動テストは属人化する
  • 一つの案件に対して複数人をアサインするようにしている

Let's step into the OSS community #Seleniumjp

スライド

www.slideshare.net

クックパッドについて

  • 日本だけでなく世界でもサービスを提供している
  • Rubyを使っている

OSS活動について

  • 今はOSSに貢献している
  • 入社前は全然コミットしていなかった
    • 利用していただけ
  • 最近はどんどんOSSのコミットをしている
  • Appiumのコミットを盛んにしている

Appiumのコミュニティについて

  • 様々な人が存在している
  • コミッター
    • Rubyのコミッターの一人として松尾さんがいる
    • あくまでもコミュニティの一つのユーザー
  • 質問に回答している人もいる
    • Githubのissue
    • Appiumのdiscussionのサイト
    • Appiumに関するチャット
      • コミッター同士ではSlackで行っている

OSSの貢献について

  • 松尾さんの最初のPRはiOS8の不具合修正(2014 Oct 14)
  • タイポ、スペルミスなどのプルリクも貢献のカタチの一つ
    • 例えば、Elixerでは、コロンが抜けていたのでPRを送った経験もある
    • OSSをメンテしているのも人なので、間違いはある
  • 慣れていくと、もう少し大きな修正をしたりする
    • Google/earlGreyでは、大きな不具合修正をした
    • リリースノートに自分の名前が載った!
  • 質問に回答したりケアするのもOSSの貢献の一つ

  • OSSの貢献では英語が主体にはなる

    • このSeleniumコミュニティのように地域ごとにあるコミュニティもある
      • 英語が苦手なら、こういうコミュニティに入ってケアするのも貢献の一つ