大企業だけど新規ビジネス開発をモブプログラミングでやってみた #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

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

#ICST2017 基調講演「The State of Continuous Integration Testing at Google」聴講レポート

はじめに

  • ICST2017の中で、「The State of Continuous Integration Testing at Google」というタイトルでGoogleのエンジニアであるJohn Miccoさんが基調講演を行いました。

  • ICST2017公式ページ

ICST 2017 | 10th IEEE International Conference on Software Testing, Verification and Validation

発表スライド

http://aster.or.jp/conference/icst2017/program/jmicco-keynote.pdf

今日話すこと

  • Googleのテストの状況を話す
  • 開発者が3万人頑張っている

Googleについて

  • 420万のテストケースが継続的に動いている
  • 1億5千万のテストケースが動いている
  • ほぼ全てが自動化されている
  • Googleは自動テストが好き
  • 開発者はテストに時間をかけられません
  • 1万3千行のプロジェクトチームがある
  • 99%がテストに合格している
    • 失敗することはたまにある

テスト文化について

  • 自動化テストを促進する文化がある
  • 10年の文化がある
  • コードビューがある
  • テストの経験についても話し合う
  • Googleの新入社員に対してテストの仕方を教える
  • SETIでテストについて教えている
  • コードビューでモニターしている
  • チームに取り込まれているプラクティスを行う
  • 他にも色々行われている
  • 420万のテストは開発者が行っている

回帰テスト

  • 1つのbranchで何十億ものコードがある
  • それを3万人の開発者がテストをする
  • どの回帰テストをするのかの選択が大切
  • 例えばfoo.hを選んだ場合は赤部分のところをテストする(スライド5ページ)
  • 選択が適切にできればスケジュール化しなくても良くなる
  • クレームから状況を解析して行う
  • 1秒間に変更を2つ行うとBackendが追いついていかなくなる

Presubmit testing

  • 粒度の細かい従属性について見ていく
  • 同じプールを使って
  • Presubmit testを上手く使ってコミットを行う
  • コードビューツールがテスト結果を検知して却下したりする
  • 開発者の判断ミスによって壊れないようにする

Postsubmit testing

  • リグレッションテストが上手く行っても、それでOKではない
  • テストの優先順位は付けない
    • 時間がかかるし
  • なるべく並列に行う
  • Backendとしてキャパシティがあるか確認する
  • スケジューリングの場合、どこかが空かないとやれないから
  • passしたらflagをたてて変更を書ける
  • 2年間のテスト結果やコンソールログを保存している(DBに入れている)
    • どのようなファイルのエディットをしたかなど

グラフ

  • チャンジリストを表している(スライド10ページ)
  • 横軸が時間、縦軸が個々のテストを表現している
  • グラフの1つ目の縦軸は回帰テストを4つ行うことを表している
  • 今までの変更を見て、マイルストーンを引いて、多くのテストのトリガーを引くことになる
  • キャパシティが溜まった時にテストが行われる
  • 45分間ごとにテストを実行される
  • 1日1回45分ぐらいで行われる
  • 最も直近で影響を受けた変更を探し出す(スライド11ページ)
  • きちんと順番通りになっていない可能性もある(スライド12ページ)
  • これをDBに入れて、どれがGreenなのか探す
  • 失敗した場合、何が原因で失敗だったのかを明らかにする(スライド14ページ)
  • どの変更がBreakしたのか判断する必要がある
  • 回帰試験のセレクションをして、スケジューラが必要になる
  • これを塊にしなければならない
  • キューに入れてバッチに入れる
  • もしある特定のシステムが受けた場合、システムのものなのかユーザーのものなのか明らかにする
  • ツールが失敗した場合は再実行を行う
  • 開発者のサブミッションと合格・不合格の判断をなるべく速くする
  • マイクロスケジューリング
  • 原因がどこにあるのか
  • ケースのリストアップをしていく
  • ギャップを埋めていく
  • 開発者が破壊する恐れがある
  • 限られたリソースで済むようにする
  • 破壊実験をしていく

