E2E自動テストの長期運用に耐えるための5つの手法 #Seleniumjp

スライド

www.slideshare.net

モバゲーのプラットフォームについて

  • 数千万人の会員がいる
  • 3rdパーティーの開発のためのサービスを提供している

モバゲーのプラットフォームの経緯

  • ブラウザのゲームからスマホゲームに移行している
  • まだまだ沢山のユーザーがモバゲーのプラットフォーム上で遊んでいる
  • 課題として、高いアベイラビリティ後方互換性を少ないメンテナンスコストで行っている

規模感

  • 5年経過
  • 22個のテストスイートが分かれている
    • 機能毎に分かれている。
      • 会員登録とか
  • 700個のテストケース
    • 決済とかログインとかはしかkりテストしている
  • 60000個のAPIのテストケース
  • 開発者はサーバーサイドのリリースはQA無しでリリースできる

運用について

  • テストスイートがどういう経過を辿るか分かってきた
  • QAの一部として作り始める。
  • リグレッションテストとして回り続ける
  • 1年ぐらい経つとテストが壊れ始める
  • 自動テストが完全に壊れるテストスイートが出てくる
  • 出来る限りちゃんと動く期間を長くするようにする

どうすれば長期運用に耐えられるようになるのか

  • とにかくテストを流し続けましょう
  • 1日1回は最低限回すようにしている
    • 定期的に実行しているぐらい安定していないといけない
    • なかなか通らないテストは安定化しましょう
    • 開発環境が変わったなどをいち早く検知するため
      • 壊れた瞬間が一番直しやすい
  • どうしようも無いテストは諦める
  • 既存のリグレッションテストの100%グリーンを拘らない
  • 環境に依存するようなFlakyなテストとか
  • 直す工数が大きいが得られるメリットが小さいものとか

できるだけ早くテストをデバッグしたい

  • 出来る限りテストのデバッグが出来る人を増やす
    • 一番長く使われるテストは、開発のプログラミングテストと同じ言語にすることだった
  • テストのインフラはしっkり確保しよう
    • 1回回すのに1時間かかるものとかは無しで
    • 失敗したテストケースのみ流せるようにする
    • 失敗時のログを出す
  • Selenium Gridが活躍している

Debuggability

  • Zalenium
  • 実行のデバッグが見やすいようになっている

テストの実装とテスト対象システムの実装を疎結合にしたい(これからやりたいこと)

  • WebAPIはメンテしやすい
    • APIサーバーに依存しにくいから
  • Seleniumでテストを書こうとすると、テストコードの中で表現しないといけない
  • 取り組み
    • イトクローラを用いて、本番プロダクションのデータを持ってきて、それを正解データとする
      • 正解データはGithubに入れる
      • 別のブランチでプルリクする
        • GitHubが勝手に差分をしてくれる
    • 自然言語処理を使ってフォームを解析する
      • ICST2017で得たネタを使っている

re:反復開発

勉強会告知ページ

connpass.com

スライド

speakerdeck.com

自己紹介

  • @m_seki
  • XPプログラミングを16年ぐらいやっている

クックパッド

  • 2015年にイベントをやってた
  • 秋山さんが論文を書いてた
    • 開発チームの中にテストエンジニアを配し…テストの現場の理想型の一つと思う
    • 開発者もテストエンジニアも不具合を減らし、
    • このようなチームを@m_sekiさんが持っている

Agenda

  • 反復開発の基本
  • 上手くやることのヒント

本当はなにに困っていますか?

歴史

  • 2004年には会社の理解が無かった
  • 2008年
    • 川口さんが上手くやり始めた
  • 2016年のJaSST
    • 「Scrumは上手く行っているがプロジェクトは上手く行っていない」
    • →反復開発が上手く行っていないみたい

障害を想定したい

  • 今日の会場は「変わりたくない層」ではないと思うことにした

反復開発ができてないのでは?

  • まず、反復開発を説明するべきかもしれない
  • Scrumとか色々な名前の手順書が出てきたのに、それを使いこなせてない

プロジェクトが終わったとき

  • どんなことを感じますか?
    • こうすれば良かった…とか
  • もう一度やったらうまくいくような気がしませんか?

ウォーターモデル

  • 図だけ引用されることが多い。
  • 実は「戻りはnステップですよ」と書いてある
    • 工程は1ステップずつ進むけど戻りはnステップ
  • 同じ工程は何度も起こる
  • むしろ2度作りましょう
    • 1回やって分かったことを使って本番の開発をしましょう
      • 2度作ることで色々活かせることがある

期間を半分にしてみる

  • 期間と内容を半分にして、2回に分けて開発したら?
    • なんだかうまくいきそう!

工程別の不具合の調査結果

  • Royceの図はテストは1つ
  • この資料ではV時モデル風
  • 原因工程と発見工程の違い
    • 原因は上流工程が60%強
    • 下流工程で75%発見
      • 企画・仕様・設計の問題をその時に見つけるのは難しい
      • テストは問題を見つける能力が高い
  • 試して分かることは試す
  • 試さずに調べるのは高コスト
  • 中間成果物(ドキュメント)をあてにするのは危険
  • 試してみたほうが安いので、上流工程で頑張るのはコストがかかる

利用する

  • 工程と時期を分けて考えてみよう
  • システムテスト・運用テストをより早く
  • 結合された状態でのテストを早く、頻繁に行うために反復型の開発を行う

期間を半分にしてみる

  • 1/2、1/4、1/8としていって、どんどん小さくしてみる
  • V字を行うにあたって、どこまで短くできるか考えてみる
  • 時期ざっと並べて開発するのと同じ

やり方視点

  • V字モデルの全行程をやるのが1反復
  • 小さな動くシステムから始める
  • 強のシステムを次の反復で改造する
  • じわじわ開発するのとは違う
    • V字の下部分しかやってない
    • @t_wadaが言っていることを信じちゃうやつ
  • V字の一番底だけを繰り返すもの
  • うまくいってそうに見えるのがやっかい
  • 例えば、「ブランチで作業することで、結合時の問題を避けている」という状態になったり

システムを改造する単位

  • 確認ができ、数日で終わる仕様を作る
  • ストーリー毎に全行程を行う
    • 部品、フレームワークを先に揃えるのは✕
    • ストーリー単位に必要なものを用意するのが○
  • 住みながら増築していく感じ
  • アプリケーションとフレームワークが同時に進む

製品を反復毎に確かめる

  • 不具合を確認するだけではない
  • 製品を前にして様々なことを発見できる
    • 製品の意味とか
    • この製品はどういうものだったのかとか
  • 顧客の欲しいものは顧客もよくわからない
  • 実装の問題もよくわかってない
  • 最初から分かるはずがない

プロセス=チーム

  • 出来上がって製品によって、要求が変わったりチームが変わったりする
  • チームが変わったことでどんな効果があったかを製品を見ることによって分かる
  • 要求を変えたりチームを変えたりするには、製品を作る必要がある
  • 全部が成果!
    • 製品はもちろん成果だが、その作り方とか、その途中で分かってきた要求仕様とかも成果物になる
      • 2008年では膨大なテストスイートも成果物だった
      • 自動テストではなく、手動テストだった

製造業であれば…

  • おそらく自社製品
  • 3つの成果を活かしやすい
    • 良い仕様の開発は非常に難しい
      • 何が使いやすいのか
    • 製品寿命が長い
    • 開発期間が長い
      • チームが長生きする
  • 数ヶ月でAgileとかは難しいと思う

チームの変化

  • 反復毎に何かが変わる
  • メンバーのちょっとしたふるまいの変化とか
  • わざとらしい変化以外もあったりする

