yoshitake_1201’s diary

テストのこととか、ペンギンのこととか書きます。

JaSST'19 Tokyo F3「赤い会社のテストエンジニアたちが語りつくす~テスト現場で起こるリアル課題と対処策~」の参加ブログ #JaSST19Tokyo #JaSST

講演内容

タイトル:「赤い会社のテストエンジニアたちが語りつくす~テスト現場で起こるリアル課題と対処策~」
URL:http://jasst.jp/symposium/jasst19tokyo/details.html#F3

講演資料

パネルだったので資料はありませんでした。

講演中のツイートまとめ

togetter.com


JaSST'19 Tokyo、F3「赤い会社のテストエンジニアたちが語りつくす~テスト現場で起こるリアル課題と対処策~」の参加ブログです。
講演中に私がおぉ!と思ったことや、自分でまとめたいと思ったことなどを中心にしています。
なので講演全体を網羅したものではないです。

以下、まとめです。

SHIFTさんのCM!

vimeo.com

www.shiftinc.jp

あったんですね。
福岡では流れてないのか(流れてるけど自分がテレビを見ていないからなのか…)私は初見でした。
かっこいいCMでしたね。
テスト業界の会社がテレビCMを流すっていうのはなかなか斬新な取組みだなぁと思いました。

本当に1,500万円もらったいる人がいるんですか?

パネラーの方々のコメントはノーコメントでしたけど(笑)
「知りたかったら入社して〜」っという返しはうまいなぁと思いました。

「〇〇であること」は「〇〇ではないこと」が抜けていることが多い

なのでフローチャートなど使って教えたりしている。と。
このあたりチームメンバーとの関係性次第な気もするので、テストケースのレベルが難しいよなぁと思いました。

アジャイルな現場の場合「会議にとりあえず来てね」をなくす

これは個人的には意外でした。
(ここで佐藤さんが使われた「アジャイル」の定義にもよるんですが)。
「開発 → テスト → リリース」のサイクルが早い現場と想定したのですが、伝達コスト的なところもあるだろうから、会議は全員参加 → 短く終わらせる、というようなイメージを持っていたんですよね。
ただこういった話は状況や目的によって全然違うので、細かい背景も聞いてみたかったです。

「これまで経験した一番の無茶振りは?」という質問に対して

「プロジェクトが燃えてる」って聞いたから現場に行ってみたら「やることがなかった」という話は印象的でした。
確かに燃えてるんだろうけど、どうしようもないですよね。
その後どういう対応したのかまで聞きたかった。

感想

パネラーの4人の方々はロールや経験年数が違ったこともあり幅広い意見が聞けたのでよかったですね。
欲を言えば、新人教育についての具体的な話や、テスト設計の具体的なアプローチなど聞いてみたいなぁと思いました。
個人的には鈴木さんが現場レベルの話を忌憚ない感じの話をしていたのが良いなぁと思いました。
だめなことはだめ、できないことはできない…など。

来年もパネルセッションしてほしいですね。
パネラーの方々、ファシリテーターの方々、ありがとうございました!

JaSST'19 Tokyo D2「あなたに捧げる~TPI Nextを活用したチームメンバーの問題意識から始めるテストプロセス改善【導入時:改善計画立案編】リターンズ」の参加ブログ #JaSST19Tokyo #JaSST #jasstd2

講演内容

タイトル:「あなたに捧げる~TPI Nextを活用したチームメンバーの問題意識から始めるテストプロセス改善【導入時:改善計画立案編】リターンズ」
jasst.jp

講演資料

こちらからダウンロードできます。
www.software-quasol.com

講演中のツイートまとめ

togetter.com


JaSST'19 Tokyo、D2「あなたに捧げる~TPI Nextを活用したチームメンバーの問題意識から始めるテストプロセス改善【導入時:改善計画立案編】リターンズ」の参加ブログです。
講演中に私がおぉ!と思ったことや、自分でまとめたいと思ったことなどを中心にしています。
なので講演全体を網羅したものではないです。
※ 特にTPI Nextと至るところに書かれていますが、このブログではTPI Nextにはほぼほぼ触れていません。

以下、まとめです。

「疑ってかかって!」

スクリーンショット - a0620582af19cdb49b0b5f058b2f3c75 - Gyazo

講演資料P4より

講演中、様々な場面で度々この言葉を安達さんが言われていました。
そもそも、TPI Next公式トレーニングを受けてないから…と資料にはありますが、その他にも似たような文脈で以下の言葉を使われていました。

  • 「"モデル"は体系的なものだから一般化されている」
    • 端折っていることに注意
  • 「書いてあることだけを信じないでください」
  • 「(モデルが)合わないと思ったら捨てていいんです」

発表されている内容や紹介されているモデルは全部が全部正しい(= 自分たちの組織に合う)かはわからないので、「とりあえず信じること」はやめようね、気をつけようね という意味で使われているんだろうと私は感じました。

プロセス改善の位置づけ(分類)

スクリーンショット - ce65347f1f63b0eef74295767cfdd002 - Gyazo

講演資料P9より

自分の周りでは、「改善」といえば「製品品質改善」をイメージする方が多いかと思っています。
が、プロセス改善というのもありますよね。
(どちらも大事なんですが、個人的にはプロセス改善の方を重要視しています)

こういった分類については、以下のセッションでも似たような話が出てきました。

プロセス改善モデルの改善が失敗しやすい原因

プロセス改善モデルは失敗しやすい、という話がありました。
その原因は 「プロセス改善モデルスコープを勘違いしているから」
というのが1番の原因かなと私は認識しました。
(現に私も失敗したことがある勢の1人です)

