aretan.jp

Advances in Continuous Integration Testing at Google John Micco¶

150,000,000回/日の自動テストを実施
マニュアルQAは一切していない
トイレにテストのテクニックを貼っている
QAの部門を置かずにすんでいる理由は自動化テストがあるから
変更に影響する部分のテストだけをうまく実施している
テストの合否はDatabaseに２年間保存して分析している

Flaky Tests
PASSからFailになるのは84%がFlaky Testによるもの
C++よりJAVAの方がFailが起きにくいGoはもっとおきにくい
ある一定のFlaky Testは許容しなければならない
Flaky Testをトラッキングできるようにする

カバレッジは測っていないチームもある
Flakyとは不安定さを指す、一貫性のない人を指す言葉

ペアプロにするとFlaky Testが減る

Google Home等のサービスでもマニュアルテストを一切していない
人が死ぬようなサービスがないので、自動化テストのみで済んでる

UXは1%ユーザにA/Bテストするなどして検証している
テストを壊しやすい人は機械学習でテストが増やされる
Beselというビルドシステムを使っている。Facebookも。

唯一手動でテストしているのは翻訳のチェックのみ
レアなものでも自動化テストをする文化があってコスパは気にしてない

2006年からテスト文化を作ったので、今そういう負債はない
2006年より前に書かれたコードというのはほぼ残ってないから
SETIによってそこの変革は円滑に行われた

テストを中央で管理するような機能はない、個々のチームで策定する

機械学習そのもののテストをどのようにするのか、は大きな問題になる

3人以上が1つのファイルに取り組んでいるときに壊れやすい
1人より2人の方がいいけど、3人より2人の方がいい

レビュワーはコードに一番近い方、ほとんどがテックリードがする
トライクオーターというFWで静的解析してレビューを自動化している
静的解析は過剰なレポートを提供してくる事がある
エンジニアがNot usefulというボタンを押して、よく押されたら消される

テストプロセス改善モデル 概要と特徴の紹介¶

テストプロセス改善技術ガイドというものを作っている（１８夏までに発行予定）
JSTQB TMやSQuBOKガイドに記載されている
TPI TPI NEXT TMMi ISO33063 CTP STEPなどのモデルがある
TMMi 段階モデル
ISO33063 連続モデル
TPI NEXT 段階＆連続モデル

能力水準 不完全な 定義された 管理された 確立された 予測可能な 革新的な
能力軸 33020 プロセス測定の枠組み
プロセス軸 29119-2 ソフトウェアプロセス

改善対象が自組織にマッチしているのかというのもモデルを選ぶ基準になる
テスト計画テスト設計テスト環境テスト測定はどのモデルでも共通している

テストプロセスをなぜ改善するのか
プロセス改善の前提として、システムの品質がソフトウェア開発に使用しているプロセスの品質によって大きく影響を受ける (TM)
要求とテストに関する７つの神話
要求定義へのテスト専門家の三角についての実践的な施策提案

品質の課題についてパッチで対策するよりプロセス改善モデルを適用するべき
だから、まずはアセスメントをして改善計画を立て実行していく

要求目的ゴールを明確にして関係者と認識を合わせておく

ISO29119を組織標準に的確に取り組む IVIA ZEROX¶

IT検証技術者試験をやっているのでそのシラバスとかを作っている
IT検証標準工法ガイドを改定するにあたってUSDMを活用すると上手く行った
ISO9000やCMMIなどのマネジメントシステムにも適応できることがわかった
各組織の標準と国際標準規格ではフレームの切り口が違うことが多い
国際標準規格だからといって十全なフレームワークとは言えない
ISO29119とTMMiとTPI NEXTを比べてもやっぱり切り口が違う
ISO29119を要求仕様書に落として、IVIA1.1からIVIA2.0の派生開発をする
USDMとはUniversal Specification Describing Manner
要求(+理由)と仕様をセットにしたデータ構造を持つ
要求は振る舞いを表現し目的語と動詞のセットで記述する
マニュアルに理由がなければ使えるマニュアルにはならない
その要求事項の文章を崩さないように使う事で要求を満たす
USDM形式でルールを作ることによって、カバレッジが測る事ができる