やろうとすると難しい

  • よく知られている話だけど実践するのが難しい
  • なので、m_sekiならではのヒント

反復開発ならではの問題

  • プロジェクトの初めから終わりまでに起こる問題が5日間の中で発生する
    • ごまかせない。目をそらす時間がない

壁?

  • 世界のエリートは大事にしないが、普通の人にはそこそこ役立つビジネス書

おすすめ→無理をしない

  • 無理そうなことは無理そう
  • 3つの例を示す
    • サブシステム間のペースの違い
    • 工程別のチーム
    • ストーリーの分割

ペースの違い

  • 大きなシステムでは全員同じペースではないかもしれない
  • ペースの違いから揉めがち
  • 実はペースを混ぜても大丈夫
    • 結合された状態で確認するという原則を守っていればね
  • まだ結合されてない部分はリスクとして持っておけば良い
    • あるチームだけ確認した内容は信じない
  • 反復が綺麗に揃うことはあまり重要でない
    • そんなところでは揉めない
  • 隣のチームのペースを無理に変えない
    • スムーズに行っている自分達が合わせる
  • となりのチームもサボっていないのでイライラしない
    • となりのチームは遅いのではなく、実はタイミングが合わないことへの不満が多い
    • 質問しても返事が来ないとか
      • 相手の都合を聞いてみよう
  • どこまでがチームなのか、チームの切れ目に意味があるのか?
  • となりのチームの人達も同じチーうの人達のように考えましょう
  • チームの境界を曖昧にするのが吉

工程別チーム

  • ロール別にチームを作ったり…
    • 開発者とテスターとか
  • なんとなく仲違い
  • 遠慮とか不信感が…
  • 担当する工程がうまくいっているかどうか製品で確認する
    • 自分達の工程だけ上手く行っている状況はあり得ない
  • 前後の工程のチームがうまくいくように気を使おう

開発に関わる活動

  • 以下の5つ全部!
    • 欲しいものを実現する
    • 仕様を具体的にする
    • 実装を考える
    • プログラムを書く・直す
    • テストする
  • 5日間の中に全ての工程がある
  • ソフトウェア開発の加圧動画そのままロールになった
  • こうなるのが自然
    • 5日間でやるとなると自分でやらざるを得ない
  • ほかのロールは?
  • やらないことが違う
    • テスターの場合、「プログラムを書く・直す」だけがない
  • テスターは劣化プログラマか?
    • テスターならではの価値がある
    • 開発者に比べ…
      • 領域が広い・深い
      • テスターの方がより長い時間製品を触れる
      • 製品全体を触れる
      • 手触りの一貫性をイメージしやすくなる

ストーリー

  • 要求の分割のテクニック
    • 練習しないと難しい
    • パターンは存在する
  • ルール
    • 結合したシステムで確かめられること
      • 部品だけのストーリーを作らない
    • 何かしらの価値が増えていること
  • 作戦
    • 起動、主処理、終了までの最も単純なフローを見つける
      • まずはこれを作る
      • 最初は起動と終了だけ作る
        • 設定ファイルは…とか面倒なものが多い
      • その後、徐々に増築し、単純なフローを完成させる
        • 起動の面倒なものが多いので、それが終われば主処理のコードに集中できる
        • なるべく早い時期に心配な処理が試せるように工夫する
        • 枝葉を気にせず幹(中心となるもの)を作る
    • 基本フローから徐々に枝葉を増やす
      • 幹無しで枝が生えないように、いきなりリンゴを作らない
  • 階層のあるチケットはオススメしない
    • 入れ子になりがち
    • なんとなくかっこいい!
      • しかし確かめられない…!
        • 進捗が分かっても確かめられない
    • 個人の進捗は確かめられるが、製品の出来は確かめられない
  • いつも結合テストを可能にする
    • 手に触って完成した様子が分かるようにする
    • 新しいものが載っていることを確かめたい
      • 個人の進捗はどうでも良い
      • 「進んでいる」と言う割には分からない
      • 「どうやって確かめるの?」と聞いてみると良い
        • 「実は確かめられないです」「ダメだね」となったりする
  • ボタン一つは価値があるの?
    • システムが壊れていないことは分かる
  • できるだけ早く喜ばれるものにしたくなる
  • 向かい合うことは大事!

質問

チケットの粒度について。チケット1つが価値を届けるものになっているのか?それともストーリー?

  • ユーザーが確かめられるものが一単位
  • チケットはストーリー、バグ、タスクの3種類。そのうち、ストーリー、バグは確かめられないことが書いてある。
    • タスクは確かめられないもの。ほとんど書いていない

イテレーションの最初は考えるものが多いと思うが、最初はユーザーに届ける価値が無いのでは?

  • ボタンを押して起動して、終了できること
  • 少なくともWindowが出てくること

受託開発をやる場合は、お客様が出した要件通りにやらないといけない。3ヶ月でとかだと難しいのでは?

  • 難しいと思う。
  • 3ヶ月経って作ったもの見せて「ああ、ダメだね」となったり。
  • 「早く気付くために期間を半分にしてみよう」と提案するとか

ストーリーと価値の話について。「ボタンを押して起動して動くものを提供する」というものは、ストーリーを繋げて話すと思うが、お客様としては繋がらないと意味ないじゃんと言われるのでは?

  • 「価値」というと難しくなるので、「変化が分かる」と言ったほうが良いかも
  • ユーザーのゴールは一番細い線ができること

今のやり方に組織が変わるきっかけはあったのか?

  • 全員がやっているわけではない
    • 最初にやっていたのは、V字のテスト部分のみをやっていた、それによって開発が変わったりする

じわじわ開発について。非機能の部分とかも反復の中でやっているのか?

  • 非機能の多くは分けていない。
  • パフォーマンスはもはや非機能ではない。パフォーマンスはほぼ毎日触る。
  • ただ、できないのもある気がする。
  • できないものは「できないなぁ」と思っているようにする。

エンタープライズアジャイル勉強会のきっかけは?反復開発できていないと気付いたのはどこで?

  • テストのイベントでテストエンジニアが開発と話をしていないことがわかった
    • 永田さんから「これが普通なんだよ」と言われた
  • プログラマの話は、プログラムの話はあってもプロダクトに興味を持たない

ストーリーを扱うのは1本だけか?

  • 最初は少なくしていたが、どんどん増える

徐々にテスト工程が増えてくるのでは?

  • やるべきテストスイートを集めてきて優先順位を付けるツールを作った

テスト工程を全なめするわけではない?

  • 全体をカバーしているが、全なめするわけではない

疎にしていると思うが、そのアルゴリズムはどういう風にしているか?

  • 最近触ったものは暫くしなくてよいとか
    • だいたい通っているものは下がっていく
    • rateを決めていて、rateが高いものは頻度を高くするとか

ストーリーの分割が難しい。「DBにアクセスしないといけない」とか、「インタフェースを切り替えたい」といったようなものは、どういうタイミングに行うべきか

  • 増築していくと辛いから整理したいときとかで。

その結果、何が良くなるのか?

  • 次の増築がやりやすくなる

リファクタリングしたい」という要望が出る場合は?ストーリーなどが書けないと思うが…。

  • それで何ができるの?
  • 言ってくる自体怪しいよね

増築するとぐしゃっとなるのでは?

  • 数日で終わる経験が多い。それだけ大ジャンプしてないのかも。
  • 限定的にするように話をすり替えているのかも

大企業だけど新規ビジネス開発をモブプログラミングでやってみた #xpjug

スライド

speakerdeck.com

カンファレンス

  • カンファレンスは発表者に直接聞けるのが売り

現地

  • 真ん中の写真は従業員ボード
    • 自分ができること、出来ないことを書いている
    • 付箋には、他者からのコメントが書いている
  • 右側の写真は技術について、TDDとかBDDとかカンバン、リファクタリングとか

