2018-05-02

転職を決意した話

はじめに

2017年の9月に転職して半年が経ち、そろそろ振り返っておく意味でブログを書こうと思います。今回の話は転職を決意するまでの2016年の夏から2017年の冬の半年くらいの内容になります。

自分の話（当時）

パートナーのQA(Quality Assurance)として1年半くらいスクラムチームに在籍
自社では初めてのQAなのでキャリアパスとかフォロー体制とかはない
スクラムチームを横断したQAチームのリーダー
業務内容は自動テストのメンテやテストプロセスの改善
手動テストは作り直しによる速度改善とかパフォーマンスアップのテストがメイン（軽めの案件は別のQAが担当で、計画会でやばい案件は自分みたいな感じ）

ちなみに、前回ブログで書いたチームを離れる時の話が今回のスタート地点です。
riririusei99.hatenadiary.jp

当時のスクラムチームの話

（自分から見れば）チームは成熟していて、離れる人は新しいチームを作る時のコアメンバーとしてチームを離れ、入る人は経験を積ませるために参画する…みたいな結構影響がありそうな体制変更もなんだかんだ受け入れられるチームでした。メンバー変更のインパクトを残ったメンバーが覚醒することでチーム力を維持する…みたいなチームになっていました。（当時のスクラムマスターの心境をお察しします…。）
自動テストの師匠が抜ける時は本当に大変でしたが、裏側まで見られるようになったので結果的に自分の成長になったのでいい経験でした。

前職(SIer)のアジャイルQA事情

運用をメインでやっていたSEがQAとして開発チームに参画するといった展開は上層部に偉く魅力的に映ったらしく、「QAを増やすにはどうすればいいのか」みたいなことを毎週毎週、根掘り葉掘り聞かれ、新しい案件の引き合いがあれば候補の中には大抵自分の名前が上がっているような状態でした。
なのでJSTQBの資格取得を目指すとか、オススメ書籍の購入をお願いしたりとか、自動テストのリポジトリ・開発規約を作って業務を受けられるようにするとかQAをキャリアパスに乗せる環境づくりについていろいろ提案・実施しました。
QAメンバー自体は引き合いがあるので多い時は５人まで増えましたが、どれも中途半端な状態で止まってしまっていた印象です。

白羽の矢が立ったその裏で…

そんなこんなで、同じ現場で肝入りのプロジェクトがテストフェーズに入る前にQAとしてテスト全般の舵取りをお願いしたいということで最初のスクラムチームを離れることになります。リリース後には保守案件のスクラムチームが発足するのでそこのQAプロセスもお願いするかもみたいなオプション付きでした。
ここでは結合テストから受け入れテストを一手に引き受けるテストマネージャみたいな仕事をしつつテストを実施したり、強化テスト用のスポットで発足したテストチームのマネジメントしたり、品質評価のインシデント分析したり貴重な経験ができました。なんだかんだお客さんに気に入られ、大変そうなリーダーのサポートもお願いされるなどそれなりには貢献できたのかなと思います。

…その裏で、「QAを増やすにはどうすればいいのか」といったアプローチを着々と決めている様子で、どうも今のプロジェクトが終わった際にはスクラムチームには合流しないで別の現場でQAとして働きQAチームを作るみたいな流れになっていました。

転職を決意する

育ててくれたチームに恩を返したい。

慣れない新しい仕事ができるようになるのは、自身の頑張りももちろんですがその時一緒に働いた人のフォローがあってやり遂げられたと思っていて、できるようになった領域の仕事はその場所に還元したいと思っていました。
還元できると思う頃には次の現場が決まってしまうので、今の働き方では大切にしたかったことは実践できないなと思いました。
新しいスクラムチームのテストプロセスを考えながらも、未来のチームに自分はいないのが分かっていうのも思い返してもつらい仕事だなと思いました。

現場の人間を大切にして欲しい。

