ロンリーQAによるJaSST '18 Tokyo レポート（2日目）

#はじめに
ソフトウェアテストシンポジウム 2018 東京（JaSST Tokyo） はソフトウェアテストのカンファレンスとしては国内最大規模で、最新動向の紹介と情報共有を目的として開催されています。
２日間まるまる参加してきたのでその様子をざっくりレポートしてみました。
Web系のQAとして働き始めて約1年。
まだまだ駆け出し故の浅掘り、薄い考察がキラリと光る内容になっていますが、QAってなにやってるの？という方にもわかるような記述を心がけてみました。
なんとなくの雰囲気だけでも伝われば嬉しいです。
タイムテーブルのとおり、同時並行で色々なセッションが開催されてるため、本稿は筆者が参加したセッションのみの報告となります。ご了承ください。
そして若干の（いや、たくさんの）誤解釈があると思うのでそこは玄人の方々にフォローしていただけると大変嬉しいです。

---

ご興味ある方は1日目のレポートも是非

---

テストマネージャの決断

モデレータ：町田さん（NTTデータ）
パネラー：柿崎さん（サイバード）web系
　　　　　　湯本さん（ASTER）エンタープライズ系
　　　　　　長谷川さん（ベリサーブ）組み込み系

ケースについてパネラーたちが意見を言い合う形式

ケース１：計画を超える量バグが見つかった場合

出た意見

• 全般的にweb系とそうでない系統で危機感というか意見が別れる

• web系ゆるめ（出してやばかったらすぐ直せばいい）

• 組み込み系はそうはいかない

• 上流工程からQAが入ると防げることがたくさんある

• QAはデリバリーの時期とかは言ってはいけない

• このテストでどんなことが担保できるか、このテストにかかるコスト、このテストにかかる時間が言っていいこと

• バグの重要度によって直す直さないの判断をするが、その重要度はどのようにつけるか

• 開発側に修正の説得をするときにどのような説明して理解してもらうか

• 直す直さないが職能で意見がちがうのは、チームビルディングができてない。顧客価値を毀損してるかどうか、が判断材料なはず。

• ここを直すと全部直さなければならない、というのは現場の都合であって、できればここのところを事前に合意してから開発できた方が良い

• web系は↑こういうことができるが、旧態依然としてる会社だと難しい。:わかる:

ケース２：不十分なテストベース+複雑な開発体制

前提条件

• 統合テスト以降のテストマネージャ
• 別の開発会社が基本設計から単体テストまでを担当
• 基本設計書がない
• 記述内容がばらばら

出た意見

• まずこの前提条件がおかしい。このプロジェクトを正常な状態にするためのタスクフォースが必要。
• 開発標準があるケースが多いが、実現可能性が低いもの多い。末端まで行き渡っていないケース多い。
• Web系でもズタズタになった組織があったが、チームをなるべく細分化してそれぞれに裁量をもたせてすすめたという事例を聞いた。
• テストできない状況と言いたいところだがそうもいかないので交通整理をやっていくしかない
• QAはやはりprjの限りなく最初から入るべき
• Prj始まる時点でどのようにテストしていくかの方針を出すべき
• テストマネージャはメンバができる範囲を理解してそれに見合ったプランを出す
• そのプランをもっていってPrjと合意するしかない
• 安請け合いをしたらダメ

ケース３：リリース直前の仕様変更

前提条件

• 3ヶ月後にリリース控えてるがライバルが１ヶ月後にリリースの情報入る
• 仕様変更しないとライバルに負ける
• 既存部分にも手をいれねばならない→大規模な回帰テストが必要

出た意見

• 組み込み）何かとトレードオフにしなければならないことを話し、prjと合意とる

• web）ライバルより早くリリースできる計画をたてる

• 仕様変更どうこうじゃない。

• いちはやく市場に届けることの方が顧客価値提供といういみで重要

• いち早く市場のパイを取りに行かないとビジネス自体が死ぬ

• アーリーアダプターを捕まえる

• アーリーアダプターはバグを見つけて報告してくれる

• これをいち早く直すというレスポンスの速さでファンを増やしていく

• テストのスタイルとか網羅率とかにこだわらないでサービスを育てていく意識で取り組むと良いのではないか。

個人的な感想

:なるほど:
前職（組み込み）に比べて今はやりたいことができる環境にあるのだと改めて実感しました。
アーリーアダプターを捕まえる件は大賛成だと思いました。

QAからDevOpsへの挑戦（スポンサーセッション）

SHIFT 山下さん、脇坂さん

QAとは 顧客価値最大化させるための全組織的な改善活動