Flaky(スライド21ページ)

  • あてにならないテストのこと。
  • コード以外のものには従属していない
  • テストのアイソレート化、切り分けが必要
  • 全体の16%はFlakyである
  • プロダクトのリリースをブロックすることが多い
    • 全てのパスしなければいけない
  • 16%はいつかFlakyになる
    • 全体で1万近くのテストがあるので1000近くある
  • 何か問題があるとFlakyだから、となってしまう
  • 2%〜16%はFlakyテストを再送されることになる
  • このFlakによって赤信号になってしまう
  • マイクロスケジューラだとパスするかなと思うかもしれないが、緑にするためには、Flakyもクリアする必要になる
  • プロダクションコストに関してはフレーキになる
  • どのくらいのコストがFlakyにかけてしまうのか

  • 何が原因なのか

  • テスト実行の1.5%がFlakyの継続率になる

    • これをFixさせないといけない
      • Fixさせるのは時間がかかる
  • Flakynessを緩和しないといけない

システム

  • Flaky testを認識する
  • failedになると、Flakyになるか確認する
  • 10回それを走らせてFlakyであると判断する
  • スタックトレースもDBに保存する
  • Flakynessレベルに変更になる。(1%のFlaky率から5%のFlaky率に変更など)
  • 自動テストをして、Flaky状態も管理する
    • 例えば、50%のFlakyになるGmailは上手くいかないだろう、とか

OSS

  • Bazelなどのように、OSS化して公開しているものもある(Bazel.io)

学会のリサーチについて

  • OSSプロジェクトのものに対して仮説をたてる
    • 実用性には欠ける
  • Sponser resercherの方々や学生に協力を頂いて、データセットのペーパーを出している
  • Googleコードベースも仮説をたてている
  • 1つのテストがFailになった時に何が原因なのか調査している
  • 1億5000万のテストの結果をOpenにしている
  • 業界と学会のコラボレーションで解決ができるはず
  • API frameworkも作成している
  • かなりのビジネスチャンスがある
  • インターンシップもある
  • journal clubに参加すると、月刊誌をお送りする

質問

3rdPartyについて

  • 異なる言語の自動化をどのように行っているのか
  • また、テストコードと開発コードを同じ言語ですべきか
  • 他の言語で書くこともできるが、枠組みとしては同じ言語で行う
  • 慣れ親しんでいる言語で行う

コンカレンシー問題

  • Flakyテストだとコンカレンシー問題があると思う
  • Flakyの診断をする。もう一度実行するなどを行う
  • ある程度のレベルのFlakynessはあるがそこまで心配していない
  • パーフェクトな状態ではない

マニュアルテストとの兼ね合いについて

  • マニュアルテストとのリンクにしているのか
  • マニュアルでメンテを行っている
  • 必要でないdependencyは削除しているが、基本的にはマニュアルで行う
  • 過度に依存している問題はあるが許容する必要がある

包括的なテストについて

  • 包括的なテストであるが、どのような形でどのタイプを行うと選択しているのか。
  • ある制約がある
    • どのくらいの規模で…
      • 15分
      • 4Coreで
  • E2EテストはFrameworkの中で行う
  • 大きなインテグレーションテストを行う時、45分の中でテストをしていく。
  • システムテストだけではなく必ずUnit testとシステムテストの両方が必要である

Flag optionについて

  • Flagの組み合わせの問題に直面にしなかったのか。
  • 全ての組み合わせをテストするのは不可能ですよね?
  • Flagの組み合わせに対しては相当きつい制約をしている。
    • 例えば、キャッシングに制約をかけるようにしている。
  • 例外にすることはできるがほとんどしていない。
  • Optが失敗してDebugが成功することもあるが…。

  • 400万のこーどがあると言っていたが…。

  • プロダクションテストはあるが、その他のテストはしない。
  • 新しいVersionとして全てうまくいくか
  • プロダクションサーバイメージに対して行う
  • sandboxテストとプロダクションテストは違うということか?
  • そうです
  • これはABテストか?
  • そういうことです

420万のテストケースについて

  • 420万のテストケースは増えていっているのでしょうか?
  • テストプールは常に増えていっている
  • テストケースの最適化は行っているのか?
  • 自動化の分析は行っていない。
  • ただしテスト品質の解析をしている。
  • 例えば、テストが成功ばかりしている場合、そのテストは必要ないのかもしれない
  • Backendが有限になると思うと、テストの質に意識するようになった。
  • テストについても何らかの責任をもたせることは大切

  • UTestで開発者が作ったもの。自動的なケース。自動化で良い点。どこでどこで使われているのか

  • テストを書くことが企業理念になっている
  • テストリソースを消費してしまう
  • 探求にも時間がかかってしまう