もう一点はネガティブな話になるのですが、改善してほしいと意味を込めてきちんと書いておこうと思います。これまで「QAを増やすにはどうすればいいのか」と言われ続けていましたが、本当に言いたかったことはきっとこんな感じだったのかなと思います。
「（お金をかけず、余った人材で、かつ短い期間で）QA（の契約）を増やすにはどうすればいいのか」だったのかなと。そこにいる人にはあまり関心がなかったのかなと思っています。自分自身も同じ環境で育っているのであまり強くは言えないですが、契約を優先して交代だったり増員のメンバーがQAの仕事に対して興味や関心がない人、極端にスキルが劣る人を補充するのは本当にやめてほしいと思っています。育ててくれたチームに対して後任のメンバーがトラブルを起こし、リーダーとして以前所属したチームにトラブルを解決しに行く時は恩を仇で返しているような気持ちになりました。

…と言う状況で、別の現場に移動して同じことを繰り返すというのは個人的にも耐えられないなと思い転職を決意するのでした…。

まとめ

つらつらと書いてみたものの転職を決意しただけでこんなに長くなるとは思わなかったですが、こんな感じで転職を決意しました。
ここら辺の考えがベースになっているので転職エントリーでは活動の内容にクローズアップしてかければと思います。

2018-02-21

QAエンジニアとしてのスタート地点を振り返ってみる

はじめに

なんだかんだスクラムチームでのQAエンジニアとしてのキャリアが4年目になったので今回のエントリーを書きました。
そういえばブログを書いているけど、自己紹介すらままならないのでこの辺で自分語りの記事も入れておくって側面もありつつ、これからQAになる人に向けて、話すことを今のうちから貯めておこうっていう企画です。

QAエンジニアになったきっかけ

2014年の末、それ以前は常駐してBPOサービスを提供するSEとして運用業務・受け入れテストなどを2年半ほど業務に従事していました。
そんなところにスクラム開発でQAを探しているというお誘いがありました。
プロダクトオーナーがテスト＆受け入れを行って、多忙ゆえに十分なテストが行うことができないことに課題感を持っていたっていうのが始まりです。

・・・

~~若くて勢いがあったのと、~~テスト＆運用業務を通してドメイン知識のあるということで自分に白羽の矢が立ちQAとしてのキャリアが始まりました。
今思うとマネジメントな人が多い会社だったのもあり、運用プロジェクトのリーダーになるかなぁとか漠然と思っていたけど、テストで生きていくようになるなんて思ってもいなかったなぁという感じです。

最初のミッション

当時の自分に課せられたミッションをまとめると下記だったような気がします（チャレンジも含む）

受け入れテストの実施
テストプロセスの改善
品質の向上
テスト自動化

一番最初のMTGで「アジャイルテストの４象限」と「テスト自動化のピラミッド」の図を見せてもらったことについては今でも覚えています。
これから先、アジャイルQAを育成する機会があれば、まずこれを見せてあげようかなぁとか思います。

役割分担

f:id:riririusei99:20180221020826p:plain

これは実践アジャイルテストの図に方針を書き足したもの。
まずは最初に「受け入れテストの実施」など手動の領域を担当するのが最初のミッション。
将来は手動と自動の左上の領域もQAに任せていきたいという内容だった（と思う）。

それぞれの４象限について誰がメインで担当していくかを明示してくれたのでわかりやすかったと思う。
改めて思い返すと成長した時に期待する姿もしっかり言及しているし、心の中にこの図はいつもあります。

自動化戦略

f:id:riririusei99:20180221015949p:plain

こちらは自動化戦略の説明のために。チームの自動化戦略として山の登り方はこうやって進めるという内容でした。
最小構成で作ったピラミッドを順々に大きくしていく…という文脈でGUIテストの自動化から最初に着手する必要があり、自動テストのシナリオを作ってくれってのもQAになりたての頃にやりました。
~~…そして当時作ったケースがその時入ってきた新人君にボロクソに言われるのだった。~~

当時のチーム構成

プロダクトオーナー
スクラムマスター
エンジニア(7人)
QA(１人)