• agileとの違い：aglieはQAまでの開発だがDevOpsは顧客に届くところも含んでいる
• agiletesting：QAとしてdevとopsの橋渡し（QAが要）

事例1

• プロジェクトの状況

• BtoCのプロダクト

• β版運用中の過渡期

• スクラム採用

• 1wのスプリント

• 自動テストがすごい時間かかっていた（自動テストの内容を担当者以外把握してなかった）

• 課題解決のための目標設定

• 60分かかる自動テストを10分に短縮させる

• やりかた

• 自動テストの並列化

• 自動テストを削減

• 統合テストでテストとパターンの網羅を目指していたのをやめた

• 重複してるテストコードの整理

• テストのブラックボックス化を解消

• 結果
  8分に短縮でき、2wごとにリリースできるようになった

事例2

• プロジェクトの状況

• 半分以上オフショアだが現地にマネージャーいる（対等）

• 環境がへぼい（OSなど全部期限切れ）

• 環境差異による障害（dev環境とStagingとProduction でOSがすべて違う）

• 目標設定

• 自動テストでQCDバランスをとる施策

• やりかた

• 一人から改善の流れを作る

• 本番障害の分析

品質改善ではなく組織の課題として捉える、解決へ進める

愚痴を聞くことから始める :ほほぅ:
↓
情報があつまったらタスクを並べてみる
↓
違和感を感じる部分を深掘りする
↓
改善課題が導きだせる
↓
Issue化する

立場にあった効果を示して提案する

• 決裁者：ビジネスに貢献できるか、多部署に説明がつくか
• 上司：報告できる成果（メトリクス）か、実施内容をイメージできるか
• 同僚：楽になるか、楽しくなるか、スキルアップできるか、など

:なるほど:

説得に最終的に必要なのは、 改善への強い思いとビジョン
繰り返し同じことを言って共感をもってもらう活動を惜しみなくやる

QAの枠を飛び出すことでQAの意味が出てくる

本番障害とフローが解決のヒント
やりきった後に共感を促すことで初速を与える

質疑応答

• 書きやすさでテストコードを変えてしまってよいと考えているか？
  →よいとおもう

• 重複する自動テストを共通化すると報告しづらい、説明しにくい
  →コード効率を下げただけで、テスト件数としては元の数（2）をカウントする

個人的な感想

SHIFTさんはテスト専門会社。
テスト業務を請け負っているゆえ、テスト工程に来た時に大爆発しているPrjに出会うのは日常茶飯事だが、その状況から「QAの枠を超えて提言、提案していく」という姿勢が言葉として強いメッセージになっていてとても良かったです。
自分もQAの枠を超えなければな、と思わされたセッションでした。

招待講演：ソフトウェアテストの変遷

登壇者：柴田芳樹さん
富士ゼロックス、リコーでデジタル複合機のコントローラソフトウェア開発に長年従事
資料：予稿集のP132〜
※たくさんの本から引用しての説明が秀逸だったのと、それぞれの本の内容も良さそうなので是非引用元の本を読んでみることをオススメします！（私も読みます！）

テストファースト、テスト駆動開発

〜90s　目視確認が主流

「コンソールに出力されるテスト結果を私がチェックしなければならない」
↑これが「苦痛」であるということに世の中の人々が気がついたのは2000年前後だそうです。
私の前職の話をしてしまうと、あの人たちはまだ気がついてないよ？！そしてこの会場にいる人の一部はきっとそういう気づいてない組織構造の職場で今も働いているよ！と何だかツイッターのタイムラインを覗きたい衝動に駆られましたがメモとるのに精一杯で追えませんでした。

テストファースト開発

テスト対象のコードより先にテストコードを書くべき

• コード書いて、テスト書いて、テスト実行する、だとタイムラグが起きてチェックできてほしいことが漏れる可能性があるから
• 単体テスト作成、からのコード実装、からのテスト実行、にして、 今書いたコードを今すぐテストできるようにすべき

:なるほど:

手でやったテストは資産にならない、自動化されたテストは資産になる

:おっしゃる通り:

00s~ テスト駆動開発による自動化されたテストが開発の基本

デグレの早期検出、技術的負債の解消に一役買う
ある日一斉にがっちゃんこするのではなく、継続的にインテグレーションやる（CI）
ビッグバンインテグレーションを避けて常に動作するソフトウェアを保つ

10s~ CIからCDが登場

CIがあったからといってかならずしも成功するとは限らない
ビルド失敗を放置（ローカルでビルドできることを確認しないままコミットしちゃうとか）したり、静的解析ツールの結果に関心がない（警告も結構進化してるからcatchup必要）とCIをやっても意味がない

柴田さんの職歴

HOLENET開発＠大学