感想

  • テストケースをbreakした時の判断の仕方が良いなと感じた。
  • 「Flaky」という言葉を使って、テストの種別をするというやり方は参考になった。

「ソフトウェアエンジニアリングカリキュラムの中での品質とテストについて」パネルディスカッション聴講レポート #ICST2017

はじめに

  • ICST2017の中で、「Quality and testing in Software Engineering curriculum」(ソフトウェアエンジニアリングカリキュラムの中での品質とテストについて)というタイトルで、各国の大学教授・准教授が登壇して、パネルディスカッションを行いました。

  • ちなみに、聴講者も意見を出していたのですが、意見を出していた殆どが、前回の記事で書いたGoogleAppleのエンジニアだったと記憶しています。

nihonbuson.hatenadiary.jp

  • ICST2017公式ページ

ICST 2017 | 10th IEEE International Conference on Software Testing, Verification and Validation

このパネルディスカッションのコンセプトについて(司会のShlomo Markより)

  • 最近4年間でソフトウェアのエンジニアリングをやっている
  • ここでは、ホワイトペーパーを出している。
  • Test、クオリティについて産学連携には沢山の問題がある。
  • それに関しても、私もできるだけ研究に移したいと思う。
  • それでは、パネリストの方には自己紹介をしてもらいたいと思う。

自己紹介

  • パネリストには、何を課題として考えているのか伝えてもらう。

Ina Schieferdeker

  • 品質エンジニアリング、解析についてもどういう教育が大学で行われていくのか考える必要がある。

Jens Krinke

  • 当初、ソフトウェアエンジニアリングのプログラミングに関しても、問題解決ベースだった
  • 学生は最初からアプリケーションを作っていた。
  • 学生はハッキングなども技術をやったりもしている。
  • しかし本当の意味を理解していない。
  • 普通のところからソフトウェア・エンジニアリングを話すことになる。
  • テストもそうです。
  • 5年間を考えてみると、業界が変化していくので追いつかなければならない。
  • コンセプトを考えて、テストの要素をなぞらえていかなければならない

Tanja Vos

  • プログラミングをしているのに対し、テストコードを書かなければならない。
  • それは難しい。
  • テストに関しては教えを請いたくないと言われる。
  • 教えるときには、何がステートメントなどを教えて、テストの方をやらなければならない。
  • しかしテストを後から教えることになっても意味がない

森崎修司

  • 私はソフトウェア工学を教えている。
  • 大学と大学院の両方で教えている。
  • 論文のリクエストやコメントもやっている。
  • その他、博士号過程などで教えている。
  • このディスカッションを行っている中で色々と産業界に提起したい。

討論

Shlomo Mark

  • 各国でどのようなことを行っているか。
  • 例えば私の場合、学生はマシーンランニングがやりたいと言ってきたりする。
  • そのときには最初から品質やテストを教える。
    • 問題に直面するから。
  • そしてUnitテストに入っていく

Ina Schieferdeker

  • 動機づけは、ソフトウェアの作っていることの安全を考えなければならないから。
    • 最近の研究ではエアバッグについて。
    • 他にも医療機器とか。
  • そういったところから見ると、テクニックだけではなく、例えば専門家になったときの責任も教えている。

Shlomo Mark

  • 学生になぜテストを教えるのかが難しい

Ina Schieferdeker

  • 皆さんの仰るところは私も思う。
  • 私は何にそれを適用するのかを教える
  • 研究側ではプロトタイプを使う。
  • ソフトウェアの重要性がある。
  • システム側の品質も必要になる
  • 20年関わっているが、「なぜこれをやらなくてはいけないのか」と学生に問う。
  • どの部分をやっているのかを明らかにさせる。
  • 本当の意味での品質レベルを製品に落とし込まないといけない。

聴講者

  • シリコンバレーの場合、どのような理由でできないかをはっきりさせる。
  • テストに関してバックグラウンドがある人しか雇わなければ良い
  • なので学士以上のところが必要