当時のチーム構成はこんな感じ。
チームの方針は「分からないからこそ、型を意識する」みたいなチームでした。
まずは型を守って、少しずつ破っていき、ある程度したら型から離れていくみたいな進め方だったので初めてのスクラム開発としては馴染みやすいチームでした。

あとはスクラム開発自体を導入する最初のチームだったので各社が肝入りのメンバーをそれぞれぶつけてきた感じのチームだったのですごい人が多かったなぁ。。。開発チームの一員で役割が違うだけという括りだったのですべてのセレモニーや会議に参加していたので本当によかった。

はじめに頑張ったこと

社内で初めてのQAだったのでモデルとなるキャリアパスがなかったので、当時が頑張ったことは下記です。

JSTQBの資格取得
界隈のスクラム・アジャイル・品質保証系の勉強会に出る

JSTQBの資格取得

テストの専任・プロなのでいろいろ調べて真っ先に取ろうと思った資格。
勉強してみると日頃の開発で使えそうな知識がたくさんあったのでオススメしたい。

界隈の勉強会の参加

テストの自動化やアジャイルテストに関わりそうなものは足を使って情報収集した。
いろいろ勉強会で分からないことを質問したら、同じような境遇の人と連絡先を交換したりしてこれはこれでよかったかも。

おわりに

当時のことを思い出していろいろ書いたので、また思いついたらここを直していきます。
そう考えるとまるまる3年はやってるのでそこらへんの整理は定期的にやるべきだと改めて思いました。
教えるのが下手くそな自覚はあるので次教える機会が来る近い未来までにはある程度形にしたいと思います。

オチ、書いた人の現在の雑な自己紹介（読み飛ばしてOKです）

私、riririusei99！QAエンジニアだよ！最近転職してきたけど、憧れて入った先輩エンジニアがどんどん偉くなっちゃって、さぁ大変！ひょんなことからスクラムマスターも兼任することになって…どうすればいいの？？次回、「ドキドキ☆スプリントプランニング」お楽しみにー！

終わり

2018-01-26

【まとめ】JavaScriptのE2Eフレームワークを触ってみる

はじめに

これまで５回に渡り書いたE2Eフレームワークを使ってみる系の記事は、We Are JavaScripters! @15th【初心者歓迎LT大会】 - connpassに登壇するにあたり書きました。
今回はLTに組み込めなかった補足とかを書ければ良いかなと思います。
~~事前に盛大にネタバレしていた訳ですが、LTは総集編だから良いだろうという目論見です~~ wajs.connpass.com

発表資料

speakerdeck.com

E2Eフレームワークを使ってみる系の記事

Cypressを使ってみる - riririusei99’s blog
TestCafeを使ってみる - riririusei99’s blog
cinnamonjsを使ってみる - riririusei99’s blog
nightmare.jsを使ってみる - riririusei99’s blog
protractorを使ってみる - riririusei99’s blog

紹介したツールの選び方

LTの中で5つのツールを紹介したのですが、検討条件・紹介した理由みたいなのを書きます。

検討条件

テーマであるJavaScriptを使っているもの
自分の勉強のため、これまで使ったことないもの
LTで紹介することを意識してテストコードの書き方に違いが出そうなもの

そこからぼんやりと紹介するテーマを選んでから紹介するツールを当てはめてみました。

紹介するラインナップ案（結果）

拡張性が高い、いろいろカスタマイズできるもの(Protractor)
導入が簡単で、単品で色々できるもの(Cypress)
Seleniumを使わないもの(Nightmare)
モダンな書き方ができる新しいもの(TestCafe)
テストケースの書き方に特徴があるもの(cinnamonjs)

※今回WebdriverIOやNightWatch.jsなどを紹介しなかったのは実は触ったことがあったのと、WebdriverIOはProtractor、NightWatchはCypressと方向性が近いかなということで紹介から外れています。
ちなみにpuppetterを使ったHeadlessChromeを使ったE2Eを紹介できなかったのは単純に触る時間がなかったためです…スミマセン。
~~触っていたら名前がカッコイイNightmareと入れ替えるか考えるので悩ましいですね。~~

