JaSST'18 Tokyo参加レポート　1日目

ソフトウェアテスト

今年もJaSST'18 Tokyoに参加してきたのでレポートします。

「Advances in Continuous Integration Testing at Google」

John Micco（Google）

Googleのテスト
  • 1日、1億5000万件のテスト実行 （420万件のテストを1日35回繰り返す）
  • マニュアルテストはない。100%自動化している
  • 99%のテストはPASSSする
  • コードをコミットするときは、当然のごとくテストコードも一緒
テストの選び方
  • 依存性関係を持ったテスト
  • コードの依存性グラフを作っている
  • テストは450万件あるが、依存関係グラフによって実行対象を絞れる→影響のないところはテストしない、割り切り
テスト結果への対応
  • テストの合否はすべて記録（2年分）
  • ひたすら自動テストを実行
  • PASSからFAILに移行した場合 →スケジューリングをさかのぼってどこから変わっ・たのかすぐにチェックする。
  • 結果のパターンが見えてくる
  • 結果は何種類かに分類することで、開発者とインフラチームが責任を持つべき結果を分けている
Flakyなテスト
  • 同じテストを実行する中で、結果が成功から失敗（またはその逆）に状態が切り替わるもの。不安定なテスト。
  • テスト結果を蓄積して、Flakyの原因が何なのか分析中。問題がない場合もある
Googleの文化
  • テストを自動化する価値→イテレーションの高速化。手動はない。100%自動化。人が死ぬようなシステムないからね！という割り切り。
  • コードレビュー時に同時にテストコードをサブミットしてもらうようにしている
感想

愚直な正論の積み重ね。日本の周回遅れを感じました。
あまりに印象が強すぎて、思わず当日券買って次の日のチュートリアルに参加しました。
基調講演聞いて、がぜんチュートリアルに興味が出たので、チュートリアルも受講してきました。

「はじめてみようテストプロセス改善〜テストプロセス改善モデルを使った改善活動の勘所〜」

TPI NEXT、TMMi、ISO/IEC 33063といった各種改善モデルの紹介。

改善の勘所

1.アセスメント
　やってみる
　認識合わせた
　振り返り

2.計画
　関係者の要求を確認
　関係者との調整
　バッファを持った計画

3.実行
　状況確認
　改善アクション
　更なる改善

重要だと思ったポイント

改善は大変。何より大事なのは１人で悩まないこと。いろんな人と話す。困ったら誰かに話す。

「テスト会社のテストリード達はどのようにテストを成功に導いているのか？」

いいこと色々いってたのですが、自分的にはツイートした内容がクリティカルだったので、そこについて。

とても良い例えだと思いました。そして、最近自分はこのように行動できてるかな？と自問するきっかけになりました。一応機能の目的とか、どういうユースケースを想定してるのか前よりつっこんで聞くようにしてますが、もうちょっと開発者と一緒に考えられるようになりたい。

「開発がスクラム導入するんだって！試験どーしよ！？」-サイボウズQAスクラム奮闘記-」

クラウドサービスcybozu.comの管理者機能開発の事例

開発：QA：PO=5:5:1

＜スクラム導入前の問題＞
　バグの検出が遅い
　要件があいまいなまま開発がスタート
　開発とQAの隔たり感

　→スクラム研修受ける
　　やってみよう
　　
＜開始までの準備＞
(1)「カンバン仕事術」輪講

(2)もろもろ定義
　完了の定義
　テストに関することをどこまで含めるか定義
　開発チームの実力に合わせることが大事
　→含めなかったこと
　　・テスト実行を完了する
　　・脆弱性検証
　　
(3)アジャイル第一人者の講演を聞く

＜導入後のプロセス＞

  • スプリント2週間
  • リリース単位は6スプリント＋リリーススプリント

＜よくなったこと＞
(1)バグの早期検出
　類似バグの量産を防げる
(2)要件の明確化
(3)開発チームの一体感
　QAは開発のリクエストにこたえられるようになった
　開発はQAのことをより気に掛けてくれるようになった
　
＜実際＞
スクラムは問題発見のフレームワーク。

Garoonの開発チームの事例

＜開発のプロセス＞
　スプリントは3週間
　リリースサイクルは3か月
　
＜導入前＞
全員スクラム未経験、拠点は日本、中国、ベトナム三箇所
→とりあえず日本のみ
　スクラムチームに日本QAが足りない
　　当時PG7名、QA2名
　　→1名SMやるため実質QA1名
　
→スクラムの基本にのっとるのはあきらめた
　スプリント内では実装完了、次のスプリントでテスト設計・実施
　テスト設計、実施は海外拠点
★結論：失敗した失敗した失敗した

主な原因
　価値分割できず、バックログアイテムが巨大化
　仕掛中タスクが大量発生
　職能の壁が発生

課題はあれど、海外拠点でもやることに

開発と比べると、QAの方が変化が大きいのでは

＜解決＞
チームの有志で勉強：実践アジャイルテスティング
　ABD（Active Book Dialogue)

職能間の障壁を下げる
　できる作業は職能に関係なく着手

感想

★結論のところで、スクラム導入当初のバーンダウンチャートをさらす勇気が素晴らしいと思いました。下がるはずのバーンダウンが炎上している！って紛れもなく失敗で外部に出したくないものだと思うんですが、出してくださって勇気づけられます。失敗しても改善して前に進んでいるチームがいるって事実はちょっとほっとしますね。ありがとうございます。