• ネットワークプロトコルを理解するため、大学生を実験台にして色々やるため
• 当時の環境
• バージョン管理システムない
• デバッグはオシロのみ
• ROMからRAMにダウンロードしてデバッグする、という工夫をした（これくらいしか工夫できなかった）

ワークステーション開発@富士ゼロックス

• 隣のパソコンからリモートデバッグできることに感動した
• 6060ワークステーションを開発、ethernetドライバらへんを担当

デジタル複合機コントローラソフトウェア開発

• 環境

• Solaris2.3、C++、割り込み処理などもあり結構複雑

• マルチスレッドプログラミング

• リリースで起きる問題
  バージョン管理は社内ツール使ってた
  2w毎にビッグバンインテグレーション（必ず失敗）、そしてよくデッドロックする
  リリースできる状態になるまで叩く、そのほかの作業しちゃダメというルール
  ↓
  月曜リリースのはずが水曜リリースになってしまう

• メモリリークとメモリ破壊
  purify というメモリの状態を教えてくれるツールを導入して監視してたがこれが超重くて使い物にならなかった
  メモリ管理機構をどうするか考えなければならなくなった
  ↓
  C++用のメモリ管理機構を作った
  マルチスレッドプログラミングの難しさを痛感した

もう一度複合機のコントローラソフトウェア開発

00sごろ、複合機のそれぞれのボードを１つに集約する動きがあり、また召集された

• 環境
• Linux, C++
• 完全なテスト駆動開発、自動テスト

やり方は画期的だったが感動とかがなくてつまらなかった

転職後、また複合機のコントローラソフト開発

リコーに転職してLinuxとGoでまた複合機のコントローラソフト開発
また、マルチスレッドプログラミングの難しさを痛感

学んだこと

マルチスレッドプログラミングでの重要な４要件

• 動かす前に必ずきちんとしたレビューをする（経験豊富で知識もちゃんとある人によるレビュー）
• 自動テストによる自動テスト
• 様々な環境での長期間ランニングテスト
• ハングしたらその場できちんと記録、分析する（ あとでやる、は改善に繋がらない ）

:大納得！:

ここで今日イチの名言が出ました

CIは強みではなく、やらないことが弱み

QAとは品質を製品に作り込むこと
だから開発プロセスの最後ではなく、プロセス全体を通して深く関与しなければならない

全く以ってその通りでございます。の一言につきました。
複合機のソフトウェア開発というバリバリの組み込みの世界（私の前職と同じ）で、ここまで考えて開発されてる方がいたこと、10年前にこのことを理解して実践されていたということにびっくりでした。

よくある問題

• テスト設計がうまくできない（研修受けてない、テストケースが漏れる、情報不足で網羅できない、など）

• API設計がうまくできない→テストファースト開発がうまくできない、
  防御的プログラミングができていない（関数の呼出順序が実はあるのに、順番を間違えて呼び出したらどうなるか、が仕様に書かれていないからコードにもない）

• コードカバレッジを品質基準にしている
  :たしかにおかしい:

作業はコンピュータに、人は創造的な活動を

:その通り:

質疑応答

• 設計力をあげるにはちゃんとしたレビューを受ける必要がある、と仰っていたがちゃんとしたレビューができる人がそもそもいない問題がある

• 教育ありき。教育と現場での実践がペアにすべき、それを繰り返さないとスキルにならない。
  最初は柴田さんがレビュー指摘してばかりだったが、これを続けていくと周りが指摘するようになるそう。

• テスト環境と実際の環境に差があるときはどう担保するか。

• 実機に限りがあったため、エミュレータ開発の人たちだけが実機を毎日触れるという状況にした。エミュレータと動きが違うところがあったらエミュレータでも起こるように作り変えるようにしてもらい、エミュレータの精度を上げた。
  他のレイヤの開発の人は実機がなくても作れる／動くことを担保させ、エミュレータや実機がないことのせいにしないようにすることが大切。

個人的な感想

同じような意見のツイートを見かけましたが、昨日はミッコさんに、今日は柴田さんに度肝を抜かれました。
地道なことを継続的にやるというのは華がないですがとても重要で、そこから気づきや学びが生まれ、さらにその中からイノベーションが出てくるのだと思いました。
ということで地道なことを継続してやる、を実践していこうと思いました。

クロージングセッション：アジャイル・自動化時代のテスト現場のリアル

お題についてパネラーの皆さんがあれこれ話すパネルディスカッション形式。
開発規模のコンテキストを合わせるため、自己紹介時にデプロイ頻度を言おう！ということになった。斬新。

• 登壇者
  ※（カッコ内）はデプロイ頻度