Jens Krinke

  • このような比較ですが、例えばマシーンラーニングだけしたいと言ってくる学生がいる。
  • そういう学生に対してはソフトウェアテストや品質は学ぶ必要がない。
  • ただし、エンジニアではない人がやるとなると一貫性が無くなる。コンセプトがなくなってしまう。
  • パッケージに関しても、最初に品質を学ばなければならない。

Tanja Vos

  • 教育の最初にクオリティを学ばせないといけない
  • 例えば、
    • プログラムを見ていく。
    • 学生に関してはプログラムで検証していく。
    • デバッグをしていくときに対してUnitテストをさせたりして埋め込む必要がある

聴講者

  • テスト志向というのは非常に大切。
  • どれぐらい文化を変えるのに、テストを分かっていない人を変えるのがすごい大変です。というか不可能です。
  • テストを学んでいない人にテストの話をすると、その瞬間に水を失った魚みたいな顔になる。
  • 結果的に、そういう人を雇用できなくなる

Ina Schieferdeker

  • それから教授がいかに説得させるか。
  • 論文などをICSTに参加している方に向けて書いていますが、学生の教育のタスクとしても書いている。

聴講者

  • 機械学習をやっていてもコードを書いている以上、それを健康的な状態に保つためにはテストが必要。

聴講者

  • 5年間Masterでコンピュータ・サイエンスをしている。
  • 1年目からテストケースを与えてテストコードを書いている、実際に開発者テストを書いている。
  • よりテストパターンとしてできるものをやっていく。
  • 上手くいっているところもあるが、Functionalテストになると、どういう風にやっているのか分からない。
  • ツールも入れて、そこの部分も学生に紹介しようと思っているが、それは出来ていない。
  • テストの話をすると、コードがテスト無しで正しく動いているかどうかという方向性にいってしまう。
  • 文化として試行錯誤するという考え方にできていない。
  • ダメならば別のコードをやればよいとなってしまう

聴講者

  • テストを書くことのクールさに学生が気付いていない。
  • 大学に入る前にテストを書いているという人がいない。
  • なので、カリキュラムの中でも厳しくする必要がある。
  • 例えば、コンテストをするとか、インタフェースを設けるとか。

聴講者

  • これは学生の問題ではない
  • ツールやチャンスはある。
  • この命題に関しては好きな人もいるはず

Jens Krinke

  • 学生がこれが好きではないという話については、学生的にはやることには問題ない。
  • こちら側がカリキュラムを変えている。
  • 多分、1,2年あたりで起こると思うが、4年生の方のカリキュラムを変えている。
  • 同じモジュールを異なったコードにしたり。
  • ソフトウェアエンジニアリングをどのように改善していくのかも大学でやっている

聴講者

  • 学生への教え方が変わっていっていくことに驚いている。
  • 一緒にやっていこうというアイディアですね。

聴講者

  • 最も賢い1年生に対して「テストをやっていないとパスできないよ」と伝えてほしい。
    • それがたとえ宝石のようなプロジェクトをやろうとしていても。
  • テストを書かない人は無理です。そのような人はGoogleのインタビューでは受け入れません。
  • 我々はテストを扱える人を求めている。
  • マーケットも求めているし、アカデミックもそうでしょうか?

森崎修司

  • 優先順位について。何がいちばん大切なのか。
  • 同意です。
  • グループワークをやっていて、何人かの学生はそれを学んでシェアする必要があると思っているようです。
  • プログラミングの講義をやっていると、何人かの人は本人で学んでいく人もいる。
  • テストは教えられるべきものなのか。
  • QA活動は気付いたり、生徒自体が発見していくことが大切ではないのか?

聴講者

  • quality testingについてはどう考えているか?

Ina Schieferdeker

  • 大抵は比較をしている。
  • テスターが沢山いるので、大学で学んでいる人もいるので、ソフトウェアエンジニアリングが厳格に勤勉に学んでいかなければならないものである。
  • ソフトウェアエンジニアリングは完璧なものではない。
  • 他のものも鑑みた上で、何をプログラム化すべきなのか。
  • ソフトウェアエンジニアリング以外のものも含めて、より厳密に扱っていく。
  • 例えば、パブリックセクターとプライベートセクターの両方で構築すべきだと思う。