Hunter社のモブプログラミング

  • 社内に6つぐらいモブが存在する
    • 川口さんが現地に行った時には8つぐらいになってた
  • 1つのモブに付き3〜5人
  • 隣のモブは全く別の技術領域
    • CDの話
    • UIの話
    • サーバーサイド
    • 製品の制御系
    • Android
  • 常にモブプログラミングをしている
    • この時間はモブプログラミング、というような働き方ではない

環境

  • 大きいモニタ2枚と、長机
  • 楽天では、ディスプレイ2枚とPC
  • エンジニアは1日中タイピングしていることが無くて、だいたい調べているはず

作業内容

  • 分担を決めてやると、他作業者の同期の時間がかかる
  • モブの場合、常に同期をしている状態
  • お客様のところへ行くと、人事の人がほしいと行っているものに、発注者と利用者が違うので、欲しいというものに違いがある
  • モブプログラミングでは作る量に限りがあるので。
  • 業務担当者から要望が出ない
    • 業務担当者はソフトウェア開発をしているわけではないので、時間がない
  • バグ=思いもよらない挙動なので、予想できない
  • コードの量に比例してバグの量が増える
    • 一番良いのは作らないこと
  • やり方を直すようにしている
  • 打ち合わせの後に、伝言ゲームを使ってクレームが来た
    • クレームがくるのは良い。伝言ゲームを辞めろ

10年ぐらい出てから気付いたこと

  • お客様は成果物の想像が出来ない
  • 引き継ぎは問題の強調解決しないとできない
    • 2週間や1ヶ月では、業務手順は引き継げるがスキルは引き継げない
    • 問題が出てきた時点で、どうやって解決するか話し合う必要がある
  • 人は忘れやすい生き物なので、備忘録は必要
    • 手順を書くだけでなく、どうしてその手順が必要なのか書く
  • 情報ラジエータとして壁に貼る
  • モブプログラミングはコード・情報・情報ラジエータ・ヒトが必要

取り組んでいること

  • 全員で客先に行く
  • 「来週は何がほしいですか?」と聞く

質問

  • 誰もいなくなっちゃう場合には怒らないのか?
  • モブプログラミングは評価と紐付いている。誰もいないところに参加するだけで、評価が上がる
  • リーダーはいるか?
  • それっぽいヒトはいたが、明確に決めているかどうかは分からない

【基調対談】ワークスタイル改革を実践者する二人が、働き方の本質を語る #xpjug

はじめに

  • その場で聞きながら書いたため、間違っている箇所があるかもしれません。
  • 指摘箇所があれば、コメント等でお願いします。*1

自己紹介

倉貫

  • XP祭りは10何年参加している
  • いつの間にかスタッフだといわれ、スタッフMTGに参加していたらいつの間にか会長になってた

  • 働き方という話

    • 社員の半分が全国で在宅勤務&コミュニケーションはチャット
  • 働き方改革と改めて言われても、昔からやっているので質問されても困る

青野

  • サイボウズで代表をしている
  • 元々プログラミング少年だった
  • MSXを購入し、大学はコンピュータ・サイエンスを学んでいた
  • 1年先輩の同研究室の畑慎也さんのプログラムを見てショックを受けた
  • 松下電工に入社したが、120人に対してPCが3台しか無かった。
  • macのパワーブックを自費で購入して、GW後に持ち込んだ
  • インターネットのブームに乗って、新卒3年で辞めてサイボウズを起業した
  • 16年ぐらいプログラミングはしていない
  • 「働き方」とか興味ない

  • 最初の頃のサイボウズは良い感じでブラックだった

  • 25%ぐらいの離職率があった
  • 社員に「ワガママ言って」と伝えたら、「残業したくない」とかいっぱい要望があった
  • 色々やったら5%ぐらいまで減った

  • 電通の事件があって働き方改革に注目された

  • 昔も死ぬ例があったが、今は厳しい。
  • 残業をさせないために、「帰れ」と言って、責任逃れをする
  • 最近、「働き方改革に関するお詫び」の広告を出した。
  • 働き方改革が曲解されてると感じている

倉貫

  • 昨日もコードを書いている
  • 学生時代からベンチャーで働いている
  • それまで家庭教師や寿司屋のバイトをしていた。
    • 自分の性格と合わなかった
  • よく考えたらプログラミングでバイトを募集しているな
    • プログラミングで遊んでいたらお金になる
    • こういう仕事いいな
    • 一生プログラマーでやりたい
  • 就活時は就職氷河期だった→大企業に行こう
  • 独立系SI&オブジェクト指向ができる会社
    • →オージス総研or東洋情報システム(TIS)だった
  • 99年はプロジェクトマネジメント全盛期だった
  • 2000年問題があったので、プログラマが必要だった
  • 入社直後、「これからTISはマネジメントの会社になります」という方針を聞いて「えっ!?」となった
    • 配属しようと思っていた部署も3月末で廃止に
  • 周りは「IT業界に入りたい≠プログラミングやりたい」だった
  • マネジメントが出世コースなので、マネジメントやります
  • 社内で合う人がいなかったので、社外に出たらXPJUGがあった
  • 参加したら、社内のマイノリティの人がいっぱいいた
  • 社外に出ると、物差しが増える。社内だと上司しか物差しがない
  • すごいと思う人がお酒を飲むと普通のおじさんだった
  • 発信しているうちに、社内でも面白いやつがいるとウワサになった
  • 「色々やってクビになろう」と思ってた。
  • 真面目な働き方が分からない

青野

  • 社内ベンチャー時代にお会いしたことがある
  • 独立後「納品のない開発」とか、おかしなこと言ってるなと思ってた。

「納品のない開発」について

倉貫

  • TISから独立した頃は、仕事は自社開発のものだけだった
  • せっかく独立したので、まずは会社のビジョンを考えよう
    • リーダーがどうこうではなく、乗組員の顔を見て決めればよい
      • 独立した5人が全員がプログラマだった
      • 一生プログラミングをできる会社に
  • 営業とかマーケティングが必要だった
    • 用もないのに人の家に行くのが辛い
      • 受託開発するしかない
      • ただし下請けはヤダ
  • 開発は繰り返しをすべきだなぁ
  • けど1回こっきりの納品がある
    • お客様も納品した後に言ってくるし
  • 儀式で納品しているだけなのでは?

  • 最初発表した時は「意味が分からん」「そんなのでうまくいくわけないでしょ」と言われた

  • 「無理でしょ」と言われると頑張りたいと思った
  • 理解してくれる顧客も出てきた

  • 例えば、電力自由化によって、電力会社が自由に作れる

  • 東京電力がメーカーになって、小売業者が作れるようになった。
  • そんな電力会社が顧客に
  • 1人で電力会社の基幹システムをRuby+AWSで作ることになった
  • SIerの場合、電力会社の基幹システム=数億となっていた
  • 電力会社も投資して…とか
  • 電力会社の仕様は頻繁に変わるので、ウォーターフォールでやっていると全滅してた

青野

  • PJの失敗するだけならまだしも、死人が出ているのはちょっとね
  • やらされ感が出てくる仕事があって、喜びを奪っていた

倉貫

  • お伺いを立てないといけない
  • WFの上流で決めた人は楽しくやってる
  • 夢語っているうちはそりゃ楽しいさ
  • 最後までケツ吹けば良いのに逃げていく

  • 社員でプログラムができる若者は使い勝手が良い

  • 上手く行ってないPJは本当に最初から上手く行ってないのか?調べてみた
    • 下流「3ヶ月前に決まった仕様だから直せない」
    • 下流「設計のコミット、フィックスが出来なくて、けど次の工程に流さないといけない」
  • 上流に行けば行くほど清らかな世界
  • 最上流「お客様も夢があって、うちの会社も協力して、毎日飲みに行ってた」