以下は「問題・課題ベースの改善」と「プロセス改善モデルベース改善」の特徴の違いをまとめられた表と、P17、P83、P86を参考に私が作った図です。

スクリーンショット - 132c18d5a0e700dc5b66c4b292a5651a - Gyazo

講演資料P10より

スクリーンショット - ecbae2bd47e5b9d90ad87daee3ca9a4b - Gyazo

講演資料P17、P83、P86を参考に作った図

注意したいポイントは以下です。

  • 「人の感情部分」は「プロセス改善モデル」のスコープ外
  • モデルなので一般化されている
    • 大事なこと以外は端折ってる
    • 自分たちの背景・実情と異なることが多分にある

これらのことを認識しない状態で「モデル = 銀の弾丸」と思って使うのでだいたい失敗してしまうとなるのかなぁと。

またモデルを読んだ人が「こんなん使えないよ」と言うのを私はたまに聞くのですが、その多くは「モデルに具体的なことが書かれていないから」という意見が多かったです。 ただ、そもそも「モデル = 体系的」なものなので、その意見はその通りですよね。 「現場を良くしたいけどゴールも見えずどうしたらいいかわからない」というときに「モデル」を使うと良いなぁと思いました。

「問題・課題ベースの改善」と「プロセス改善モデルベースの改善」のハイブリットなアプローチ

これが今回の事例だそうです。
どちらか片方ではなく、両方使うということでした。

「感情は論理に勝る」

講演資料P83より

講演終了間際、↑のページで安達さんが強く言われていたのがこの言葉です。
講演資料や↑の図にある通り、「(現場の)人の感情」はプロセス改善モデルのスコープ外です。
だから どれだけ論理的にモデルを説明しあるべき姿を説いても、最後の最後に「嫌なものは嫌」と言われたらそこで終わるんです、と。

このことから改善の始めの一歩を踏み出すときに失敗する多くの原因は↑なのかなぁと思いました。
(自分が失敗した原因もこれにあたるかなぁと)

※補足
今回発表された事例は「改善意識がある方が1人、その周りはそこまでの意識はない」という現場の事例でした。
だからこのことが強く書かれていると思いました。
また改善の大きな悩みの1つに「メンバーや自分の感情(モチベーション)の維持」があるとも思いました。

事例の中でTPI Nextを活用したのは3ヶ所

講演資料P80より

今回の事例(アプローチ)のSTEP全体像が↑です。
その中でTPI Nextのエッセンスを使ったのは3ヶ所だけでした。
TPI Nextを活用したのも、事例当事者である中山さんがたまたまTPI Nextを使っていたから活用してみた、という感じだそうです。

なので、TPI Nextを使わないほうがいいなら(使わなくてもいいなら)無理に使う必要はない。と言われていました。
最初に言われていた、「合わないなら捨てていい」ということを強調されている感じですね。
感情に重きをおいて、プロセス改善モデルで手段を探す、素敵なアプローチだと思いました。

TPI Nextについて

TPI Nextを読みやすくする背景

スクリーンショット - f4d71d4106947693f37b211f6d7cab5f - Gyazo

講演資料P29より

この図のような組織のテストチームに所属していると思ってTPI Nextを読むとわかりやすいよ。と言われていました。
確かに、TPI Nextは組織全体像やステークホルダとの関係を意識しないと読みときづらいなぁと思っていました。
ありがたい背景です。

TPI Nextの注意点 = たくさんの場所に散ってる

スクリーンショット - d6ab9d2ac6c261b4bddab2196aee0d28 - Gyazo

講演資料P45より

キーエリア名と内容が一致していない場合があるとのことでした。
講演中は時間の都合で↑の一番左のものだけ質問となりました。
会場では、「手法の実践」「テストケース設計」の順で手が多く上がったと記憶していますが、正解は「テスト担当者のプロ意識」に存在するでした。

なぜこの分布になっているのかを考える

スクリーンショット - ad2bde977a0965d03341a2313dd34895 - Gyazo

講演資料P31に赤枠と赤字を足したもの

↑の資料は、講演資料P31に私が赤枠と赤字をつけたものです。
なぜ「テスト業務の専門性」のAやB(初期レベル)が少ないかな?
そう思って見てみると、初期レベルでは「テスト業務の専門性」よりも「利害関係者の関係」や「テスト管理」を重要視しているからと読めるよね。
という安達さんの見解でした。

私はこういう風に意識して読んだことがなかったので、かなり腑に落ちました。
その視点で見ていくと、「利害関係者との関係」はどのレベルでも基本的に満遍なくプラクティが分布されているので、定常的に重要(なによりも大事)と読めるかなぁと思いました。

TPI NexTは人に着目している部分が多い

スクリーンショット - d90aa61609036e36a19b2aaae5158454 - Gyazo

講演資料P43より

体系的なモデルなのに技術だけでなく人に着目していてバランスがいい、という話でした。
話は変わりますが、JSTQBシラバスの中でも人に着目する要素がかなり出てきますよね。
最初受験したとき(2年前ぐらい?)は「資格試験なのになんで人間関係?」と思ったんですが、今となってはその理由もこれと同じかなと思います。
テスト業界全体として、人間関係(ステークホルダー、テスト実行者、テストリーダー、テスト管理者など)に重きをおいているんだなぁと感じました。

感想

「改善活動」について詳しくまとめられた発表で、とても勉強になりました!
個人的なことですが、最近「改善」という言葉があまり好きではなかったんです。
ただ講演を聞く → 知人に講演内容の説明をしたおかげで、改善活動にも種類があるなぁと気づくことができ「改善」という言葉が少し好きになりました。
(改善は、お悩み解決と研鑽に分けられる、と今の自分は考えています)

