JaSST18 Tokyo 招待講演　柴田芳樹氏による「私が経験したソフトウェアテストの変遷」のレポです。

一部SNS公開NGのところなどもあったので、内容メモ見るだけだと特に柴田氏の実体験部分がわかりづらいと思いますがご容赦ください。

  • テストファースト、CIはもう当たり前。
  • コンピュータにやらせられるところは極力コンピュータにやらせて、人間は創造的な部分に取り組もう

という趣旨が、そのままJohnMicco氏の言っていたことや、今回のJaSST全体通してのメッセージに（結果的に）なっていると感じました。

そのエッセンスは以下のメモでも十分伝わるのではないかと考えています。

内容メモ

※太字は私（伊藤）による

  • パラダイムシフトは2000年前後に起きている
    • 90年代までは目視が主流だった
    • 90年代初期に十分ユニットテストをやってない、というのは、当時は非難するような気はまったくおきなかった。そういう時代だった。
  • プロダクトコードよりテストを先に書くルール
    • 規律
  • フィードバックをいかに早くできるか
    • たとえばエンドユーザからのフィードバックしかないと、遅すぎる。実際にそんな組織はないはずで、QAテストやシステムテスト、単体テストなどを行ってフィードバックを行っている。単体テストは先週書いたコードや２週間前に書いたコードに対してだったりするかもしれない。これだとまだ長い。
    • 単体テストを先に作ってコードを書くことで、実装からテスト実行までのフィードバックループを最も短くできる。「今書いたコードを今テストする」
    • テストファーストだと「デバッグしている」という感覚がなく、「ひたすら実装している」という感覚
  • 手でやったテストは資産ではない、自動テストは資産である
  • 自動テストがないソフトウェアは、ずっと使っていくと腐る
    • 腐っている＝メソッドが長い、ネストが深い、など
  • 継続的インテグレーション
    • keyword:ビッグバンインテグレーション
  • 2010年以降は継続的インテグレーションから継続的デリバリーが登場
  • 自動テストを導入した「だけ」という現場が多い。
  • 道具を使いこなせていない
  • CIの問題
    • ビルド失敗が放置されている
    • 開発者がビルド失敗に関心をもつには、マネージャが関心を払わないといけない
    • CI環境でのビルド失敗を、開発者のローカルで再現できなかったり
    • 静的解析ツールの結果に関心がない
    • 開発者が警告に関心を払う。マネージャは、内容までは見なくてよいが、なぜ増えているのか/減っていないのかに関心を持つ必要がある
    • 改善に興味がない

私（柴田さん）の経験

  • HOLENET開発
    • 教育研究用マイクロコンピュータネットワーク
    • バージョンコントロールはない
    • フロッピーで管理
  • ワークステーション開発
    • バージョン管理はあったはず（CVS？）
    • ビッグバンインテグレーションをやってた
    • 分散コンパイルをして高速化
  • 米国ゼロックス
    • 当時のゼロックス固有の何かをつかっていたはず
    • 二週に１回ビッグバンインテグレーション（ぜんぜん成功しない）
    • 必ず失敗するので、頭にきて夜間ビルドを導入
    • 月曜にリリースをする、という話だったが、実際にリリースできたのは大体水曜日
  • 以下を作った
    • CodeReviewGuide
    • C++ Coding Standard
  • コードレビューは単体テストの前におこなうべき

（柴田さんが）学んだこと

  • マルチスレッドプログラミングの困難さ
  • マルチスレッドプログラミングにおける重要な４要件
    • きちんとしたレビュー
    • 自動テストによるテスト
    • 様々な環境での長時間ランニングテスト
    • ハングしたらその場で徹底して調査
  • 終わったあとに分析しても、分析結果は役に立たない
  • 日本の開発者の多くは
    • 自動実行されるコードを書いたことがない
    • テスト駆動はやったことあっても、テストファーストはやったことがない
    • CIを経験したことがない
  • 継続的インテグレーションは強みではなくなった
    • CIや自動テストを実践していることは強みではなく、むしろ実践していないことが弱み
    • 実践を推進しないマネージャも、弱み

ソフトウェア開発とQA

  • 開発者もテスト手法を学ぶ必要がある
    • コードカバレッジなんて品質全然担保しない
    • カバレッジを100%にするための作業が行われたりする
    • 今書かれているコードが全部通った、と言っているだけ
  • QAも開発がきちんと回っているのかに関心を持つ