LTの中でCypressを選んだ理由

現在の開発チームに導入することを考えた場合、我々の特徴として下記がありました。

特徴

既に稼働している自動テストがある
開発エンジニアに好まれるツールが良さそう

拡張性があるツールより、簡単に導入ができてレポーティングが便利なツールが望まれ、既存のテスト領域を補えるツールを考えた結果、Cypressが良いとしています。

f:id:riririusei99:20180110233044p:plain — Cypressの実施＆レポート画面

やってみての感想

社内イベント以外で登壇したのは初めてだったので非常に緊張しました。

緊張しすぎて２番手だったのに頂いたお酒を１本飲みきった状態でLTに挑みました。
終わった直後は緊張か酔ってるの分からないくらい頭が真っ白になりました。
普段から登壇されている人は改めてすごいですね。

改めて、場を提供していただいたWeJSの皆様、ありがとうございます。

また発表するので精一杯で、質疑に対して正しい返答ができず本当に申し訳ないです。
次回頑張る＆自分なりの回答をブログのネタにしますので大目に見て下さい。

最後に、資料をあげた後にたくさんの人に閲覧してもらう形になりいい経験になりました。

当初は簡単な暗号文を解析をしてくれるツールを作って、オリジナルコンテンツとしてFF10で使っていたアルベド語翻訳ツール（最近実況動画を見た）みたいなネタツールを作る話をしようと思っていました。

作った時のテンションで発表は到底できなかったので結果的に自分の仕事に関係するようなテーマを選んでよかったと思っています。
~~要所要所に笑いどころを入れようと考えて作ったのですが、同僚に指摘された通りポケモンの下りはやめておけばよかった。かなり恥ずかしい~~

本当にありがとうございます。過去は取り戻せないのでこれからを頑張ります。

といったところで勉強会の初登壇の話はこの辺で終わりです。
ここまで読んでいただきありがとうございました。

追記

発表資料がはてブでホットエントリーに取り上げられてちょっとバズりました。 b.hatena.ne.jp ありがたいです。

riririusei99

2018-01-25

Cypressを使ってみる

はじめに

E2Eツールをどんどん使ってみる月間なのでこちらを挑戦しました。ボスに触ってみるならコレだと教わったので触ってみる。
下書きのまま放置されてたので公開。

www.cypress.io

インストール

$ mkdir cypress-test

$ npm install cypress --save-dev

$ ./node_module/.bin/cypress open

ウィンドウが立ち上がるとホームディレクトリにいろいろ追加してくれるので試しにexample_spec.jsを走らせるとテンションが上がる。 sampleにはいろいろ書いてあるので触り方を学ぶにはちょうどいいかも！

ディレクトリ構成

.
├── fixtures
├── integration  //ココにテストを書く
├── plugins
├── screenshots
└── support

テストを書こう！

$ cd integration
$ touch simple_spec.js

simple_spec.js

describe('My First Test', function() {
  it("Search riririusei99", function() {
    cy.visit('http://teamspirit.hatenablog.com/')

    cy.get('input[type=text]').type('riririusei99')
    cy.get('input[type=submit]').click()

    // Waits for the title to be 'riririusei99'.
    cy.title().should('include', 'riririusei99')

    cy.title().should('eq', 'riririusei99 の検索結果 - TeamSpirit Developer Blog')
  })
})

画面

simple_spec.js f:id:riririusei99:20180110233044p:plain

CLIで実行してみる

$ ./node_modules/.bin/cypress run


  (Tests Starting)


  My First Test
    ✓ clicking 'type' navigates to a new url (8625ms)


  1 passing (10s)


  (Tests Finished)

  - Tests:           1
  - Passes:          1
  - Failures:        0
  - Pending:         0
  - Duration:        9 seconds
  - Screenshots:     0
  - Video Recorded:  true
  - Cypress Version: 1.4.1

