yoshitake_1201’s diary

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

転職後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

2018/02/04 TDD体験的なワークショップに参加してきました!

ふとしたご縁で(ただただ押し掛けただけなんですが…w)
テスターちゃん作者Mさん、のご友人のYama Kenさん主催のワークショップに参加してきました。
(大分遅くなったけど…)以下、内容と感想です。

※主催者の方のこのワークショップのエントリ
欠陥プログラマーの整備手帳 — ワークショップ@博多

■開催概要

日時: 2018/02/04
参加人数: 3人

ワークの内容

ワークの流れ

  1. ワーク1
    1. お題のプログラムについて、テストを考えずに実装する
    2. ↑を参加者が持ち回りで探索的テストする
    3. それぞれがテストした結果を共有する
  2. ワーク2
    1. 1.2や1.3をもとにテストケース&テストデータを作成する
    2. 2.1のテストコードを作成した後、お題のプログラムを作成する

お題【マイヤーズの三角形】

  1. ユーザーが3つの整数を入力する。この3つの整数は三角形の一辺の長さを表す
  2. 3つの整数から、「不等辺三角形」「二等辺三角形」「正三角形」を判定してメッセージ出力プログラムを作成する
  3. それぞれの三角形のメッセージは英語表記とする
  4. 不等辺三角形(Scalene triangle)
  5. 二等辺三角形(Isosceles triangle)
  6. 正三角形(Equilateral triangle)
  7. クラス「Triangle」を定義し、実装すること
    ※使用するプログラミング言語は自由

■ワーク1について

お題のマイヤーズの三角形は、そもそも知ってたのと、 "テストを考えないで"っていうのがなかなか、難しいなぁ…と思いました。
なので、初めてマイヤーズの三角形に出会った時の感覚と、学部生時代のころを思い出して プログラムすることにしました。出来上がったコードが以下です。
※私が選択したのはJavaScriptです。

<html>
<head>
<title>マイヤーズの三角形byモンキー!</title>
<script type="text/javascript">
function Triangle( line1, line2, line3 ){
  if( line1 == line2 & line2 == line3 ){ 
    return "Equilateral triangle" ;
  }
  else if ( line1 == line2 | line2 == line3 | line3 == line1 ){ 
    return "Isosceles triangle" ;
  }
  else { //Scalene triangle
    return "Scalene triangle" ;
  }
}
function disp(){
  line1 = window.prompt( "三角形の1辺を入力してください①", "" );
  line2 = window.prompt( "三角形の1辺を入力してください②", "" );
  line3 = window.prompt( "三角形の1辺を入力してください③", "" );
  alert( Triangle( line1, line2, line3 ));
}
</script>
</head>
<body>
<p><input type="button" value="三角形識別!" onClick="disp()"></p>
</body>
</html>

ワーク1 感想

一応補足すると、もちろん、三角形が成り立たないことがあるとか、入力されるデータのチェックが必要とか… そういうのはわかっておりますw(念のため)

プログラミング学びだしたころぐらいまで感覚を戻しまくって、 ただお題だけを読んで「よっしゃこんなん簡単やで!」っていう思考で、 特に調べることなどせず、辺が全部一緒なら正三角形、 2つ一緒なら二等辺三角形、全部違うなら不等辺三角形! という考えを疑うことなくプログラムをした。
という感じでした。
その結果なんですが、とりあえずIF文で辺を比較したらそれでいいだろう、という思考になりました。
コードができた後に、「0が入力されたら」とか、「マイナスがにゅうりょくされたら」とかそういうのを考えました(時間がなかったので実装はしてないです)

そしてお二方に動かしてもらったんですが…まぁバグいっぱい出してくださいましたw
正常系以外バグしか出ないですしね…。これ。
だいぶ楽しんでくれてて、ある意味いいもの作った感でしたw

■ワーク2について

事前に作成したテストケースは以下です。