「モデルが作られた背景を考える」「なんでこの分布になっているか考える」といった視点を持っていなかったので、その視点を知れたのがよかったです。
モデルなどの文章を読むと、難しい言葉で短く書かれているので「それが正しいか?」などの思考が止まっていたなぁと。
なので、今後は疑いながら噛み砕きながらかかろうと思いました。

安達さん、講演ありがとうございました!

参考

※ TPI Nextの監査ツール日本語版が公開されています。
以下のサイトからダウロードできます。
www.tmap.net

※ JaSST'17 Hokkaido 中山さんの事例
jasst.jp

「あのチーム」のフレーズを教えてくれるボットを入れてみた話

こんにちは。
福岡でテストをしているyoshitakeです。
前任のテスト担当者と入れ替わる形で昨年5月に今の会社に入社。
その後11月に @sae というテスト仲間が1人増え、現在結成4ヶ月、メンバー2人のテストチームで日々業務に臨んでいます。

今回の内容は、最近チームのSlack Channelに取り入れた「あのチーム」のフレーズボットについての紹介になります。

「あのチーム」ボットとは?

speakerdeck.com

speakerdeck.com

上記の資料で紹介されている「あのチーム」が日頃よく使うフレーズを定期的に教えてくれるボットです。
教えてくれるフレーズは以下の16個からランダムに1つです。

  • うまくいったらどうなるの?
  • なにしてるの?
  • えー
  • できそう?
  • なんでやるんだっけ?
  • 早く見つかってよかったねー
  • 再現させたらわかるの?
  • なんでできると思うの?
  • 自分で触ってみた?
  • なにが大事じゃないの?
  • 多数決で決める?
  • やりたくないの?
  • どこが自信あるの?
  • がんばらないで!
  • みせて
  • わかんない

※ そもそも「あのチーム」とは? については上記のスライドを参考ください。

入れようと思ったきっかけ

ある日のMTG中、僕が@saeに「あのチーム」のフレーズを使ったことがきっかけでした。
(その時使ったのは「うまくいったらどうなるの?」だったと思います)
@saeが「なんでそういう言葉知ってるの?」と聞いてくれたので、上記の資料の紹介と説明をしました。 すると「こういうフレーズ言えるようになりたいよねぇ」と言ってくれたので、どうやったら身につけられるかを考えた結果、今回のボット導入しようか、となりました。

しかしボットは形骸化しがち…

定期的に同じ内容のフレーズを通知するだけのボットが形骸化しがちというのはあるあるかと思います。
今回のボットはそうなって欲しくないので、形骸化しないために +αで別の要素を追加することを考えました。

どんな要素がいいかなぁ…と悩んでいたところ、「あのチーム」のテスター miwa(@miwa719)さんといえば…

そうだ、スタンドだ!と思いつき、メッセージが通知されると立ち上がるという要素を盛り込みました。
工数入力を促すメッセージもついでにお知らせしてもらうことにしました)

通知は11:00、15:00、17:00の1日3回としました。

実際のチャット内容

こちらです。

f:id:yoshitake_1201:20190224130006p:plain

スタンド!の流れから、アイコンとお名前はmiwaさんご本人のtwitter iconとIDをお借りしました。
(ちなみにUninoteというのは弊社で使っている社内製の工数入力システムです)

入れてみた結果

よかったこと

  • 立ち上がることで意識を切り替えることができる
  • 立ち上がってからメッセージ内のフレーズについて少し意見を交わせる
  • 通知回数と時間がちょうどいい

+αでスタンドを入れたのが良かったなぁと思ってます。
そもそもスタンドすることがいいですね!
立ち上がるとPCから目を離せるのでいい意識の切り替えになりますし。
また、席が隣なので立ち上がることで話す時間も取れることができるというのもいい感じです。
軽く話し終わったら工数をつけてそのまま仕事に戻っています。

そして、通知時間もいい感じでした。
集中しすぎようとしている、または気が抜けそうになっている時間に通知されるので、いい息抜き & 気持ちを入れ替えるのに役立っています。

アイコンと名前をmiwaさんにしたことのいい効果

最初は流れでmiwaさんにさせてもらったのですが、実は想定外のいい効果が生まれました。

  • スタンドを必ずやる(miwaさんに言ってもらっている気になるので断れない)
  • 自分のチームにmiwaさんがいると感じる → なんとなく安心感が生まれる
  • 自分のチームにmiwaさんがいると感じる → もっとテストしよう!と身が引き締まる

ただのてきとうな画像や「あのチームボット」などという簡素な名前だったら、たまにサボっていただろうなぁと思います。
しかしSlackの表示的には「miwaさんがスタンドを促してくれている!」となるので、サボろうという感情はなくなりました(これまで2人とも1回もサボってません)。
どんなことをしていようと2人がいきなりおもむろに立ち上がるので、周りの人からは変な妙な目で見られているかもしれませんが…(笑)

加えて、チームのチャットルームにmiwaさんが登場する(ことになる)ので、どこか安心感と一緒に身が引き締まる感じを得ることができました。
「あのチーム」を少し体験している気になっているのかもしれません(笑)

おわりに

今回この内容をブログに書いて公開してもいいですか?とmiwaさんご本人に相談した所、快く承諾してくださいました。
miwaさん、本当にありがとうございます!