青野

  • 仕様をなかなか決めない
  • 大きいところは、お客様にも決断を求める
  • お客さんも参加意識が出る

  • 上流と下流が離れるほど責任感が薄くなる

倉貫

  • 1週間分だけお客様に決めてもらうようにしている
  • 1周間分がダメだでも、すぐに修正ができる

現場寄りの話について

青野

  • 開発のことを聞かれても知らない
  • ちょうど、目の前の席に社員の天野がいるので、話してもらう

天野

  • サイボウズkintone開発の天野です。
  • kintoneは1年前にスクラムを導入した
  • 前までは作って出荷していた
  • クラウドは3ヶ月で出荷
  • 高速WFになってて辛かった
  • 今は2週間のサイクル
  • 社長がスプリントレビューに参加
  • QAの部門が大きいが、試験を順次回しているようにしている
  • 3ヶ月の出荷サイクルが1ヶ月の出荷サイクルになった

青野

  • 今はホワイトボードだらけ
  • 総務部門も
  • 我が家でもホワイトボードがあったりする
    • 夏休みの最後にWF的にリリースしますからね
    • 見えるようにしたが、やらないことはやらない
    • けど、9月4日には宿題を終わってた

倉貫

クラウドを扱うようになって、社内も変わったのでは?

青野

  • 一番変わったのはDevOps
  • 前までは運用はお客様任せだった。
  • スキルもないし、やりたい人がいなかった
  • クラウドになったら、運用もやる必要が出来た
  • 作るところでも意識するようになった

倉貫

  • 開発から運用へというようなキャリアになる?

青野

  • 今はないが、運用の人も開発ができるようになっていかないといけない

倉貫

  • 創業時は開発と運用メンバが分かれているが、5人だけだと運用メンバが暇になる
    • →開発やるか
    • Rubyを勉強し始めた
  • 開発者は運用が開発をし始めると「俺らの存在って…」と思うようになった
  • クラウドになるとプログラミングの延長でサーバーが用意できるようになった
  • Rubyなどになると、メモリのことを気にしなくなったり、OSSで色々できるようになった
  • クラウドOSSによって、開発と運用のハードルが低くなった

青野

倉貫

  • メンテが別人だと、「ちょっと良いかな?」と思ってしまうが、自分自身が運用することになると「ヤダ」となる

納品なくして、オフィスをなくしたが、今度は何をなくそうと思うか

倉貫

  • 次は管理をなくそうとしている
  • 経営はするが、管理はしない
  • 管理されるのは嫌だし、管理するのは面倒
  • 部署がないので中間管理職がない
    • 「中間管理職」という言葉が悲劇の元
    • だって、中間で管理ですよ!?
  • 指示命令がない
  • 自分で考えて自分でやる
  • 有給も自分で申請&承認
    • だって、上司が有給却下することないじゃん
  • 会社のクレジットカードを全社員と共有した
  • 社長も含めて全社員の経費利用状況がオープン
    • 「良いもの食ってる」と見られちゃう
  • 個人評価も無くした
    • 評価が面倒
  • 「お前、何を分かるねん」と。
  • エンジニアは評価をされにくい
    • 良いコードはビジネス的にすぐに評価されない
    • メンテ時に初めて価値が分かる
    • その時は評価されにくい
  • 「コード量少ないんじゃない?」→「コピペしたろうか」となる
  • 給料も山分け
  • 売上目標も無し
  • 結果、社長の仕事が一気に減った
  • 社員との面談も無くなった
  • 今はストレスフリー

青野

  • 基本給は?

倉貫

  • グレードはある
  • 弟子・見習い・一人前の3段階しか無い
  • それぞれのグレードの中は一律
  • 勤続年数でおまけが付く(しかし上限付き)
  • 「いつかはすごい給料になるから、今は我慢して」は無理。
    • 経済も成長してないのに。
  • 「給料上がらないから、欲しい人は副業して。」と言ってる
  • お金は十分与えているので。
  • 給料格差はない。
    • 地方だからというのも無いので、地方に移住する。良い車に乗ったりしている
    • 昨年末、スノーボードやりたいから長野に移住した社員もいる
    • 2月頭に「何回スノーボードしたの?」と聞いたら、「40回行きました」
      • スノボ、仕事、スノボ、温泉、仕事

働き方改革

青野

  • 星野リゾートの社長の提言として「働き方改革ではなく」「休み方改革」にすれば良いのでは
  • 「この時期の雪は良いから、この日に休みたい」とかになるはず

青野

  • 自分で考えて、自分でやって、自分で責任を持つ
  • 自分でPDCAを回す

倉貫

  • 自分で考えなくちゃいけない中で、会社でサポートする?
  • そういうこというと、外を見て会社を辞めちゃうかも

青野

  • 「あなたのキャリアはどうしますか?」と考える機会を半年に1回設けている
  • 「他の部署に行きたい」となったら、本部長の異動会議に載せる
  • 「今もう少しここの部署でやった方が…」とかもあるが、そういう話の結果もフィードバックとして本人に伝えている

  • 本人からキャリアチェンジを言い出せない人もいるが、上司からの逆ドラフトもある。本人は断っても良い

  • 自立して欲しいが、引き出す、ファシリテートを組織で作り出せれば

  • 出ていくと、人件費が減るんですよ。(笑)

  • 出ていく人に対して悪いと思わないほうが良い

  • 去った後に成長してれば、良かったなと思う

倉貫

  • 洗脳ではなく、魅力があるから辞めないようにするのは、すごいが魅力を作り続けないといけない

青野

  • 大企業の退職金は20年を超えた後に伸びる

倉貫

  • 普通、目標を管理すると思う
  • サイボウズさんは評価の面接ではなく、キャリアの面接なのが良い
  • 目標の面接にすると、設定を低くするはず

    • 自信家だった自分は、高いハードルを達成しなかった自分は評価されない
  • 私たちはYWTを(やったこと、わかったこと、次にやること)を話す

  • 仕事の成果を話していても意味が無くて(評価しないから)、得意・苦手を見返す機会を作る

  • 学生時代までは3,4年に1回、進路相談の機会があったが、大人になったら進路相談をしなくなる

  • 半年に1回進路相談の機会を作ろう

  • YWTは若手とベテランで違う

    • 若手はキラキラしたことを言う
    • ベテランは「向いていないことが分かりました」と言ったりする
  • 普通の会社の面接では言えないこと
  • 「これ出来ません」と言ったからには、次やることを一生懸命やる
  • そうすると不適合な人が集まるが、何か尖っている人がいる方が会社として良い
  • 弱みを見せるのが大事

青野

  • 自分の向いていないことに気付くと、得意な人を尊敬する
  • 別の部署の大変さを知らないからギスギスする
  • 営業の副業でカレー屋さんやってる人もいた

倉貫

  • 奥さんがパン屋さんをやっているが、そんな奥さんが大好きだからリモート勤務すると言った社員がいる
  • 木・金はパン屋の仕込みという副業をしている

青野

  • パン屋の仕事きたら活躍しますよ
  • プロトコルがあるんで。

倉貫

  • そのパン屋が通信販売を始めた
  • ソニックガーデンの先着販売も告知があった
    • つまり、社内で商売を始めた

質問①

質問者

  • 「倉貫さんの話の中で、クラウドになったことで組織も変わる」とあった。
  • どうやってものが出来るか分かっている社長さんですが、「俺に分かるように説明してくれ」という経営者をどう思うか?
  • なぜかソフトウェアを分からない人が経営していることが多いと思うが…