・テストケース(32ケース)
正三角形の確認(1パターン)
二等辺三角形の確認(3パターン)
不等辺三角形の確認(3パターン)
三角形が成り立たない(6パターン)
全角文字が入った時にエラーとなること(3パターン)
半角英字が入った時にエラーとなること(3パターン)
0以下が入ったときにエラーとなること(3パターン)
小数が入ったときにエラーとなること(3パターン)
入力が最大値を超えた時にエラーとなること(3パターン)
先頭に0がついた時、エラーになること(3パターン)
空白の時、エラーになること(3パターン)

ワーク2感想

プログラム書く前の、テストコードを手で書いていくのが大分辛かったですw
3人とも頑張ってテストコードをただただ手打って…苦行でした。。

だけど、テストコードを書き終えた後は、待ちに待ったプログラムができる! ってかんじで、みんな楽しみながらプログラムしていて、良い感じでした。
一応ルールとして、テストケースが全部Passになったら完成、というのがあったのと、 あとどの機能を実装したら完成か?というのが目に見えて分かりやすかったので、 精神的な負担が少なかったです。

■全体の感想

ワーク1とワーク2で、状況や感じたことをざっと比較すると、以下になります。

  • ワーク1
    • 先に基本機能を実装する→あとから継ぎ足し継ぎ足ししていく
    • 終わりがわからない不安感がある
  • ワーク2
    • 先にテストする項目を考える→仕様が細かく決まっている
    • いつでも動作確認ができるので、精神的に楽。
    • テストケースを終わらせていく感覚が、ゲームで実績解除していく感覚に近くて、楽しめた

最近はほとんどコード書かないですし(そもそも社会人になって開発したことないですし) プログラムを書く!っていうワークが新鮮でしたw

ワーク1であんなコード書いてますが、長崎QDGで池田さんが言われていた、 設計時に思考が狭まっていく(仕様を定めていく)っていう感覚は一応あったんですよね。
なので、ワーク1でプログラム書き終わった後、探索的テストになったんですが、 テストの思考に切り替えるのがだいぶつらかったですね。
テストする視点を広げていく、というのがなんとも難しかった。

昨年出版されたTDD本の 「テスト駆動開発」を読んではいたんですが、実際に経験してこそわかることがありますね。
また読み返そうと思いました!
本の中に、開発が予測可能となる、プログラムを書いていて気持ちがいい、
ということが書かれていましたが、まさにその通りで、 ワーク2では、先にテスト考えれてて、いつでもテストが楽に行える、っていう安心感と、
ゴールが明確化されているという、すっきりとした感じが開発中にずっとありました。

そして、普段ブラックボックステスト(+グレーボックスっぽいこと)しかしていないので、 ホワイトボックステストを経験できたのも有益でした。
こういう実装しているから、このテストはいらない、とテスト項目を削るのが新鮮でした。

そして、事前にテストを考える=仕様を明確化しているんだなぁと実感できました。
普段の業務でも少しはあるんですが…テストと開発を一緒にやることになると、更に深まった感じでした。
やっぱり静的にテストするって大事ですね

突如押し掛けてしまったんですが…普段できない貴重な経験ができたワークでした!
Yama Kenさん、まつさん、ありがとうございました!
またやってみたいですし、自分の周りの人にも経験させてあげたいなぁ…と思えるワークでした(^^)


Reference

その他

続きを読む

2018/02/02 第3回長崎QDGに参加してきました!

NaITEさん主催の、第3回長崎QDGに参加してきました。
(大分遅くなったけど…)以下内容と感想です。

■開催概要

日時: 2018/02/02(金) 12:00 ~ 17:20 場所: メルカつきまち nagasaki-it-engineers.connpass.com

togetter.com

■各講演の感想

池田暁さん:「単なる仕様チェックから卒業するために 〜最初に抑えたいキホンのキ〜」

www.slideshare.net