それぞれのフレーズがどういう意味合いで使われているのかは、上記の2つのスライドと「エラスティックリーダーシップ ―自己組織化チームの育て方」という書籍内で、「あのチーム」のメンバーであるseki(@m_seki)さんが一部紹介されています。

エラスティックリーダーシップ ―自己組織化チームの育て方

エラスティックリーダーシップ ―自己組織化チームの育て方

詳しく紹介されているフレーズはこちらです。

  • うまくいったどうなるの?
  • 早く見つかってよかったねー
  • 再現させたらわかるの?
  • わかんない
  • やりたくないの?

ちなみに私達は、資料で詳しく紹介されてないフレーズが通知されたときは「こういう風に使ってるんじゃないかな?」と想像しながら意見交換しています。
(なお、我々の中では「多数決で決める?」というフレーズは、「このままだと多数決になっちゃうよ、それでもいいの?」という感じで使っているんだろうという結論になりました。今度ご本人たちにお会いしたときにどういう感じで使っているのか聞いてみようと思っています)
このフレーズを自然に使えるようになったり、自分たちで新しくフレーズを生み出せたりして、よいチームになったらいいなぁと思ってます。

それでは、ここまで読んでいただきありがとうございました。

転職後7ヶ月経過してから転職当時を振り返る

こんにちは。吉武です。
今年の5月に今の会社に転職したんですが、半年ぐらいたったのでいろいろ整理するために、当時を振り返りを書いてみます。
(5月に退職エントリも転職エントリ書いてないですけどね(笑)

前職の私(2015年10月 ~ 2018年4月)

当時私はゲーム会社のテスターでしたが、その会社はテスターの派遣も行っており、私は入社したあとすぐに大きな会社に派遣されました。
そこでかれこれ2年半、1つのサービスを10人ほどのテストチームでテストしていました。
派遣されてたんですが、あまりそういうのを気にすることなく、自由度もあってやりやすかったです(勉強会などもやらせてもらえましたし感謝でした)。

前職で思ったこと・やったこと

この当時のテストチームのリーダーさん(QAさん)が、めちゃくちゃお仕事できる方だったんですよ。
なので、その方みたいになりたいと憧れて、テストを勉強しようと思いました!
しかし、いかんせんその当時は、テストやQA(品質保証)について本当に何も知らなかったので、どうやったらテストがうまくなるのか?と悩んでました。
そんな中JaSST(ソフトウェアテストのシンポジウム)の存在を知ったので、「全国のJaSSTを回ればテストの知見が得られるかもしれない」と思い立ち、2017年4月のJaSST新潟から全国を回りました(最終的に2018年の5月のJaSST東北まで連続参加できました) 。

そのときのことについては、WACATE 2018夏のBPPセッションで話させていただきました。

www.slideshare.net

このJaSST行脚中、行った先々で知ったことをテストチームにFeedbackさせてもらったりもでありがたかったです。
またJaSSTを通じ全国を回った結果、テストの知見を得るだけでなく、テストに関わる方と知り合い、交流をもてたことが何よりありがたい事でした。

転職したきっかけ

JaSST行脚のおかげで、テストに関する知見を得れたので、どうやって自分のスキルを高めていくか?や、どうやってチームや会社を強めていくか?を考えていました。
しかしその反面、当時の働き方に限界を感じているところもありました。
派遣先で仕事しなければならない、派遣されているということで情報セキュリティ的などできることに限界がある、などなどですね。
そこで少し転職を考えるようになってました。

そんな折、@____rina____ さんに今の会社を紹介していただき、そのまま面談→面接→合格→転職とあっという間の流れで転職が決まりました。
お話を頂いてから決まるまで2 ~ 3週間で本当あっという間でした。
当時は、とんとんと話が決まるので、流れに身を任せてた…という感じでしたね。 2018年3月に転職が決まり、翌々月の5月から入社することとなりました。

転職するにあたりやりたいと思ったこと

今の会社はWEB系の開発を行う会社で、自社サービス・受託サービスを開発しています。
僕はそこにテストを専門に行う、テストエンジニアとして転職しました。

転職するにあたって、いくつかやりたいこと・叶えたいことがありました。
その一部が↓です。
これは面接時に社長や面接したメンバーに話した上で採用してもらいました。

  • 開発者と物理的に距離近く仕事したい
  • テストエンジニアを増やしたい
  • 1回はサービスの開発をしたい
  • 外部勉強会に気軽に行きたい(発表もしたい)
  • 給料は下げたくない

少し解説します。
「開発者と物理的に距離近く仕事したい」について、前職は、開発は東京・テストは福岡だったので、物理的に遠かったんですよね。
チャットで気軽にいろいろとコミュニケーションはさせてもらえたんですが、直接質問できたら…と思うことが何度もありました。

「テストエンジニアを増やしたい」については、今の会社は僕が入る前は少数精鋭でテストをされていたので…。
このやり方は僕には難しいなぁと感じていたので、テストメンバーを増やしたい、と入社時から思っていました。

やりたかったことはできてるのか

以下、それぞれの結果です。

  • 開発者と物理的に距離近く仕事したい
    • できてます。 いろいろ困ったときは質問しに行ったり逆にしに来てもらってます。
  • テストエンジニアを増やしたい
    • 11月に1名増えました!来てくれたおかげで、やれることや視点が広がってます。
  • 1回はサービスの開発をしたい
    • まだできてないです。 まぁこれをやるためにはもう少し時間がかかるかなぁと。
  • 外部勉強会に気軽に行きたい(発表もしたい)
    • できてます。 入社直後にJaSST東北にも行かせてもらいました。それだけでなく、行きたいものには行かせてもらってます。
  • 給料は下げたくない
    • もちろん下がってないですwあがりました。

ということで概ねできてます。
入社時やりたいことが叶えれて本当感謝ですね。

1回はサービスの開発をしたい、については、まずは自分の開発スキルを高めないといけないですからね(笑)
ちょっとずつ開発したりしてスキルアップ中です。
開発スキル修行中に困ったときは、気軽に開発メンバーに相談できてるので、すごくありがたいです。

転職して感じるむずかしいこと

当たり前…本当に当たり前とは思うんですが、会社ごと、プロジェクト、案件ごと、とやり方が全然違いますね。
人も対象も違うので繰り返しになりますが当たり前とは思うんですが、転職するとそれがかなり実感できました。

また、去年よりも組織の中での立場が上がっているので、それに伴い考えることも増えました。
ですが、今いるメンバーでどうやったら良いものができるか?良いことができるか?など考えるのは大変ですが、楽しんでやれてます。

おわりに

というわけで、総括すると転職してよかったなぁと思っています。
声をかけてくれたrinaさん、そして受け入れてくれた弊社のメンバーには感謝です。
ありがとうございます!

一番良かったと感じることは、やはり開発者と近いということですね。
ちょっとしたことでもいろいろ教えてくれてみんな優しいです。

ちなみに、もちろんですが、今は入社時よりもさらにやりたいことが出てきました。
社風的に自由度高めなので、そしてそれを整理してちょっとずつ取り組んでいます。
自由な社風というのは素敵ですね。

あと、サラッと書きましたが、 11月にテストメンバーが1人増えました。
これは本当に大きいことで、仕事中にテストの話(壁打ちや相談など)ができるのは良いものですね。
お互いスキル不足なんで…試行錯誤はしてますが、テストチームとして日々ちょっとずつチャレンジしていってます。
来年もチームメンバーを増やしながら、テストチームとして様々取り組んでいけたらと思ってます。
あ、弊社はテストエンジニア募集中ですので、ご興味ある方はぜひ私にお声掛けください!(笑)

ではでは、ここまで読んでいただきありがとうございました。

ブラウザ自動化ツールのインストールとサンプル実行6選

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

qiita.com

昨日19日目は@e5rijunさんのISTQB 翻訳辞書を作ったでした。

e5rijun.hatenablog.com

ISTQBの翻訳辞書便利ですね!
そして整理したスプレッドシートまで共有してくださるとは…さすがrijunさん。感謝です。
せっかくなのでスプレッドシートのデータを活用できたらと思ってます。

この記事の内容

さてこの記事は、6つのブラウザ自動化ツールについて、セットアップ & サンプルの実行を紹介するものになります。
これをやろうと思ったきっかけは、 今月12/8(土)に参加した、システムテスト自動化カンファレンス2018の中で@Hnzさんのブラウザ自動化ツール カオスマップ風というLTを見たからです。

speakerdeck.com

この発表ではブラウザ自動化ツールがなんと16個も紹介されていました。
私はこの中の3つぐらいしか知らなかったので「こ、こんなにあるんだ!」とただただ驚いたんですが…まぁ、驚くだけではもったいないですよね。
ということで、とりあえず全部試してまとめるか…という経緯です。
本当はAdvent Calendarまでに全部やりきるつもりだったんですが、まぁ間に合わず(笑)とりあえず6個になりました…年末年始にがんばれたら良いなぁ…

なので、この記事では↑の発表で紹介された16個のツールのうち、JavaScript Injection系のツール3つとDevtool-protocol系のツール3つの合計6このツールの紹介になります。

※ とりあえず動かしてみたい人向けです。詳しく知りたい方は公式ページを参考ください。
※ サンプルコードは、公式ページで紹介されているものを引用しました。

紹介するツール一覧

※ クリックすると書くツールの公式ページが開きます。
※ 「JavaScript Injection」、「devtool-protocol」といった分類名は発表資料のものを引用させていただきました。

諸注意

紹介するすべてのツールに、node.jsnpmを使います。
インストールしていない場合はこちらの記事を参考ください。

1. Nightmare

f:id:yoshitake_1201:20181220192356p:plain

セットアップ & サンプル実行

※ 書いてある順番で実行していってください。
nightmare_testというディレクトリをプロジェクトフォルダにしています。
※ テストコードはnightmare_test/tests/の中にtest.jsとして保存しています。

$ mkdir nightmare_test
$ cd nightmare_test
$ npm init
$ npm install nightmare
$ mkdir tests
$ touch tests/test.js

test.jsの中身に以下をコピペし保存してください。

const Nightmare = require('nightmare')
const chai = require('chai')
const expect = chai.expect

describe('test duckduckgo search results', () => {
  it('should find the nightmare github link first', function(done) {
    this.timeout('10s')

    const nightmare = Nightmare()
    nightmare
      .goto('https://duckduckgo.com')
      .type('#search_form_input_homepage', 'github nightmare')
      .click('#search_button_homepage')
      .wait('#links .result__a')
      .evaluate(() => document.querySelector('#links .result__a').href)
      .end()
      .then(link => {
        expect(link).to.equal('https://github.com/segmentio/nightmare')
        done()
      })
  })
})

以下のコマンドをたたくと、テストが実行されます。

$ node tests/test.js

その他

mocha、chai、avaといったJavaScriptフレームワークと連携してテスト実行もできるらしいです。
詳しくはこちらの記事を参照ください。

2. Cypress

https://www.cypress.io/img/logo-dark.36f3e062.png

セットアップ & サンプル実行

※ 書いてある順番で実行していってください。
cypress_testというディレクトリをプロジェクトフォルダにしています。
※ テストコードはcypress_test/cypress/integration/の中で管理する仕様です。
※ インストール直後はexamplesディレクトリが既にあり、その中にsampleコードが入っています。

$ mkdir cypress_test
$ cd cypress_test
$ npm init
$ npm install cypress
$ ./node_modules/.bin/cypress open

↑を実行すると、cypressテスト用のGUIが起動します。
GUIに表示されるファイルをクリックするとそのファイルのテストが実行される。
action.spec.jsが、入力フォームなどを操作しているサンプルになるのでわかりやすです。

その他

Seleniumを使ったことがある方はこちらのブログを読むと、イメージしやすいかと思います。
また、弊社Tech Blogでも少し紹介しました。

3. TestCafe

f:id:yoshitake_1201:20181220193720p:plain

セットアップ & サンプル実行

※ 書いてある順番で実行していってください。
testcafe_testというディレクトリをプロジェクトフォルダにしています。
※ テストコードはtestcafe_test/testsの中にtest.jsとして保存しています。

$ mkdir testcafe_test
$ npm install --save-dev testcafe
$ mkdir tests
$ touch tests/test.js

test.jsの中身に以下をコピペし保存してください。

import { Selector } from 'testcafe'; // first import testcafe selectors

fixture `Getting Started`// declare the fixture
    .page `https://devexpress.github.io/testcafe/example`;  // specify the start page


//then create a test and place your code there
test('My first test', async t => {
    await t
        .typeText('#developer-name', 'John Smith')
        .click('#submit-button')

        // Use the assertion to check if the actual header text is equal to the expected one
        .expect(Selector('#article-header').innerText).eql('Thank you, John Smith!');
});

以下のコマンドをたたくと、テストが実行されます。

$ testcafe chrome tests/
# Safariで実行したいときは↓
$ testcafe safari tests/
# Firefoxで実行したいときは↓
$ testcafe firefox tests/

その他

アプリ版(有償)や、GUI + Recorder機能付きのIDE: TestCafe Studioなどもあるようです。
こちらの記事を参考にするとわかりやすいかと!

4. Puppeteer

f:id:yoshitake_1201:20181220193511p:plain

セットアップ & サンプル実行

※ 書いてある順番で実行していってください。
※ puppeteer_testというディレクトリをプロジェクトフォルダにしています。
※ テストコードはpuppeteer_test/tests/の中にexample.jsとして保存しています。

$ mkdir puppeteer_test
$ cd puppeteer_test
$ npm init
$ npm i puppeteer
$ mkdir test
$ touch test/example.js

example.jsの中身に以下をコピペし保存してください。

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');
  await page.screenshot({path: 'example.png'});

  await browser.close();
})();