青野

  • 日本が遅れている理由の一つがそこ
  • なぜなら、これらをコストとして見ているから、
  • そういう会社は沈んでいくしか無い

倉貫

  • 社員が不幸だと思う
  • だって、説明するのが面倒
  • 管理してないので、Githubを見れば良いとなっている
  • サイボウズさんもスプリントレビューに出てるのが良い

質問②

質問者

  • マネージャはどういう風にしていけば良いと思うか?

倉貫

  • 今後のキャリアとして、1人で複数のスキルセットを組み合わせて仕事をしていくようになるのではないか
  • 例えば、今の副社長は社内のバックオフィスを作りながら仕事している
  • kintoneを使っているので、JSを開発するだけで、運用はサイボウズさんに任せられる
  • 中小企業の社長さんから働き方改革を聞かれるが、「まずはムダなことをなくしましょうよ」と言っている
  • 他社はチューニングしないところが多い。
  • 今まではやり方が分かっていなかった総務の人が、やり方を伝えるだけで改善ができる

  • 昔は「社内SE」と言っていたが、「業務ハッカー」という言葉にすればかっこいいと思ってもらえる

  • マネジメントの組み合わせる内容の一つ

青野

  • 今までのマネージャがマネジメントと称していたのは相当効率化できる
  • マネージャがいらないわけでなく、マネージャはビジョンを作って共感してもらう
  • 倉貫さんはビジョンを発していて、メンバが共感している
  • 風土を作るのがマネージャの仕事
  • より次元の高いマネジメントにシフトしないと、これからの組織はまとめられない

質問③

質問者

  • マイクロマネジメントな仕事をしていて、マネージャが優秀で成果が出ているが、組織として見た時に歪な形になっている。
  • 下が育たない。自分の経験が正しいと思っているマネージャをこういう場に連れてくるためには?

青野

  • 働き方改革は2年前ぐらいまで人事の人が聞きに来たが、2年前ぐらいからは経営者が聞きに来た。
  • 今年は情シスの人が聞きに来る。
  • 徐々に波が広がってきている。
  • もしかしたらそのマネージャも気付くかもしれない。
  • 確実に前進している。

質問者

  • 殺し文句は?

青野

  • 人手不足がはっきりしてきた
  • 「このままだと採用できない、このままだと辞めていく」

質問④

質問者

  • 「マネージャをなくしたよ」と言うと「仕事がなくなってしまう」などの受動的になってしまいがちだと思う。
  • 社員の方々は、会社に入る前からその意識だった?それとも会社に入ってから意識が変わってきた?

倉貫

  • 中途採用は働き方に共感して入ってくれる
  • 応募から入社まで半年から1年かかる
  • その間に似た考え方か見る

  • 新卒は学生なので、働き方についてはわからない。

  • 0からなので、会社の責任として育てる
  • 「会社は潰れるかも」「自分で考えて成長する」「どこに言っても通用する力は提供する」
  • と伝えれば、会社が潰れても納得してもらえるなと。

青野

  • 会社が潰れても社員がいきいきとする状態になるのが良い。
  • 元々技術力が高い人が入ってくるわけではない
  • The・サラリーマンな社員がいる。
    • 「副業したら?」と言ったら、「辞めろと言っているんですか?」と言われた
    • 結局、その人も副業探しの旅に出たりした。
  • 機会を与えるようにしている

倉貫

  • 副業はお金が入ることよりも、自分が自信を持てることが大事。

まとめ

青野

  • すごく楽しい時間でした。
  • ITエンジニアはもっと評価されるべき
  • そして逆らうべき
  • もっと給料上げろと声をあげるべき
  • 声をあげることで社会が変わるはず。

倉貫

  • オファー頂いた時に、「XP祭りで青野さんで大丈夫ですか?」「ここに連れてきて良いのか?」と思っていたが、杞憂だった。
  • 小井土さんには「遊んでいるのか働いているのかよくわからないね」と言われたが、それは正に私がやっていること
  • 働くこと自体が楽しいとなれば、本当に革命になる
  • 働き方改革を提言できるのはエンジニアだからでしょ?」と言われる。
  • 確かにそういう側面がある。
  • だからXP祭りの会場は話しやすい。
  • 皆さん、やりやすいんです。
  • 昔は資本家がいて、労働者がいる
  • 今は逆転している。エンジニアの方が価値が高い
  • お金を持っている人よりもスキルを持っている人の方が価値が高い。

  • 好きな場所で働けるかどうかが大事。

*1:既に @Mura_Mi さんに多数ご指摘頂きました。本当にありがとうございました!

Selenium Committer Day 2017『Q&Aパネルディスカッション』聴講レポート #Seleniumjp

勉強会の告知ページ

seleniumjp.connpass.com

  • 今回の記事では、この勉強会の中のQ&Aパネルディスカッションの内容を記載します。
  • 同時通訳の人の言葉を基に書いているので、若干内容が不足している可能性があります。

進行方法

  • 質問に対してパネリストが応えていく形式
  • 質問は以下のサイトから投稿&投票が出来る

app.sli.do

  • 得票数が高い質問から行う

回答者

  • 3名ともSeleniumのコミッターです。
  • Jim Evans(以下、JIM)
  • Marcus Merrell(以下、Marcus)
  • Manoj Kumar(以下、Manoj)

SeleniumプロジェクトとAppiumプロジェクトは統合する予定はあるか?

JIM

  • Noです。
  • SeleniumプロジェクトはDesktopのアプリケーションの自動化。
  • Appiumプロジェクトは目的が違うので統合する予定はない」

Marcus

  • 自分の会社ではすべてのプロジェクトをモバイルも含めて統一したプロジェクトに入れたが上手くいかなかった。
  • 結局、デスクトップとAndroidiOSを分けて管理している。

A/Bテストの話にもあったように、今後テストの対象の質が変わってくるように思います。例えば確率的に振る舞うもののテストや、機械学習のように時系列で結果が変わってくるようなものなど。今後どうしたらこうしたテストを生産性高く行えるでしょうか?

Manoj

  • 面白い質問です。
  • A/B Testingで色々なこと、クレージーなこと、異なるDOCKERイメージでパフォーマンスで比較して…とか。
  • Marcusさんもアナリティクスの話で、どちらのユーザーフローが良いのかなどを行っているが(どうですか?)。

Marcus

JIMさんのセッションで、Selenium 4でオープンソースではなくなるところがある、といったことをお話しされたような気がするのですが、少し聞きもらしてしまいました。その部分について、あらためて説明してもらえないでしょうか。

JIM

  • Seleniumプロジェクトですが、これは常にOSSです。これは強い意向を持っている。
  • ただし、コンポーネントの中のブラウザが提供しているものについては話が別。
  • 例えばEdgeDriverとかはMicrosoftが開発しており、ソースコードをリリースする決定はなっていない」

JIMさんはアルバムをリリースしているとのことですが、どういう音楽のアルバムを出しましたか?

JIM

  • いくつか出しました。ロックです。今はもう活動していませんが。
  • 例えば、{複数のグループの名前、聞き漏らした…}などのアーティストと似たような音楽です。

Marcus

  • 全然理解できませんね。

JIM

  • じゃあ、リリースした音楽についてのリンクを送りますね。

ヘッドレスブラウザが登場した時はどう思いましたか?また、皆さんは使っていますか?