CLIで実行するとvideosディレクトリが作られmp4ファイルを出力してくれる

さっくりまとめ

すぐにインストールできてすぐに動く、しかもCLIでも動くのは結構便利（自動化しやすい）
いろいろ拡張したくなる（ブラウザ変えたい、テストフレームワーク変えたい）のにはどう対応していくのかな
小さなコンテンツに対してChromeだけで保証するような場合とかにはものすごく便利だと思いました。

おわり

riririusei99

2018-01-22

TestCafeを使ってみる

はじめに

使ったこと無いE2Eフレームワークを触ってみる月間第四弾
あきらかにテストしてくれそうなこちらです。

devexpress.github.io

インストール

$ npm install --save-dev testcafe

ディレクトリ構成

$ tree -L 1
.
├── node_modules
├── package-lock.json
├── package.json
└── simple_spec.js

テストを書く

simple_spec.js

import { Selector } from 'testcafe';

fixture `My First Test`
    .page `http://teamspirit.hatenablog.com/`;

test('Search riririusei99', async t => {
    await t
      .typeText('input[type=text', 'riririusei99')
      .click('input[type=submit]');

    const title = await t.eval(() => document.title);
    await t.expect(title).eql('riririusei99 の検索結果 - TeamSpirit Developer Blog');
});

テスト実行

$ ./node_modules/testcafe/bin/testcafe-with-v8-flag-filter.js chrome simple_spec.js
 Running tests in:

 My First Test
 ✓ Search riririusei99


 1 passed (12s)

今回使ってみての感想

触ってみて5分もたたずに動きました。ほぼ設定いじってない状態で動いたので導入が簡単。
async/awaitを使ってテストコードをかけるようになりましたので、フロントのエンジニアは抵抗なく書けるのかな。
一通り触り終わったら使い込んでみたくなりました。

今回触ったもの

github.com

2018-01-18

cinnamonjsを使ってみる

はじめに

触ったこと無いE2Eフレームワークを触ってみる月間第三弾。
今回はちょっと変わり種のコチラ

github.com

リーダーに紹介頂いたのですが、なかなかマニアックそうなのを教えてくれましたね…。
諦めず頑張ります。

インストール

$ npm install --save-dev cinnamonjs
$ npm install --save-dev selenium-webdriver

## ダウンロードしてきたfirefoxドライバの配置(geckodriver)
$ mv ~/Downloads/geckodriver-v0.19.1-macos.tar.gz ~/Repository/cinnamojs-test
$ tar -zxvf geckodriver-v0.19.1-macos.tar.gz

テストを書く

simple_spec.js

module.exports = [
  {action: "start"},
  {action: "browser.set.size", width: 1024, height: 768},
  {action: "browse", url: "http://teamspirit.hatenablog.com/"},
  {action: "send.keys", locator: {css: "input[type=text]"}, keys: "riririusei99"},
  {action: "click", locator: {css: "input[type=submit]"}},
  {action: "wait.title", "page.title": "riririusei99 の検索結果 - TeamSpirit Developer Blog"}
];

ディレクトリ構成

.
├── geckodriver
├── node_modules
├── output
├── package-lock.json
├── package.json
└── specs
    └── simple_spec.js

outputのディレクトリにレポートファイルが入る

テスト実行

$ ./node_modules/cinnamonjs/cli.js ./specs/simple_spec.js

使ってみた感想

テストを実行するとレポートを出力し、テストにかかった時間や、アクション毎にスクリーンショットも撮って確認できる。
json形式でテストを書くのでひとつひとつの操作に意味を手動のテストケースと紐付けながらかけたりも出来るかも。

昔、聞いた自動テストコードの生成システムはExcelでテストケースを書いたらコードになるって言ってたので、こういう形式なら出来るかもしれないと思いました。

テストレポートのキャプチャ

f:id:riririusei99:20180117231946p:plain

今回触ったもの

github.com

おわり

riririusei99