講演内容は、昨年の盛岡勉強会での内容をギュッとまとめて、という感じでした。
(具体的にはスライド32~94の内容でした。)
個人的に、↑の資料を見て、講演内容を聞いてみたい!と思っていたのですごいありがたかった。。。

スライドにもあるんですが、以下のように設計の思考とテストの思考は違うんだよ。

  • 設計のための思考 > 問題領域を狭めていく
  • テストのための思考 >問題領域を広げていく

っていうのが、納得感が高かったです。
(さらにこの2日後に実体験することになって、理解は深まりました。)

テストをする前に如何に気づくことができるか?
っていうところを重要視されていて、同じ感覚だなぁと思いました。
(ただ、気づくまでのアプローチも、気づいてからのアプローチも、自分は全然足りないなぁとグサリ…。)
あと、ブラックボックステストホワイトボックステストは、
技法というよりはどちらかというとスタイル、っていうのはなるほど〜となりました。

原 佑貴子さん:「速効性重視のレビュー技術:高速2パーソンインスペクションのススメ」

なんとリモートでの講演でした。
原さんの登壇が決まったのは、開催日の週ということだったんですが、 講演が決まってからツイッターが盛り上がっていたのでワクワクしながら聞きました。
(原さんが、細川さんの話によく出てこられる赤ペンの方だったというのは、講演が終わってから知りましたw)

セッションの内容は 参加者が実際にインスペクション レビューを体験するというもので、 2人組になり、唐突に渡されたFlight Planning and Management Systemのドキュメントについて 役割分担してレビューするというかんじでした。

以下は原さんの講演資料と口頭で教えてくださったにレビュー実施のコツです。

  • お菓子を用意する!
  • 自分が1ページが何分で読めるか?っていう力を持っておくべき
  • 指摘に対して「いいね!」と口にする

  • 指摘や言い換えに自信がなくてもとりあえず言ってみる
  • 事実を指摘する
(書いていないことを指摘しない)
  • 欠陥の検出に注力する(原因や解決策を議論しない)

  • 1ページ目からレビューしない(1ページ目は、書いた人が1番自身があるから)

ガツッと”レビュー”という名目なレビューを体験したことがなかったので、 ただただ戸惑うばかりでした。
ただ、2人組になった相手がなそさんだったので、指摘の仕方とかも知れて助かりました。
感謝。。

一般にはインスペクションは重たい空気になりやすいとのお話だったんですが、 今回体験したのは楽しかったなぁ〜と。

そして後半、細川さんと原さんによる生インスペクションを披露してくださいました。
ドキュメントの曖昧さに対して「これはバグですか?」という指摘が衝撃でした。
ドキュメントをレビューする段階で、「バグ」っていう言葉を使うんだなぁと。

レビューはもちろんながら、静的テストという概念を、もうちょっとチームに広めていきたいなぁと思いました。

日下部先生:「いろいろ使える(システム理論に基づく)セーフウェアのためのモデルSTAMPとその分析法」

STAMPとは「ものごとがうまくいかないことを説明するモデル」!
とのことだったのですが…
そもそもSTAMPというものを知らなかったので…個人的には難しい内容でした。。^^;

以下を読んでそもそもどういうものか勉強しようと思います。
「はじめてのSTAMP/STPA ~システム思考に基づく新しい安全性解析手法~」の公開:IPA 独立行政法人 情報処理推進機構

STAMPを活用できそうな状況として、
例えば大学教授と学生の関係において。
* 大学教授の思惑>この内容の講義をやれば学生は積極的に参加するはずだ! * 実際の学生>とりあえず参加する、そもそもやる気がない…など。

というような状況をSTAMPで説明できそうとのことでした。
このあたりを聞いて、問題分析ということで TOCクラウドやブランチにも近いのかなぁ…って思ったりもしました。

くまちきさん: 「PSP活用SIG活動報告」