まとめ

  • TDDとCIは必須
  • QAとDevは開発の早い段階から品質を作りこむために協業すべき
  • 作業はコンピュータに、人は創造的な活動を

質疑応答

  • Q1
    • API設計をできる開発がいない、は実感しているところ。開発とQA両方にそういった教育が必要。経験を積む以外に、教育手法や勉強方法になにがあるか。
  • A1
    • 経験を積むには、レビューがちゃんとできる人に教えてもらう必要がある。エンジニアが一人でAPIを設計できるようになるよう教育もする。
    • 教育について間違っているのは、「教育をやっただけではだめ」ということ。「教育」と「現場での指導」は必ずペアでないとだめ。せっかく教育したのに、現場の上司が誰もできないとかありがち。
    • 教育では架空の例で説明をして、現場で実際の問題に適用をする。
    • レビューの場において、最初は一方的に指摘をする。ある程度時間が経って、自分が指摘する前に周りが指摘しはじめる＝チームが成長している。そのくらい教育をし続けないといけない
  • Q2
    • TDDやテストファースト、CIがまだ常識でもなんでもなかったとき。前例が少ないなか試行錯誤したと思うが、どういった苦労があったか、チームでどのように取り組んだか。
  • A2
    • 失敗がどうこうではなく「このやり方でやっていかないとダメだ」と思っていた。なので、立場上強制をした。「これでやるぞ」と。
    • ある程度できるようになったときに、その組織をどうやって大きくするか。出来る人をどうやって増やすか。
    • 開き直って新人をどんどん投入した。新人は「こういうものだ」というと素直に聞いてくれるので、良い開発プロセスになっているところに新人を投入。
    • 中堅を入れるときはその人次第。頑固な人は頑固だし、素直なひとは素直だし。
    • 自分に権限があったので、強く言い続けた、というのが大きい。
    • 立場上上だった、というのが一番大きいと思う。
  • Q3
    • 届いたデバイスが思い通りにうごかない、エミュレータとちがった、という場合にどうやったか。
  • A3
    • 良い質問。
    • Layer1の担当者がプログラムのデバイスドライバを作る。
    • 実際のハードウェアで動きが違ったときにどうするか、それを担保しないといけない。
    • Layer1のひとたちだけが、実機でもテストをしていた。
    • 実機とエミュレータの違いがあったら、エミュレータに必ず反映していた。
    • 実機で問題が起こってエミュレータで起きない場合、エミュレータでも同じものが「起きるように」変更していた。
    • そこより上のレイヤーの人たちが実機を使わなくていい、ということを担保していた。
  • Q4
    • マルチスレッドをなぜ、ガイドで止めなかったのか（日本ルビーの会　せきさん
  • A4
    • 困難は困難でわかっていたが、実際にはあんまりマルチスレッドしてない。
    • 実際にはちょこっとだけスレッド使ってやろう、ということでやってた。
  • Q5
    • システムテストレベルまで全部自動化すると、Flaky対策。テストコードとプロダクトコードの品質のバランス。（伊藤注：この質問を聞き取れず。）
  • A5
    • かなりFlakyは出てくる。
    • テストコードも製品コードと同じくらい作りこむ、リファクタリングするというのが大前提。
    • Goのチャネルを使ってうまいことマルチスレッドできるんじゃないかと思ってGoを使ってみた。
    • それでもやっぱりデッドロックとか、Flakyな部分はよくあった。
    • ソースコードを見ただけではわからないようなビミョウなタイミングでのバグに遭遇したこともあった。
    • 3か月前の改修の影響でたまったまバグが出たこともあった。そのくらい、マルチスレッドはFlaky。

感想

開発時代にやっていたことのお話、中々聴けない内容なのでとてもおもしろかった、というのがまず１つ。

あと，やっぱりJasst全体通して感じたのは、「品質良くするために自分たちで環境含めて工夫してる」ということ。ツールの開発をするレベルから。

GoogleのJohnMicco氏の講演もそうだったのですが、よいものを作るために何をすれば良いかを常に考えて、それを実践しているのが当然、なんですよね。

柴田さんのお話にもあった、開発へのフィードバックをなるべく速くしたほうが良い→じゃあテストファーストだな、とか。自分たちで改善をして “当たり前"を常にアップデートしている組織（個人）と、昔からの当たり前を引きずっている組織（個人）で、ギャップがとてつもなく開いている ことを実感しました。

講演中の参照本