JIM

  • もしもお客様が『WEBアプリの自動化したい』、そして『ヘッドレスブラウザもテストしたい』と言ってきた場合、『なぜなんですか?』と聞きたい。
  • 『ヘッドレスブラウザだと速くなるんですか?』とも聞きたい。実は速くならないです。
  • もう一つ聞く質問として、『あなた(JIMさんが相手にしているお客様)は、ヘッドレスブラウザを使ってサイトを訪問したことがありますか?』と。おそらく『NO』と答えるでしょう。
  • なのでヘッドレスブラウザのテストをする必要がない。
  • ただし、ヘッドレスブラウザが出てきた当時は各ブラウザにオプションが無かった。それが、つい最近変わった。
  • 例えばGoogleChromeでヘッドレスモードが出来た。これはChromeの一部の機能であることを意味しているので、そうなると話が変わるかもしれない。Chromeのヘッドレスモードができたということなので。
  • 私は日々のTestingで使う時、全く同じコード、振る舞いになった場合、それは魅力的になっていくと思う。

Manoj

  • 私も同じ意見です。

Marcus

  • これはメンテナンスも大変。競争性もないかもしれない。

JIM

  • UI、ブラウザレベルの自動化の目的としては、実質的なセーフティ、あるいは予測するセーフティだと思っている。
  • ヘッドレスブラウザを使うとき、使いやすいか?

司会者

  • コレに対して反論がある方…。3人を前に反論しにくいですよね。

伊藤さん*1

  • 海外で使っている事例はご存知ですか?

Marcus

  • 私自身は知らない。
  • 外資系の仕事もしていてが、ヘッドレスブラウザを推奨している立場でもあるが、辞めたほうが良いと伝えている。

海外の会社では、1つのWebサイトに対して幾つくらい自動テストを作りますか?

Marcus

  • 一番成功した導入テストとしては、ユニークなIDが全てあった時。
  • ナビゲーションが成功しているか、ちゃんとレンダリングしているかの確認で約1200通りやっていた。
  • これが2009年の話。現在も同じソフトウェアでやっていたので、今でも使っていると思う。

Manoj

  • アプリケーションも機能テストも含めて1万ぐらい(?)*2
  • これが全体の20%にあたる。
  • テストピラミッドに対しても明確な答えとして出ている。

JIM

  • 大手のグローバルで行っている企業で働きましたが、ブラウザで適切に表示されているかどうかについては、どこかで線を引かないといけない。
  • ブラウザレンダリングのバグも存在するので。それについては私たちは制御できない。
  • 何を制御するのか。ファイルをダウンロードするのは制御できるもの。
  • それでは無い部分などはブラウザベンタが制御するものかもしれない。

Marcus

  • 例えばユニークなHTMLが表示される場合、ソフトウェアアーキテクトはhtmlをQA側にも提供して、シームレスにできるようにするとか。
  • QAというのは、自分達の立場、リクエストを主張してこなかった。投げかけられるのを待っていた。
  • QAがきちんとテストするということをQA側が主張すべき。

「独立したテストはどのように作っていたのか?」

Marcus

  • このセッションはあと何時間ぐらいできますか?

司会者

  • あと30分ぐらいですね。

Marcus

  • この質問に対して語るには時間が短すぎますね(笑)
  • 例えば私達はテンプレートとしてVelocityを使っている。これを用いて開発者が作成している。
  • 一方で、私たち(QA)はPage Objectを作成した。
  • コードをチェックインする前にPage Objectを作成する。
  • それを用いて自動化で何か壊したか確認する。
  • Simon Stewart*3は生成には否定的だった(?)*4

JIM

  • Page Objectという言葉に誤解がある。
  • システムが何を生成するかというと、ページラッパーを生成する。その上に適切なPage Objectを作成すると。
  • 開発者は簡単にこういったelementのロケーションを提供するならば、各人によって楽になる。
  • このようにしてテストが壊れにくくするようにする。

Marcus

  • ページのマップを生成するようにしている。
  • テストが壊れてしまうかをチェックする。
  • そうすれば、新しいマップを更新するだけになる。
  • 通常のテストだとチェックインした1日後ぐらいで行う。
  • 開発者が12ページのワークフローを作成していた時に、1日の終わりの前に自動化のコードを書き始めることができた。
  • このようにして壊れにくいようにしていた。

JIM

  • 私が作っていたものでは、壊れやすいロケーターを確認するような企業が無かった。
  • 私がそこをチェックし、説明し、教育していた。
  • コーディングの標準を守って欲しいが、そこを分析するまでは出来ていなかった。
  • あまり自分がやるべきではないことに時間をかけるべきではない。
  • Dave HaeffnerさんがSeleniumConfでデモしたツールがあるが、非常に素晴らしいソフトウェアで、静的分析をSeleniumで実施してくれる、Runtimeでレポートを出してくれる。
  • 静的分析の結果、このコードは良いものである、ロケーターがしっかりある、というようなツールを作っている。

Marcus

  • Locationという名前のツールである。

司会者

  • ここらへんの話は掘り下げて聞きたい人が多いと思うので、それは懇親会などで聞ければと思います。

docker seleniuminternet explorerイメージはありますか?

Manoj

  • あればいいですね

Marcus

  • 本当ですね

Manoj

  • もしもUNIXでできるならばIEでできるかもしれないですね

JIM

  • ここの課題は素晴らしい。
  • これが変わらない限り、WindowsベースやMACベースの話なのですが、コンテナがおそらく無いと思います。
  • テクノロジが追いつく必要がある

Manoj

イメージはすべてあるが、UNIXのコンテナベースなので。

Selenium IDESelenium Builderの今後の動向を知りたいです。ちょっとした作業の自動化に便利です。

JIM

  • これは(JIMさんの発表の中で)少し話したと思うが、Selenium IDEはテクノロジーとしては古い。
  • Selenium Builderはもっとモダンなものにしようとしていた。
  • しかし残念ながら、ボランティアの仕事なので、中心で開発している人達はプレイバックのツールに興味がない。
  • Selenium IDESelenium Builderはユースケースがあり便利なものだが、ライブラリを作る、テストコードを長期的にできることに意義がある。
  • ソフトウェアテスト業界に25年以上に努めているが、コードを再生し、的確、適切、そして維持できるものは無かった。
  • 例えば、これが壊れてしまったのでもう一度レコードするというのは、長期的に維持できないことを意味する。
  • 学ぶ段階で使う。
  • プロジェクトチームが認識していることとして、レコードツールが無くても使えるようになったと考えている。
  • それには気付いているが、優先順位は高くない。
  • とはいえ、これをどうやって前進させるかということは話している。去年のSelenium confの後に1日話し合った。
  • コードが生まれてきているわけではない。
  • ただし、現状のSelenium IDEのコードを見たが、このコードを現状のまま使い、さらに前進させることを見ているチームもいるが、まだ時期尚早。
  • 具体的なスケジュールを言うことは出来ない。いつか。まあ、クリスマスまでにはあるでしょうね(笑)*5
  • 期待に添える答えではなかったと思う。それを欲していることも知っている。ただしタイミングとしては妥当ではない。

Marcus

画面の「見た目」のテストについて、有効なソリューションや、今後どうなっていくかについて意見はありますでしょうか。今はDOMの計算済みスタイルや画面のスクリーンショットをスナップショットとして保存し、正解として使うアプローチがあると思います。

JIM

  • 長い間、ビジュアル系のテストをやってうまくいったこともあるが、比較がfuzzyであるべきところはfuzzyで、正確なところは正確であるべき。
  • 誰かが『1px変えた』とかに対して上手くいったこともある。
  • 適切なスクリーンショットを提供すると比較するオプションを提供しているツールがある。
  • Mongoテスト(?)というものもある。残念ながらそのプロジェクトが今は存在していないが。
  • また、スクリーンショットではSeleniumでは課題がある。
  • そもそも『スクリーンショットを撮る』という行為がブラウザによって解釈が異なるからだ。
  • あるブラウザでは現在の画面表示域のみを見せてくれる。別のブラウザではスクロールする部分も含めたフルページを見せてくれることもある。
  • しかしフルページに意味はないと思っている。現在はスクロールし続けられるページがあるので。
  • ちなみにW3Cではビジュアルポートという項目で定義している。どんどんW3Cに従ってしていると思う」