というのは覚えました!w
たぶんここが一番重要(違う

PSPは、CMM(Capability Maturity Model, 能力成熟度)を開発した ハンフリー博士が提案した個人レベルでの継続的プロセス改善のしくみ!
とのことなんですが、 PSPもまた知らなかった内容なので…こちらも個人的には少しむずかしい内容でした。。。
(そもそもCMMもよくわかっていないので…勉強不足すぎる。。。

以下を読んでみようと思います!
第1章 PSPを導入する理由(わけ) ~自立したエンジニアのためのライフハック:ゼロからはじめるPSP ─Personal Software Process | エンジニアマインド … 技術評論社

金子 昌永さん:「チームで、長期間で、たくさんのソフトウェアを快適に開発し、価値を生み続けるためのエンジニアリング」

www.slideshare.net

金子さん、とりあえず冗談が冗談に聞こえず、普通に信じてしまいました。
「天は人の上に人を作らず…」これは忘れられないw
たぶん、僕は金子さんをお見かけするたびに、思い出すんだろうなぁと思いました。

内容について、 ソフトウェアビジネスのイメージが、わかりやすくて納得でした。
またチームの方向性や、求められる知識など、考えさせられることが多く、 現状の分析をツールも含めてやってみると、足りていないものやできていることなど分析できそうだなぁと思いました。

LT セッション

tositeさん:「いっぽんのサービスのむこうに」

www.slideshare.net

LTらしいテンポ感なLTだったなぁーとw
システムを1から全部1人で導入してていてすごいなぁ…と。
自分も研究室時代にClientからServerまで全部やって大変だった記憶があるけど、 会社で製品としてそれをするのはただただすごいなぁと思いました。
寿司とビールが同じ問題とかあるんですねぇ。
第18回 MySQLの寿司ビール問題,Pgpool-II3.6.1リリース:OSSデータベース取り取り時報|gihyo.jp … 技術評論社

caori_tさん: 「一人じゃ探せない答えを探してみたら…」

caori_tさんの発表は、ひとまず癒やされますよねw
チームメンバーとの問題解決をするのにファシリテートって大事だなぁ…とひしひしと感じでおります。
さじ加減が難しいのと、これでいいのか?がよくわからないのが最近の悩みですが…。
ゆるファシをされたい。

さとうひろゆきさん: 「テストを料理で例えてみよう」

テストの伝道師、さとうさんの、テストプロセス(開発工程も含む?)を料理で例えてみた。
というお話。
常々、さとうさんは例えるのがうまいなぁ…と思います。
テストプロセスとか自分なりに説明しようとしてもなかなかわかってもらえないんですよね。
( そもそも自分がそんなに理解できてないというのが問題ないんですが…
経験してない相手に如何にわかりやすく伝えるか?というのは重要ですよね。
自分も精進しようと思います。

細川 宣啓さん:「ソフトウェア品質レビューの全て:生い立ちから先進技術まで」

昨年、私が一番拝聴した講演者は、間違いなく細川さんなのです!が…
まさか2018年、1回目のテストイベントで細川さんの講演を聴くことができるとは…という なかなか衝撃でしたw

「いいレビュー・すごいレビューってどんなレビュー?」という、問いかけから始まったのですが 、 これは自分が「いいテスターってどんなテスター?」って悩んでいた疑問に似ているなぁと思いました。
人や状況によってだいぶ違うだろうし、難しい問いだなぁ…と。
細川さんが提示された、うまくレビューする(いいレビューをする)という1つの解としては、以下とのことで、あぁ、たしかに直してもらわないと意味ないし、どうせ直してもらうなら気持ちよくのほうがいいよなぁ…と思いました。

  • 開発者に気持ちよく直してもらうこと。
  • うまくフィードバックして、すっと直してもらえる。そして、開発者の行動が良い感じに変わること。

また、バグ分析のために、毎日バグのカルテを書いていた、というのは刺激的でした。
バグのカルテを書いて、そのカルテを自分の血や肉として、今に活かせている、と。
自分の環境的には、バグの原因まで知ることが今の状況だと難しいですが カルテをつけていってみようと思いました。

■全体の感想

参加者と講演者が近くて、良い感じの会だなぁと。
懇親会も翌日のツアーも面白かったですし!
福岡から陸路で行ける数少ない勉強会なので、来年もまた参加したいなぁと思いました。

そして、長崎、とても美味しかったです(´▽`
f:id:yoshitake_1201:20180304000722j:plainf:id:yoshitake_1201:20180304000733j:plainf:id:yoshitake_1201:20180304000742j:plainf:id:yoshitake_1201:20180304000749j:plain

Xocde : AutoLayout > TabView & NavigationBar付きTableViewで背景にImageViewを使ったら、Layoutが崩れまくったので、その時した対処(メモ)

ひょんなことから、知人のお店アプリを以下の仕様で作成することになった。

  • 環境
  • Xcode8 & Swift3.0
  • 仕様(超ざっくり)
  • TabViewでページを切り替え
  • TableViewで店舗一覧表示
  • 店舗一覧で店舗をTapすると、詳細ページに行く

でもXcode 触るのもSwift書くのも1年以上ぶりで(そもそも当時もそんなにかけるほど触ってない)どうしようかと悩んで本屋に赴いたところ、すごく参考になる本が!

TECHNICAL MASTER はじめてのiOSアプリ開発 第2版 Xcode 8+Swift 3対応

TECHNICAL MASTER はじめてのiOSアプリ開発 第2版 Xcode 8+Swift 3対応

自分がやりたい機能がほぼほぼ書かれていて、実戦向き&それでいてわかりやすい。 (自分は使わなかったけど、書籍内ではAPIを使用して TableViewに店舗一覧を表示することを実現していました。) Xcodeの使い方、Swiftの説明、AutoLayoutを使ったアプリ開発Apple申請の仕方までこの一冊は本当にすごく重宝しました。


しかし問題が…。 Navigation BarつきのTable ViewとTableの詳細ページの背景に画像を使用しようとAuto Layoutを使用してImage Viewをおいたところ、まぁずれる。ずれる。 ↑の本のおかげで、昔から苦手だったAutoLayoutと仲良く慣れたと思ったのに。 ※ちなみに↑の本には、Image ViewをAutoLayoutを使用して背景にする使い方は書かれていませんでした。 自分の力不足としか言いようがない。

んで結果とりあえずどうしたかというと、

qiita.com

chocoffee.cafeblog.jp

onga-tec.hatenadiary.jp

上記のサイトを参考に背景のImage Viewだけ viewDidLoadで呼び出すということで解決。・゚・(ノД`)・゚・。 きっといつかAutoLayoutで実現してやる!

ちなみに参考サイトではSwift2.0以前っぽくて、CGRectMake が使われているんだけど、Swift3.0では使えなくなったみたいで…。 でもソッチのほうがすぐ解決できました。

    // TableViewがあるViewControllerのviewDidLoad()
    override func viewDidLoad() {
        super.viewDidLoad()
        let bgImageView = UIImageView(frame: CGRect(x: 0, y: 0, width: self.tableView.frame.width, height:self.tableView.frame.height))
        let image = UIImage(named: "background_image.jpg")
        bgImageView.image = image
        bgImageView.alpha = 1
        self.tableView.backgroundView = bgImageView
    }
    override func viewDidLoad() {
       // TableView からshowdetailで遷移したViewControllerのviewDidLoad() に 以下を追加
        UIGraphicsBeginImageContext(self.view.frame.size)
        UIImage(named: "background_image.jpg")?.draw(in: CGRect(x: 0, y: 0, width: self.view.frame.width, height:self.view.frame.height))
        let bgImage: UIImage! = UIGraphicsGetImageFromCurrentImageContext()
        
        UIGraphicsEndImageContext()
        self.view.backgroundColor = UIColor(patternImage: bgImage)
    }