以下のコマンドをたたくと、テストが実行されます。

$ node tests/example.js

※ 実行すると、同じディレクトリ内にexample.pngというファイルが保存されます。
ファイルを開くと、アクセスしたときのスクショを確認できます。

※ Defaultがヘッドレスモードで実行されるので見えるようにするには 4行目 const browser = await puppeteer.launch();を以下に変更するとOKです。

const browser = await puppeteer.launch({
  headless: false,
  slowMo: 100
} );

その他

Googleが提供しているツールですよね。いろいろできそうな気がします。
こちらの記事がわかりやすいですね。

5. Puppeteer for Firefox

セットアップ & サンプル実行

※ 書いてある順番で実行していってください。
puppeteer_firefox_testというディレクトリをプロジェクトフォルダにしています。
※ テストコードはpuppeteer_firefox_test/tests/の中にexample.jsとして保存しています。

$ mkdir puppeteer_test
$ cd puppeteer_test
$ npm init
$ npm i npm i puppeteer-firefox
$ mkdir test
$ touch test/example.js

example.jsの中身に以下をコピペし保存してください。

const pptrFirefox = require('puppeteer-firefox');
 
(async () => {
  const browser = await pptrFirefox.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');
  await page.screenshot({path: 'example.png'});
  await browser.close();
})();