• モデレータ：楽天荻野さん（1日数回）

• パネラー：サイボウズ天野さん（2wに1回）

• パネラー：ヤフー山口さん（2w~1mに1回）

• パネラー：クックパッド松尾さん（1日30回程度、アプリは1w~1mに1回）

• パネラー：Google JohnMiccoさん（1日2万リリース、うち本番にpushされるのは5%。ただしチームによってばらつきあり）

昨日のMiccoさんの話を受けて

ミッコさんの話と会場とで認識乖離があった
Googleは全部自動化できている、その上でレグレッションテストをどう削減してくか、の話

各社の自動テストの状況

• サイボウズだと1700件くらいのテストケースが20分くらいかけて実施される

• jenkins

• 不安定な部分をエンジニアがみつけて直す

• Googleがflakyテストを売ってくれるのなら使いたい

• ヤフーはさほどテストはまだない

• 確認のためには使いたいがflaky test 全面採用はないかな

肥大化するテストをどう削減していくか

• 大規模なら必要な分だけのテストする、という取捨選択が必要と思う

• アルゴリズム

• 間引くことでバグを見逃してるのでは？

• →確かにリスクはあるがgoogleはそうせざるを得なかった状況にある。品質を保ちながらコストを下げる必要を常に迫られている。

• このテストを実行する、という判断を人間が介在してるか？将来的にAIに判断させることを視野に入れてる？

• →googleのような規模だと人間が介在するのはほぼ不可能。なので機械学習に判断させているが間違いもあるのも事実。その間違いをどんどんフィードバックして育てていく。

Googleのテスト定義と計測

• 書いたテストを壊さないようにする価値観を共有されてる
• CIの結果を記録してる
• カバレッジを意識するかどうかはチームによって異なる
• 2006年にyoutube買収、同じ頃自動化やろうと機運があった（全てのコードにテストをいれようという思いがあった）
• youtubeはテストコード0から3年で全自動化達成、インクリメンタルにすすめられた
• 2011年にgoogleに入ったがその時点でマニュアルテストはほとんどなかった記憶
• 自動化やろうという話はどこから湧く？
• 政府の規制でコードレビューが義務付けられたのでシステムを作った :マジか:

印象に残った発言その１

QAチームという組織はGoogleにはない
開発チーム毎に1人ないしは複数のQAがいる感じ（の方がいいと思う）

これはまさに、弊社のQAのあり方は良い！というご意見！！！　

印象に残った発言その２

QAチームを数年前にやめた。
開発チームにテストの責務を与えたから。
職務責任としてのQAはいないが、テストという行為はもちろんある。
（QAチームが無いことの）悪影響はとくにない

この話をもっと前に知っていたらこの間LT会に行った時に詳しく聞けたのに！！

不安定なテストをエンジニアリングでどう解決していくか

自動化テストの命中率みたいな話と、テストケースやテストデータをメンテナンスする必要がある話

• クックパッド：マイクロサービス化して確実に確認できるようにする

• dependency injection

• Miccoさんから

• コードはもちろんテストそのものがflakyである、ということを開発者に伝える必要がある

• テストそのものが失敗なのか、インフラがダメだったのかの切り分けも必要。それを確実に情報提供する必要がある

• インフラの問題でテストが失敗することはよくあるがどうやって取り除くのがいいか？

• →インフラそのものの不具合を認識できるように準備する必要がある

• →テストが原因なのか別の原因なのかの切り分けを素早くし、通知する

• テストの自動化が生産性をあげるということをCEOに説得する活動を続けていきたい

サービスをいち早く提供するためにはデプロイ回数を増やす必要がある

• 何をすればよくなるのか、を考えた結果がQAのゲーティングをなくすことだった
• サービスを提供するために自動化がよいならやればいいし、今やるべきことをやればいいと思う
• テストをどう効率よく確実なモノにできるかが鍵だと思っている
• Googleの regression test selection は良いケーススタディ
• Cookpad デプロイリードタイムが20分、これはおそらく世界一では？

個人的な感想

弊社にQAは一人しかおらず、JaSSTのような場にいくと「まだ1人しかいないの？」「相変わらずの一人旅です、、」という会話が多いのですが、このセッションで弊社にはQAが1人しかいないことに逆に自信を持つことができたのと、1人しかいないからやれること、やりたいこと、しなければならないことが明確になりました。

2日間参加して

昨年とは比べ物にならないくらい大収穫の2日間でした。
モチベーションしっかり得られました。課題も見えました。やることも見えました。
今年これからQA活動頑張って、来年登壇するくらいの成果を出せるようがんばります！
JaSST実行委員の皆さん、貴重な２日間をありがとうございました。