地獄に落ちろと思ったブラウザまたはそのバージョンは、今までにありましたか?

Marcus

  • 時間が無いのでちゃんと答えられないね。(笑)

司会者

  • それでは時間になってしまったので、このセッションはこれで終わりに…。

JIM

  • Firefox48とIE7だと、(締めのコメントを司会者が話している間に)3人の中で合意できました。(笑)

*1:日本Seleniumユーザーコミュニティ会長

*2:聞き間違えた可能性あり

*3:Selenium WebDriverの生みの親

*4:ここらへん、メモがきちんと取れていませんでした…

*5:SeleniumConf in 2013でSelenium3.0は「クリスマスまでにリリースする」と発表したが、何年のクリスマスまでにリリースするとは言っていないという笑い話を使ったジョーク(実際は2016年にリリースした)。今回のSelenium Committer Day2017でも頻繁にこのフレーズが登場した。

JaSST'17 Tohoku 基調講演「テストの極みを目指して 〜さあ、理想に近づくための一歩を踏みだそう!〜」聴講レポート #jassttohoku

発表資料

www.slideshare.net

今回の発表の目的

  • 自分自身がテストオペレーターからテスト設計者にステップアップするための方法
    • 今日のJaSSTの参加者がみんなベテランやん!
  • 自分の後に続く人に伝えてあげる方法

改めてソフトウェアテストについて考えてみる

  • テストってなんですか?
    • 背景によって色々異なる
    • JSTQB用語集などが参考になる…けど分かりづらい
    • 『ソフトウェア技法』よりテスト担当者の精神面による区分を引用
      • 成熟度によって異なる
        • フェーズ1「テストとは動くことを示すものである」だと、テストをして何が嬉しいの?と思われがち
        • フェーズ4まで行くと「テストは欠陥予防である」
      • にしさんが「テスト道」として伝えることが多い
    • 山崎さんの言葉でいうと「テストとは品質に関わる"新たな"情報を提供するための活動」

テストの価値は情報提供の価値

  • 早い・安い・旨い
    • 早い…CIで行うことで、すぐにフィードバックがくる
      • 3日後の自分は他人である
      • リスクの高いものは早めにやることで改善できる
    • 安い
    • 旨い…有益な情報でなければならない
      • 作業をこなすことは意味がない。せっかくやった結果がうまく活用されない
      • テスト結果がわかり易いほど価値が高くなる

山崎さんがモヤモヤしていること

  • デベロッパー=開発の専門家
  • アーキテクト=アーキテクチャの専門家
  • テスター=テスト実行者≠テストの専門家
    • JSTQBでは、テストの専門家として定義している

なぜテスター≠テストの専門家と認知されないのか

  • テストに対して理解されていない
  • そもそもテストの専門家以外もやってる?
    • テストをする人がテスターだけでなく、ユーザーだったりする
  • 他の専門職と比較してスコープが広いから?
    • V字モデルの右側すべてが「テスト」ですからね。

理想のテスターとは?

  • 良いテストエンジニアとは?
  • JaSST'14 Tokyoの基調講演より(Stuart Readさん)
    • TEST SKILLS
    • IT SKILLS
      • インフラの知識とかも必要
    • DOMAIN KNOWLEDGE
      • ドメイン固有の情報
      • 満たさなければならない要件とか
    • SOFT SKILLS
      • トレーニングしても身につき難いもの
      • 例えばコミュニケーションモデルとか
        • 正しかったとしても、それをきちんと伝えていなければ意味がない
    • この4つをバランス良く習得しているのがProfessional Tester's Skill-space
    • 「テスターだからプログラミングはしません」は残念なこと。価値として提供できない

開発を加速させるための協力者というマインド

  • テストは基本的にテストそのものが目的ではなく手段である。
    • テストが安定してない→バグが出ている状態
    • そんなネガティブなことを伝えても加速しない
  • テストをゲーティング(これを通らないと先に進ませないよ)とならないように
  • 開発と対立関係ではなく協力関係にならないといけない

最初の一歩を踏み出すのに重要な3つのこと

  • テストの全体観を持つ
  • ロールモデルを見いだす
  • 成長へのモチベーションを持ち続ける
    • 動機づけしてない人に伝えても暖簾に腕押し状態

1.テストの全体観を持つ

  • テストの全体観を保つための3つの軸
    • テストレベル
    • テストタイプ
    • テストプロセス
  • この3つを理解していると非常に理解しやすくなる
  • ドラクエ1の松明のようなもの

テストレベル

テストタイプ

  • 以下のようなテストタイプがある
    • 機能テスト
    • 非機能テスト
    • 構造テスト
    • 変更部分のテスト
  • テストオペレータに何のテストタイプを行わせているのか理解していますか?

テストプロセス

  • 普通の開発プロセスと同じように、テストにおいてもプロセスがある
    • テスト計画
    • テスト分析
      • どんなテストをしなくちゃいけないのか
    • テスト設計
      • どんなテストケースを作ればよいのか
    • テスト実装
      • 実際にテストケースを作成する
    • テスト実行
    • 終了基準の評価とレポート
    • テスト終了作業
    • モニタリングおよびコントロール
  • テスト実行しか見えていないと、テスト分析とかに意識がいかない
テストケースを作るまでのイメージを持てることが重要
  • テスト設計技法は学ぶが、それを上手く使えない…
    • テストベースに対していきなりテスト設計技法を適用しているのでは?
テスト開発プロセスの例
  • 文書
  • →テスト分析してテスト設計仕様を作る
  • →テスト設計してテストケース仕様を作る
  • →テスト実装することでテスト手順仕様が作られる
    • マニュアルでなければテストスクリプトになったりする
  • 29119-2では、テスト条件とテストケースの間にテストカバレッジアイテムがあったりする
  • どうしてこのテストケースにしたの?という質問に答えられないといけない
    • 「なんとなくテストしたらバグが発見できませんでした」だと情報が少ない
テスト要求分析の例
  • 何をテストしなければならないのかをきちんと洗い出すのがテスト要求分析の一側面
テストアーキテクチャ設計の例
  • 導出したテスト観点から関連性を見出してテストフレームを定義したり、
  • 複数のテスト観点やテストフレームをまとめてテストコンテナを作ったり
    • 例えば、相互互換性のテストではOSとかブラウザとかのテストフレームがあり、それをまとめて「相互互換性」とするのをテストコンテナを作る
  • 「テストの十分性や妥当性の教えて欲しい」とよく言われる
    • 全数テストはできないので、サンプリングしないといけない
    • ステークホルダーと合意を取らないといけない
    • 合意を取るためにテスト要求分析をしたりテストアーキテクチャ設計をしたりする
テスト詳細設計の例
  • 網羅基準とかコンテキストを元にテストケースを導出する
  • これらのプロセスの最後で初めてテスト設計技法が使われる

2.ロールモデルを見出す

大まかな志向の方向性を意識しよう

  • ロールモデルは会社の人事制度とも関わるが、大きく分けると以下の2つ
    • 技術トラック
    • マネジメントトラック
      • 偉くなるためにはマネジメントトラックしかない会社の場合、自分がパイオニアになって技術トラックの方向性を作る必要がある

ISTQBより

具体的にイメージできる憧れの人を持とう

  • 可能であれば社内の人
    • コミュニケーションが取りやすいから
  • 走り出したばかりの人が「俺は海賊王になる!」と言ったら…
    • →どうやって?実現性が分からない