以下のコマンドをたたくと、テストが実行されます。

$ node tests/example.js

※ 実行すると、同じディレクトリ内にexample.pngというファイルが保存されます。
ファイルを開くと、アクセスしたときのスクショを確認できます。

※ Defaultがヘッドレスモードで実行されるので見えるようにするには 4行目 const browser = await pptrFirefox.launch();を以下に変更するとOKです。

const browser = await pptrFirefox.launch({
  headless: false,
  slowMo: 100
});

その他

システムテスト自動化カンファレンスの前日に公開されてんですよね。
まだ記事が少ないですが基本的にChrome版と同じっぽいです。

6. TAIKO

f:id:yoshitake_1201:20181220194150p:plain

セットアップ & サンプル実行

※ 書いてある順番で実行していってください。
taiko_testというディレクトリをプロジェクトフォルダにしています。
※ テストコードはtaiko_test/tests/の中にtest.jsとして保存しています。

# taikoをインストールする
$ npm install -g taiko
$ mkdir taiko_test
$ cd taiko_test
$ mkdir tests
$ toucht tests/test.js

test.jsの中身に以下をコピペし保存してください。

const { openBrowser, goto, write, click } = require('taiko');
(async () => {
    try {
        await openBrowser();
        await goto("google.com");
        await write("taiko test automation");
        await click("Google 検索");
    } catch (e) {
        console.error(e);
    } finally {
        await closeBrowser();
    }
})();

以下のコマンドをたたくと、テストが実行されます。

$ taiko tests/test.js

