日々量産

考えてることとか

JaSST Tokyo 2018 1日目

JaSST Tokyo 2018に行ってきました。メモはそこそこに感想をなるべく書く。

Advances in Continuous Integration Testing at Google

同時通訳で聴いてたけど、僕の頭では理解が追い付いていないかもしれない。

以下メモ。

  • GoogleはUX周り以外のテストを全て自動化している。コード変更とテストは当たり前という文化が根付いているため。
    • (Flakyなテスト=コードの変更無しでも成功←→失敗する不安定なテスト。マルチスレッド、日付によるタイムラグ、)
  • 以下の課題を対処した
    • テスト実行中のコンピュータリソースと実行時間
      • コードの変更から依存関係があるテストだけを選び実行する(これだと共通部分の変更の影響が大きい欠点がある)
      • 定期的に全テストを走らせる。(マイルストーンと呼ぶ)
    • Flakyなテストの対応。
      • わずか数%でもテストケース数の割合からすると無視できない
      • →不安定さを検知する仕組みを作り、データベース化
        • マイルストーン間もしくは変更~マイルストーンのテストの結果を記録し、比較
        • コードに変更がないが、テスト結果に変更があったテストを見つける。(成功→失敗、失敗→成功となっていたら)それはFlakyなテストの可能性が高い。
        • 通知でFlakyなテストかどうか確認してもらい、Flakyなテストとしてマーク
      • →失敗時にそれが過去にFlakeなテストであったかどうか知る事で調査工数を減らした

気になったこと

  • コードの変更とテストの紐付けかた
    • Javaなら静的な部分はASTを読むなどで引けそうだが、そうでない部分は?
  • どうやってテスト結果を追跡しているか。
    • ユニークIDを振る?テストクラス名などある程度まとまった単位?

感想

これを聞いて思ったのは、うちと比べたら何十歩も先をいっているから、近づく改善を進めないとダメだなぁ、と。うちはGoogleがやっているところと比べると程遠いところにいる。

今のうちはこんな感じ。

  • テストの行い方が「現場」ごとに変わる
    • 結合試験・負荷試験といったざっくりな単位でのテスト計画ぐらい。テスト計画を説明するような資料は無い。
    • フォーマットばらばら
    • 取るべきエビデンスも明確になってない
    • テスト実施に必要なデータは手作業で作ることが多いが、たまにスクリプトでデータを作ってスクリプトで流す現場もある
    • 「テストケースを列挙してそれに従って実施する」「自動化は十分にされていない」という点は共通
  • テストは一通り正常にパスしたら、その成果物は確認以外に使われない
  • 全テストはしたくない時間的に難しいので、変更点に着目して手作業でテストケースを出しなおして、客を説得する
  • Googleのように頻繁なリリースを行わないものの、なりふり構わず手を動かせ!という状況に落ちいってる。

これ以上は愚痴になるので控えるが、良くしていきたいという気持ちはある。気持ちだけ。どうやっていけばよいかはわからぬ。

昼休憩

近くにある「つじ田」にいきたかったけど飯時で混んでたので、近くの「とろ肉つけ麺魚とん」に。席も空いてた。

つけ汁は少ししょっぱすぎる感があったけど、麺と絡むと良い感じ。写真は大盛りだったけど、300g~350gぐらいと意外と少なかった。なお特盛まである。

すぐ食いたいなら「つじ田」でなくてもここでいいなという感じ。

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

過去にテストの自動化を試みようとしたけど一人で取り組みことになったり、自分一人でやらないといけない「恐れ」みたいな感じがあって強く勧められなかった。 どうしたらよくなるかなーと毎秒思ってたけど、答えが出なかったので、ここに。

テストプロセス改善モデルというものがあるらしい。知らなかったそんなの・・・ 所感としてはテストを進めるために 今のやり方のどこが問題か・どこを改善していくか・どう進めていくか を見つけるフレームワークという感じ。

自分はテストの自動化ばかりに目が行ってて、実際はコードを書く前から働きかけたり準備をしていかないとうまくいかない、というのは薄々感じていた。 ただ、自分が行おうとしている事に自信がなく、それでうまくいかなかった場合はどうしよう、と不安になって言い出せず、結局今までの手動で押し切るやり方になってたり。

そこをテストプロセス改善モデルで理論武装して、周りの理解を得るような使い方は出来ると思う。 多分何の成果も出してない自分がいうよりは、世の中にこういうのがあるからやってみませんか、と言った方が聞いてくれそうだし。

失敗例から学ぶ、テスト自動化成功の秘訣

内容自体は新鮮さがなかったけど、UIの自動化については「向いてるところをやる」という点は考えた事がなかったので良かった。柔軟な考え・対応ができないマン...

どうテストを管理していくかが大変そうだけど。このケースは自動化してます、って言えないとダメなような。

ボトムアップによるテストプロセス改善 ~TPI NEXTを体験してみよう~

2つ前のセッションで気になったので。

用意された枠組みでYes/Noで答えていけば、今何が出来ているか・出来ていないか・目指すべきはどこか、と考えるきっかけには十分なりそう。まずはやってみたい。

まとめ

やっぱり良くしたいという思いはあっても、一人だと何もできないという点に落ち着くと思う。協力者が必要だ。

TPI NEXTを見ても、まずはチームとして「何が出来てるか出来ていないか」、客相手にも「こういう取り組みやってて、より良くしたいんで関わらせてください」って始めていくような感じに思える。 他のテストプロセス改善モデルを見てもいきなりテストコードを書くところからは始まらない。テストプロセスなんで、当たり前だけど。