自分の志向する方向性を探してみよう

  • セルフデベロップメントプランを作ってみよう
    • どうやって極みを目指すか?
    • 目指すべき理想の姿において、1年後の自分・10年後の自分…などを具体的に描いてみよう
    • ある時点での姿に対して、「どのような姿か」「その姿になるためにはどうすればよいか?」を書いてみる
      • どんどん具体的に落とし込むことで、今の姿に近づいていく(半年後→1ヶ月後→2週間後)
    • 自分自身で壁を作って成長を限ってはいけない
      • そんな壁は壊してしまえ

3.成長へのモチベーションを持ち続ける

  • 成長が目に見える形で測れて実感できることが大事
  • 既存のツールを使ってみたり…
    • テストにおいてはTest.SSF(Skill standard Framework)があったりする
    • テストに限らなければITSSとかETSSとか。
    • テストの全体観が無いとそもそも測れない
  • 資格試験も自分の成長を感じられる一つの尺度
    • ただ、単調に行い続けるのが大変

ぜひ社外に飛び出してみよう!

  • 社外活動による知見・刺激は多いはず
    • JaSST
    • WACATE
    • SQiP
    • テスト設計コンテスト
  • いずれは参加者から運営側になろう
    • 社外活動に関わると今まで得られなかった情報量が増える
    • そのまま社内に適用するとうまくいかなくなる
    • うちの会社の人は分かってねぇ!という麻疹になったりする
      • 「そうじゃないんだよ」と諭してあげよう

感想

  • 「テストの全体観」ってどれだけの人が持っているんだろう…?
  • 成長へのモチベーションとして書かれている「社外に飛び出す」のきっかけの作り方(与え方)が難しいなと感じた。
  • 理想のテスターがもっともっと出てきてほしい!

#ICST2017 に参加してきました!

すごく今更感がありますが、ソフトウェアテストの世界最高峰の国際カンファレンスであるICST2017に参加してきました!

ICST2017の公式ページ(日本語版)

ICST 2017 | ICST2017のページへようこそ!

私が参加したセッションを紹介し、簡単な感想を書きます。

1日目

基調講演「The State of Continuous Integration Testing at Google. 」

  • 聴講レポートと感想はこちらの記事を見てください

nihonbuson.hatenadiary.jp

Non-Semantics-Preserving Transformations For Higher-Coverage Test Generation Using Symbolic Execution

  • 実践的なプログラムコードに対してどのように単純化し、最適なテストケースを作成すれば良いかということを考えた研究でした。

Uncertainty-Driven Black-Box Test Data Generation

  • あるプロダクトコードに対してテストケースをランダムに選択するのではなく、機械学習を用いてもっと効果的なテストを選択できないかという研究でした。

Automated Test Generation and Mutation Testing for Alloy

  • テストケースを生成する際に、カバレッジを気にしながらテストケース生成する方法があるが、それ以外にミューテーションで破壊されるようなテストケースを生成し、そのテストケースの有効性を確認した研究でした。

NIVAnalyzer: a Tool for Automatically Detecting and Verifying Next-Intent Vulnerabilities in Android Apps

  • セキュリティ的に脆弱性のあるプログラムコードを検知する仕組みを作成し、既に公開されているAndroidアプリについて脆弱性が無いか確認した研究でした。

Efficient Safety Proofs for Industry-Scale Code using Abstractions and Bounded Model Checking

  • この発表はあまり理解出来なかったです…。

System Testing of Timing Requirements based on Use Cases and Timed Automata

  • タイミングが関わる機能のテストについて、状態遷移に工夫をすることで、より有効的なテストケースを生成するという研究でした。

A Comparative Study of Manual and Automated Testing for Industrial Control Software

  • 同じ製品に対し、自動テスト生成と手動テスト生成を行って、カバレッジやミューテーションがどのように違ったのか比較した研究でした。

How Do Assertions Impact Coverage-based Test-Suite Reduction?

  • 一般的にはテストカバレッジを気にしてテストケースの削減を行っているが、Assertionを気にしてテストケース削減を行ってみた研究でした。

Automata Language Equivalence vs. Simulations for Model-based Mutant Equivalence: An Empirical Evaluation

  • ミューテーション、ランダム、ユースケースからのそれぞれのテストケース作成に対して、強度なミューテーションが発生した場合に検出が出来るのかという研究でした。

2日目

基調講演「Testing and Validation Requirements for Automated Driving Technology.」

  • 自動運転についてトヨタの方が発表しました。
  • トヨタがどのような考えを持って研究しているのか、どのような最新の研究が行われているのか発表していました。

Perphecy: Performance Regression Test Selection Made Simple but Effective

  • パフォーマンステストの回帰テスト方法について提案した研究でした。

A Selection Method for Black Box Regression Testing with a Statistically Defined Quality Level

  • 過去の故障確率に基づいたテストケースの選択方法を提案した研究でした。

Private API Access and Functional Mocking in Automated Unit Test Generation

  • プライベートメソッドに対しての単体テストを上手く行う方法を提案した研究でした。

Using Semantic Similarity in Crawling-based Web Application Testing

  • 自動テストで用いられるDOM要素をベクトル化して、機械学習でどのような値が入るのか自動的に判別するという方法を提案した研究でした。

Barista: A Technique for Recording, Encoding, and Running Platform Independent Android Tests

  • Androidテストを行うツール Baristaの紹介とその効果の検証についての発表でした。

ATOM: Automatic Maintenance of GUI Test Scripts for Evolving Mobile Applications

  • Versionがどんどん更新されていくようなツールに対してのGUIテストのアプローチの提案をしていた研究でした。
  • 状態遷移図を描けば、振る舞いが大きく変わらない状態ならば対応できるはずだ、みたいなことを言ってた。

Transferring State-of-the-art Immutability Analyses: Experimentation Toolbox and Accuracy Benchmark

  • 正直、よく覚えてない…

Accelerating Test Automation through a Domain Specific Language

  • GebやSelenideといったSeleniumラッパー系のツールATAPの紹介
  • eclipse上でサジェストが出るのが特徴
  • 休憩中、発表者に色々と質問した。

Taming Coverage Criteria Heterogeneity with LTest

  • 一つ前の発表の内容ばかり考えててあまり覚えておらず…。

3日目

基調講演「Model-Based Testing and Model Inference: Better Together!」

  • モデルベーステストのお話
  • テスト設計も自動化出来るという夢のあるお話だったが、イマイチ自分の言葉には咀嚼できず…。

Are there any Unit Tests? An Empirical Study on Unit Testing in Open Source Python Projects

  • Pythonで書かれたコードのテストがISTQBで定義されている単体テストになっているか調べた。
  • 調べ方は、テストコードが1つのimportだけを読み込んでいるかどうかで判断した。
  • 疑問点が一つあったから発表者に質問した。

パネルディスカッション「Bleeding-Edge Testing Challenges that the Software Industry Faces - an Invitation to Researchers to Address these Challenges」

  • 聴講レポートと感想はこちらの記事を見てください

nihonbuson.hatenadiary.jp

パネルディスカッション「Quality and testing in Software Engineering curriculum」

  • 聴講レポートと感想はこちらの記事を見てください

nihonbuson.hatenadiary.jp

全体的な感想

色々と社内、国内だけでは知り得なかったことが感じ取れて本当に良かったです。

おまけ

  • 朝食(毎日バイキング形式で提供されてた)

f:id:nihonbuson:20170412004012p:plain

  • 1日目の夕食(立食形式)

f:id:nihonbuson:20170412004025p:plain

f:id:nihonbuson:20170412004033p:plain

これらも参加費にコミコミでした。