※ Defaultがヘッドレスモードで実行されるので見えるようにするには、実行時に以下のようにしてください。

$ taiko tests/test.js --observe

その他

ここでは端折りましたが、TAIKOはREPLにテストコードを書きそのコードを保存する というのを推しているようです。
公式ページを見るとそんな感じになってました。
また、公式ページのサンプルでは、英語環境のためか検索ボタンのクリックが"Google Search"になっていたので、 日本語環境の場合は↑のように"Google 検索"に書き換える必要があります。
ご注意ください。
ちなみに、Integrationを使いたい場合はGaugeと合わせて使うようです。

おわりに

この記事を書きながら、もちろん動かしていたんですが、それぞれのツールで似たようなところもあれば、ぜんぜん違うところもあって面白いですね。
私は今Cypressをメインで扱っていたのですが、なにやらTestCafeから良さそうな雰囲気を感じました。
いろいろ目的によって選べるようになるといいなぁと思います。

Advent Calendarももうすぐ終わりですね。なにか物悲しくなりますね(笑) 明日は @acha_821さんですね。楽しみです。
では、ここまで読んでいただきありがとうございました!

ブラウザのテストに役立つChrome拡張機能8選

この記事は「ソフトウェアテストの小ネタ AdventCalendar2018」の 15日目記事です。 qiita.com

昨日14日目は@tononoさんの「このテスト本が好き!2018」でした。

tonono.hatenablog.com

おすすめポイントがわかりやすく素敵でした。
紹介されていた本はまだ読んだことないので、来年読んでみます!

余談ですが…読む方の状況によって本を読んだときの理解度は全然違いますよね〜。
新しい本だけでなく、既に読んだ本を読み返すのもいいですよね。
読み返してみると新しい発見があるかもしれないですし。
新しい発見を得たとき、「あ、自分成長したんだ」と実感することもできますし。
本はまだ読んでない本も既に読んだ本もどちらも読んでいきたいです。

概要

さて、前段でなんか語ってしまいました(笑)
この記事の内容ですが、テスト設計やテスト実行時に役立つChrome拡張機能をただただ紹介するだけです。
超小ネタですね!
テーマにあっている自覚がすごくある。

自分が使っているものでおすすめできるものだけ書いてます。
良さそうと思ったらためしに使ってみてください(^^)

紹介するツールの一覧はこちらです。

  1. Window Resizer
  2. WhatFont
  3. FireShot
  4. テキストエンコーディング
  5. JSONView
  6. Speedtest by Ookla
  7. textlint: 文章チェッカー
  8. Tampermonkey

1. Window Resizer

chrome.google.com

f:id:yoshitake_1201:20181216001009p:plain

ブラウザのウィンドウサイズを調整してくれる。
これで4:3系のディスプレイがなくても、確認が簡単。
自分の好きなサイズも登録できるので、↓のサイトなどを参考に自前で登録すると良いかと!
ディスプレイ解像度一覧・早見表 | 早見表目的ネット


2. WhatFont

chrome.google.com

f:id:yoshitake_1201:20181216001224p:plain

テキスト部分をクリックするとそのFontやサイズを画面上表示してくれる。
要望でサイズ変更してほしいときに、一緒に画像を添付してあげると便利かも。


3. FireShot

chrome.google.com

f:id:yoshitake_1201:20181216001143p:plain

ページ全体のスクショを撮ることができる。
ディスプレイに表示してある領域だけでなく、ページ全体を撮ることができるのはかなり便利!
実行すると別タブで開き、PDFで保存することもできる。

Chrome標準の機能としてページ全体のスクリーンショットを撮ることもできます。
@yoshikiitoさんのこちらをご参考ください。
ChromeでWebページの全画面スクリーンショットを撮る方法(拡張機能不要) – ひびテク


4. テキストエンコーディング

chrome.google.com

f:id:yoshitake_1201:20181216001559p:plain

右クリックメニューで、ページのエンコードを指定できるようになります。
ChromeのDefaultで表示されなくなっちゃいましたからね。
これはやはり入れておきたいところかと。


5. Json Viewer

chrome.google.com

ブラウザでJsonを開いたときにいい感じの見た目にしてくれるやつです。
APIを使ったサービスではかなり重宝するかと。


6. Speed Test by Ookla

chrome.google.com

f:id:yoshitake_1201:20181216001819p:plain

有名どころの通信速度測定ツールですね。
iOS, Android App版もありますが、Chrome拡張機能ではWebサイトの表示時間も計測してくれます。
「表示に時間かかってるなぁ…」を定量的に表すことができますね!

※SPEEDTEST公式サイト→http://www.speedtest.net/ja


7. textlint 文章チェッカー

chrome.google.com

文章校正をしてくれるツールですね。
ルールもオプションで変更することが可能です。
チケット作成やブログ作成、執筆活動など幅広く使えますね!


8. Tempermonkey

chrome.google.com

Webページ表示時に、JavaScriptを実行してくれるツールです。
スクリプト実行中に、特定のリンクURLの書き換えなどすることができます。

※ いい感じの使用例が@rinaさんのブログで読めます。 [Github Issue]Assignされた一覧に詳細画面からワンクリックで遷移したい - テストする人。

このツール最近使い始めたんですがかなり便利ですね。 これからスクリプト書いていこうと思っている所存です。


おわりに

さて、ただただ紹介してきました。
ほんま小ネタでしたね。

もし何か知らなかったものがあったら試してみてください。
あと、これは便利だよ〜っていうものがあればぜひ教えてください(笑)

