#はじめに
ソフトウェアテストシンポジウム 2018 東京（JaSST Tokyo） はソフトウェアテストのカンファレンスとしては国内最大規模で、最新動向の紹介と情報共有を目的として開催されています。
２日間まるまる参加してきたのでその様子をざっくりレポートしてみました。
Web系のQAとして働き始めて約1年。
まだまだ駆け出し故の浅掘り、薄い考察がキラリと光る内容になっていますが、QAってなにやってるの？という方にもわかるような記述を心がけてみました。
なんとなくの雰囲気だけでも伝われば嬉しいです。
タイムテーブルのとおり、同時並行で色々なセッションが開催されてるため、本稿は筆者が参加したセッションのみの報告となります。ご了承ください。
そして若干の（いや、たくさんの）誤解釈があると思うのでそこは玄人の方々にフォローしていただけると大変嬉しいです。
#今年の目玉：基調講演が Google の John Micco 氏！
お題は「Advances in Continuous Integration Testing at Google」。
すごく平たくいうと、 開発したソフトウェアコードを自動的にテストして自動的にデプロイする 、というCI（継続的インテグレーション）をGoogleでどうやっているか、その経験から得られた法則や課題を紹介してくれるという目から鱗企画。
まず知っておいた方が良い、Googleのテスト事情
規模感
- 420万件のテストが継続的に（＝何度も繰り返し）実行されている
- 1日に1億5000万件のテストが実行されている
と↑このようにとんでもなく大規模。
当たり前ですが世界中で使用されているGoogleのサービスは日々進化しています。
進化したサービスをユーザに届ける上で、テストはとても重要なチェック機構です。
そのサービス普及率とユーザーニーズの高さ故、 Googleではテストをすべて自動化している。 （ 我々はマニュアルQAに割く時間なんてない）だそうです。。。
ただただ納得。でもそのばっさり言い切るところにとにかく唖然。。。
会場にいたおそらく全員の方が「マジかよ」と唖然としていました。。。
成功率というか達成率
- 実行しているテストのうち99%が成功してる
99%成功は聞こえがいいのですが、裏を返すと、 1%失敗してる 。
1%といっても150万件。。。
1日に150万件のエラーが出ている、ということです。
Googleには1万3000以上のPrjが存在するそうなので、単純計算で、 1Prjあたり100件のエラーが毎日出ている ことになります。
テストをいかにして効率的に回すか
膨大な量のテストを効率よく実施するためには自動化は不可欠。
所要時間、前提条件などテスト実施に関わる様々な条件を考慮しながら、どうやってテストを回すのが効率良いか、Googleのエンジニアたちは常に試行錯誤しているそうです。
その取り組みがいくつか紹介されました。（興味ある方はAdvances in Continuous Integration Testing @ GoogleのP4〜 あたりを参照ください。ただし All English です。）
Flaky テスト（フレーキーテスト）を捌く
※Advances in Continuous Integration Testing @ GoogleのP34〜 あたりから参照
Flaky とは「不安定な」という意味だそうで（Google翻訳でflakyを翻訳かけても flaky としか出てこないwwと会場の人に言われてましたwww）、同じテストを実行しても成功したりしなかったりする不安定なテストのことを指しています。
時に 
、別な時は 
となる、というのは結果が定まらず困りものです。
でもあの膨大な量のテストを実行しているのなら、flaky test が存在するのもわかります。
様々な分析や取り組みの結果、 flakyなテストをどう捌くか がポイントになるという結論に至ったそう。
現在もflaky test の分析しては試す、の繰り返しをしているそうです。
Flaky なテストかどうかの判断、flaky なテストだった場合その結果を信じるかどうか、をゆくゆくは機械学習に任せられるようにしたい、と話されていました。
Flaky test についてミッコさんがGTAC2016で話した動画
※1h以上あるのでお時間＆興味ある方向け
会場の質疑応答のやりとり
-
本当に100%テスト自動化してるのか？！
-
そう。ただし、翻訳だけはマニュアル。あれは難しい。:たしかに: :わかる:
-
コードカバレッジによってテストカバレッジが変わるか？
-
と思うよ。お互いcommit積んで良い方向に持っていく文化だから。
-
Flaky ってどういう意味？
-
（前述の通り）
-
新サービス提供開始時も全く手動テストしないの？
-
しない。Googleでは自動運転とかクリティカルなサービスが無いからその必要はない。
UX（ユーザーエクスペリエンス）が絡むテストも可能な限り自動テスト、昔はUXラボに来てもらってテストしてたが今は可能な限りやらないようにしてる。 -
テスターによってブレがある件はどのように検知してる？機械学習？
-
そう、機械学習データベースに溜め込まれてる。ブレが多いテスターに直接どうこう言わないけどデータ分析の判断材料としては使っている。
:マジか: -
テスト計画とかテストマネジメントはどうやってるの？
-
テスト計画もテストレビューもチームごと。最終OKはお偉方が出す、とかいうフローではない。
-
テストはサブミットの前にやってるの？
-
一旦サブミットの前にテスト実行して、サブミットした後にもう一度テストする。そうすることで手戻り最小限にしている。 :なるほど:
-
どんな場面でAIを利用している？
-
スケジューリング、テストの取捨選択など、より効率と意義があるテスト実行を目的として利用している。
-
AI自体のテストはしてる？
-
してない。ていうかできないよ！ :へぇ:
-
人数と品質の相関関係ってあると思う？
-
さっきも説明したが、1つのファイルをいじるのは2人までならむしろプラスに働くが、3人以上で編集し始めると一気に品質が下がり間違いが増えることがわかってる。みんな気をつけて。 :なるほど:
個人的な感想
今やってるテストを自動化しないと！と強く思わされた衝撃的セッションでした。
このセッションをしょっぱなに持ってくる時点で今回のJaSSTに対する期待が高くなりました。
自動化するテストコードばしばし書かねばならない！早く勉強しなきゃ！と思いました。
Web.JaSST~web系QAがみんなのお悩みに全力で提案を返す会
web系QA（筆者の仕事に類似）の方々による座談会。
事前にテーマを募集し、支持数（いいね数）が多いテーマをパネラーたちがあれこれ話す形式。
- 登壇者
- モデレータ：LINE鈴木さん
- Aチーム：サイバード柿崎さん、ユニファ鶴岡さん
- Bチーム：アカツキ山本くにおさん、メルカリ米山さん
- Cチーム：mixi山本健さん、mixi川崎さん
- Dチーム：ヒューマンクレスト浅黄さん、ヒューマンクレスト山口さん
パネルディスカッション
テスト観点を網羅的に洗い出す工夫（仕様書以外からの観点とかあれば）
- ロジカルシンキング＋テンプレート(A)
- 木を見て森を見ずになってる時点ですでにおかしい(A)
- 事前にテンプレを作っておいてそれを常に用いるようにしてる(A)
- 仕様に載らないこと（業務知識）や本当にやりたいことを汲み取る(C)
- お金を出す人が欲しがっているものを考える(C)
- マスターテストプランを準備する(B)
- サービスとして重要かどうかで判断する(B)
- 変更履歴、並行実施しているものの状況をちゃんと追っかける＆考慮する(B)
- レビューとコミュニケーション(D)
バグ分析のメトリクスはどのようにやってるか
- 障害がどの工程で発生してるか、どのように解決してるかをwatch。出た障害は全体で共有、ミスの詳細をログとして残す(A)
- 件数、重要度、機能、人、クラッシュ率、修正までのリードタイム(B)
- BTS - JIRA(B)
- crash率を重要視している
- 宵越しのバグは忘れる(C)
- 修正した後に出たバグのメトリクスを出す(C)
給料が安い、QAの適正な給与額、給料をどうやってあげるか
- 適正価格はない、事業が儲かっていればいくらでももらえばいい、事業に貢献すれば自ずとリターンあるはず(A)
- 関われる範囲を広くすることでQAの価値をあげようとしている(A)
- 上長の期待に応じて給与はきまるもの、何が必要か上に聞く(B)
- 上がらないなら転職(B)
- 勉強して会社にアピール(D)
- カンファレンスで発表するなどは評価に値する(D)
- Prjの困りごとを少しずつ解決してくことでQAの存在価値をアピール(C)
- テストの業務範囲を超えたところもやる(C)
QAメンバの評価方法、チーム/個人の目標設定
- 業務とスキル(B)
- スキルセットと評価フレームワークを整備中（できたら発表する）
- コミットメントの達成度（どう評価するかを事前に話し合う）(C)
- 基本業務に関係あることのみ
- 1on1でコミットメント合意、3年後の目標設定を共有
- 業務に関係ない個人目標でも会社が理解を示し応援する体制づくりをする
プログラミングもできるQAの中途採用に苦戦、転職ニーズはどの辺か
- QAとして探すといないからエンジニアを口説いてQAにする(C)
- 社内でスキルチェンジもある
- 社内の開発者をコンバート(B)
- テストオートメーションの仕組みがないのでそれを１から作る人材に会ってみるが、立ち上げたいより学びたい人が多く採用ミスマッチ (A)
- QAの権限を明らかにする必要がある(D)
- 問題解決をして行く姿勢、そういう素養がある人が向いてると思う(D)
品質保証チームの仕事範囲はどこまでがいいか、実際どこまでやってるか
- 技術の空白を埋める(A)
- 会社が達成したい目標に対してのタスクのうち、だれも拾わないならQAが拾えばいい(A)
- ビジネスサイドに寄っている(A)
- どこまでも、自分で決めていいと思う(C)
- 要件／仕様まとめ係(C)
- スコープはサービス全体、穴を埋める(B)
テスト管理ツール、その使い方
- エクセルで済むならそれでOKかと
必要ならマージしたソースの解析は使った方が良いと思う(C) - Webで自動化ができてるならTestLinkで管理、マニュアルテストはgoogledocsが最強(B)
- テストケースを管理するならエクセルでいいのかと(D)
- 管理対象が進捗、バグ、スケジュールとかだとエクセルとは限らなくなってくると思う(D)
探索的テストの終了条件
- 最初に決めた終了条件が終了条件になるはず
「探索的テスト」と呼んでいるものが探索的テストではない可能性がある(B) - 何がしたいのかをあらかじめ決めておく(C)
- プロダクトの要件を満たせたら終了(A)
- テスト実施した結果顧客価値の想像、保持ができるのであれば、手段名称がどうであれ要件を満たせたことになるからOKかと(A)
- 観点と時間をあらかじめ決める(D)
- 観点を変えることは大切（広げる、掘り下げる、重箱の隅を突く）(D)
個人的な感想
昨年本セッションのパネラーたち全員とお会いする機会がありました。当時のLTでは彼らの話していることがなんのことやらさっぱりわからなかったのですが、今回は共感もできるし、意見も言えるし、同じような経験もしてきた、等理解できるところが格段に増えていることがわかったのがなによりも嬉しかったです。
弊社の開発規模ではこんな風にやっている、という話を近いうちに発表できたらいいなと思いました。
サイボウズQAスクラム奮闘記
Agile Japan とJaSST のコラボ企画。
昨年スクラムを導入したばかりというサイボウズのQAチームの事例紹介に加えて、事例の中に出て来る課題を近くの席の人とグループになって解決策を考え発表する、という一部参加型のセッションだった。
- 発表資料：「開発がスクラム導入するんだって！試験どーしよ！？」 -サイボウズQAスクラム奮闘記-
- メモ：していたつもりだができてなかった
という状況だが、一生懸命思い出して書いてみる。
Agile Japan とのコラボ企画
Agile Japan というイベントが毎年開催されているらしい。昨年度の実行委員長は昔JaSSTの実行委員もされていたそうで、その縁で今回のコラボが実現。アジャイル開発をしている企業は増えてきたが、QAにどう影響を与えるのかを事例を用いて紹介することで、アジャイルについての理解を深めてほしい、というのが主目的の様子。
Agile Japan 実行委員の方が今日のこの日のために作ったという新聞
事例1：2万社のユーザーを支える共通基盤チームでスクラムを導入
登壇者：サイボウズ岡崎さん
導入のきっかけ
サイボウズの企業理念に沿ってスクラム開発を導入する、という話になり、リリースもそれに合わせて回すようになることから、QAもスクラムに乗ることになった。
サイボウズのスクラム概要
- 1スプリント3週間
- 開発6名
- QA4名（日本1名、海外3名）
事例2：複数拠点での大規模スクラムへの挑戦
登壇者：サイボウズ矢引さん
スクラムの規模
- Nexus Framework を採用
- 日本、中国、ベトナムの３拠点
- 日本に Nexus Integration Team を設置
- スクラム開発の元締め
- 各チームへアサインするタスクの選定（開発自体は行わない）
- スクラムのスクラム、ふりかえりのふりかえり、などを担当
- 1スプリント2週間
段階的な導入
- はじめに日本の開発チームにスクラムを導入、3スプリント回す。
- 第4スプリントから徐々に中国、ベトナムの拠点へ展開。（現地に飛び、スクラム開発の説明を実施）
グループワーク
- 課題：リリース前にQAにくるしわ寄せをどう解消するか
- スクラム導入直後の運用
- 開発とQAは並行稼働しない（開発が終わったらQA、QA通ったらリリース）
- 海外QAの中でクロスチェックをした後日本QAレビューに出す、という二段構え
- 日本QAが一人でレビュー
近くの席の人8人とグループを作って意見を出し合った。（後で会場全体に発表した）
- 開発が終わる前からテスト仕様作ればいい
- 開発もテスト仕様書のレビューをすればいい
- クロスチェックは重要だが2段構えにしなくてもいいのでは？
個人的な感想
他社の話を聞くことで、弊社のスクラム開発は結構うまく行っていて、スクラムの定義や目的に沿っていて、確かな効果を上げているんだなー、と思うことができました。
また自分は特に本を読んだりしていないのですが、スクラム開発のことを想像以上に理解していて、たくさん意見を出せたのがびっくりでした。
懇親会
ミッコさんも含め、おそらく総勢200名近くいたのではないかという大勢の方が参加していました。
結構盛り上がっていました。
登壇者など各々話したい方と話したり名刺交換したりしていました。
久々に会った方々に挨拶をしていたら、 
にありつけなかったのが個人的には心残りです。
といえば、
AgileJapan実行委員の方に弊社の スプリントSUSHI について話したらすごくいい！と絶賛されました。
（スプリントSUSHIは、毎スプリントの終わりに開催している慰労会のことです。
1スプリント2wで回している弊社では隔週で チャンスがあります 
興味ある方、sushi チャンス狙って遊びにきてください！）
1日目の感想
お腹いっぱい。気づきと発見と焦りと再認識がいっぱいでした。