Jens Krinke

  • いや、そうは思わない。
  • クオリティは他の人がやってくれるからと言われてしまう。
  • これは何年も前のやり方で上手くいかない
  • ソフトウェアエンジニアリングの経験を積んだ人が扱う。
  • 大学では品質を教えることができないのだと思う。
  • セルフエンジニアリングのトレーニングはできると思うが、大規模なことをやっていないので品質のトレーニングは無理です。

Tanja Vos

  • 別の講義で教えるということはダメだと思う。
  • 最初からテストについて教えるべき

聴講者

  • 私は少しだけ同意する。
  • そもそも教育時間が短い。
  • きちんとしたエンジニアを育てる、ある程度の教育、プリ教育として、クオリティエンジニアに関しては1つ1つ教えるだけでなく、他のことも教えることになる。
  • 他の専門性も含めて学ばなせなければならない。
  • 博士号でその道のスペシャリストを育成できればと考えている

聴講者

  • どなたか共創の話があった。
  • ベストスキルというようなコミュニケーションが必要だと思う。

聴講者

  • 私は2つのトラックに分ける必要ではないと思う。
  • エンジニアである場合、もちろんソフトを書いてテストを書かねければならない。

Shlomo Mark

  • テストを教えるとして品質は教える必要があるのか。

聴講者

  • 産業界では別にしている。
  • ただ、別々にしていると上手くいかない。
  • テストも書くのが仕事ですよと。責任を持ちなさいと言っている。

聴講者

聴講者

  • 同じ人がやっている。
  • どういうレベルであっても、自分で作ったのならば自分でテストをしなさいと。
  • なので、システムテストレベルについてはツールを提供したりしている。

Ina Schieferdeker

聴講者

Jens Krinke

Ina Schieferdeker

  • そんなことはないです。
  • テストマネージャはプロダクトマネージャよりも給料が高いです。責任が重いからです。ただし、学生は実感できませんが。

聴講者

  • 学術界の把握ができて嬉しく思った。
  • ただ、その中で大学を通じて色々な課題がありますが。
  • 大学の中で教授で産業界の経歴がある人は?何%ぐらいがそうなのでしょう?
  • 会場を見る限り半分くらいでしょうか。
  • 私は学生だが、このようなコンセプトについてそのようなクラスを受けたいと思うが、実例を学びたちと思ったとき、ソフトウェアのトピックが無くては学べないと思うが。

聴講者

  • ITに10年いますが、テスト駆動形のプロセスです。
  • このようなことを扱えて、学んだことが扱えてよかった。
  • テストでも色々な階層があるが、フォーカスしているのはどのようなテストタイプですか?ストレステストなどがあるが。

聴講者

  • Microsoftの場合はそれぞれ分かれている。
  • プロセスに関しても。
  • Microsoftの場合、お互いに役割がある。
  • ただ、Murat Ozturkさんに同意するわけでない。
  • 違いがあります。
  • Writerがいて、スケールがあります。
  • 少し大きい場合はテストオートメータの友人を入れる。
  • マシーンラーニングとかもそう。

Shlomo Mark

  • 時間が来てしまいました。最後にどうぞ。

聴講者

  • どのようにテストプロセスを作っているかについては、どちらの方法でも良い。
  • 開発プロセスに注入していくか、うまくいっているのか、カバレッジはきちんとしているか。
  • どこかに穴があってはまずい
  • トータルカバレッジを考える
  • プロセスの問題というよりもアプローチの問題。
  • 私のチームもそう
  • インフラでも楽しむことが重要。
  • 使っているコードはテストを作るときにも使っている。
  • テストの世界でも分かるようにする。

Shlomo Mark

  • 何を教えれば良いのかはペーパーも出てきています。

感想

  • 「テストを大学で学ばせる」ということ自体、日本の大学ではなかなか出来ていないことなので、世界とのギャップを感じた。
  • とはいえ、世界的にも教育について悩んでいるのかなとも感じた。
  • さらに「プログラミング」「テスト」を講義として分ける、テストの講義を後から実施すること自体も否定的な意見が多かったのが印象的でした。