ちなみにChrome拡張機能ですがもちろん開発することができます。
このあたりの方の記事を参考にするとわかりやすいかと!
(自分のじゃないのか!というツッコミはおいといてくださいw)
- [公式]Getting Started Tutorial - Google Chrome
- Chromeのオリジナル拡張機能を開発しよう(ソースコードあり)
- Chrome拡張の開発方法まとめ その1:概念編 - Qiita

ではでは読んでいただきありがとうございました!

おまけ

Chrome拡張機能だけでなく、もちろん他にも役立つツールあります!
とくに@まつさんのスライドは素敵ですね。
LINEであんなことができるとは…。便利だなぁ。

www.slideshare.net

QAにはミツバチの役割があるそうな

この記事は、Fusic Advent Calendar 201812日目の記事です。 qiita.com

こんにちは。 普段はFusicという福岡の会社で、主にテストをしているyoshitakeです。
今日は私が社内で行っているテストに関わる活動について紹介します。

社内で月に1回不具合の共有をしています

今年8月から、開発中に見つけたバグを他のプロジェクトメンバーにも共有する、という活動を始めました。
具体的には、月に1回、社内Wikiにレポートをまとめる、という活動です。
私は会社の中で横断的にテストに入るから…というのが始めた理由の1つです。

レポートといってもすごくライトなもので、現状は定性的に以下のものをつらつらと書いています。
- 今月よく報告した不具合 - 今月驚いた不具合 - コラム

件数は多くても全部で4件ほど。という小さな活動です。
(コラムについては、テストに関わることを淡々と好き勝手書いてますw)

さて、不具合…いわゆる「バグ」ですが、多くの場合ネガティブに捉えられがちなことが多いと思います。
ですが、このネガティブさの視点を外してみると、「バグ」は知見・資産でもあると思います。

「バグ」を知ることで「開発やテストをするときに気をつけるポイント」になったり、またもし、会社全体で同じバグが出ているのなら「会社全体として今悩んでいるポイントが見えてくる」というような分析にも使えるのでは?とも思っています。

バグの共有はQA:ミツバチの役割

そしてこの活動について、11/30(金)にJaSST'18 Hokkaidoで「プロジェクトを横断して不具合を共有している」というタイトルでLTをしてきました。(資料はこのブログの最後に載せてあります。)

このLTをやったところ@mkoszkさんから「QAの役割である、ミツバチ効果だね」というコメントをいただきました。
QA(Quarity Assurance)とは品質保証のロールのことですが、他のプロジェクトにバグの情報を届ける役割があるとのことです。

そのコメントを頂いたあとちょっと調べてみたところ…さすがですね。
@yoshikiitoさんのブログがヒットしました!
yoshikiito.net

こちらの本にQAの役割として、「ミツバチ」が書かれているそうです(まだ読んでいないので今度読んでみますね)。
中国オフショア開発―ソフトウェア品質保証と事業OEM | 河合 清博 |本 | 通販 | Amazon

@yoshikiitoさんはブログの中で 次のように書かれています。

ミツバチとしてやるべきこと QAはミツバチとして、成功事例や失敗事例を社内に展開する必要があります。水平展開が行われないと、他のプロジェクトで失敗したのと同じような失敗をしてしまうかもしれません。 〜(中略)〜 ミツバチは成功例や失敗例を運ぶだけではなくて、自分の経験を整理してまとめ、運びやすい形に用意しておくことも求められそうです。

なるほど。
私はバグしか共有しなかったのですが、プロジェクトで良かったことなど、様々な活動を共有するのもありなんですね。
また、共有方法についても、運びやすい≒伝えやすい様々な形があると。

僕は、「不具合」を「月に1回社内Wikiに書く」を選択したわけですが、この形に囚われず、伝える内容や伝え方を改善していけそうですね。ありがたいブログでした。
加えて…QAにはミツバチだけでなく、アラーム、ペースメーカー、ブレーキ、コンサルタントと他にも役割があるんですね。
ちょっとずつチャレンジしていこうと思います。

私はこのことを知らないで、なんとなくやってたわけですが意外と方向性が間違ってなさそうで、何かホッとしました。
情報を共有していくというのは大事ですね。
これからも続けていこうと思います。
ぜひみなさんも小さなことから共有してみていただければと思います!

おまけ:プロジェクタの機材チェックはすごく大事!という話

JaSST'18 Hokkaido LTについて。
当日私は自前のPCを2台持っていたんです(MacWindows)。
でもですね、その2台ともプロジェクタとの相性が悪く映像が写りませんでした。
(1台はHDMIを接続するとPCがシャットダウンし、1台は何か反応はするけどプロジェクタには映らない…)

ただこんな機材トラブルで時間をとるわけにもいかなかったので、諦めてブルースクリーンのままLTをさせていただきました。
会場にいた皆様、実行委員の皆様、その節は本当にすみませんでした。

(まぁブルースクリーンでLTしようと思えたのも、他にブルスクLTをした方を目の当たりにしたというおかげなのですが…(笑))

ただそのおかげ(?)で、翌日のアフターツアーの夜、ツアー運営の@nemorineさんがプロジェクタを持ってきてくださり、 ツアー参加者の前で資料を使ったLTをさせていただくことができ、 そのコメントとして↑のミツバチの話を聞くことができたのは、非常にありがたいものでした。
(他にも私の資料を使ったプレゼンカラオケやレビューをしていただきありがたい限りでした。)

話がそれましたが…何はともあれ、機材チェックは大事です。
ぜひ機材チェックの時間をお作りください!
皆様お気をつけて!

■ JaSST'18 Hokkaido LT資料(アフターツアーのレビュー対応版)

www.slideshare.net