柴田芳樹氏による「私が経験したソフトウェアテストの変遷」のレポです。一部SNS公開NGのところなどもあったので、内容メモ見るだけだと特に柴田氏の実体験部分がわかりづらいと思いますがご容赦ください。テストファースト、CIはもう当たり前。コンピュータにやらせられるところは極力コンピュータにやらせて、人間は創造的な部分に取り組もうという趣旨が、そのままJohnMicco氏の言っていたことや、今回のJaSST全体通してのメッセージに(結果的に)なっていると感じました。そのエッセンスは以下のメモでも十分伝わるのではないかと考えています。内容メモ※太字は私(伊藤)によるパラダイムシフトは2000年前後に起きている90年代までは目視が主流だった90年代初期に十分ユニットテストをやってない、というのは、当時は非難するような気はまったくおきなかった。プロダクトコードよりテストを先に書くルール規律フィードバックをいかに早くできるかたとえばエンドユーザからのフィードバックしかないと、遅すぎる。実際にそんな組織はないはずで、QAテストやシステムテスト、単体テストなどを行ってフィードバックを行っている。単体テストは先週書いたコードや2週間前に書いたコードに対してだったりするかもしれない。単体テストを先に作ってコードを書くことで、実装からテスト実行までのフィードバックループを最も短くできる。自動テストを導入した「だけ」という現場が多い。道具を使いこなせていないCIの問題ビルド失敗が放置されている開発者がビルド失敗に関心をもつには、マネージャが関心を払わないといけないCI環境でのビルド失敗を、開発者のローカルで再現できなかったり静的解析ツールの結果に関心がない開発者が警告に関心を払う。終わったあとに分析しても、分析結果は役に立たない日本の開発者の多くは自動実行されるコードを書いたことがないテスト駆動はやったことあっても、テストファーストはやったことがないCIを経験したことがない継続的インテグレーションは強みではなくなったCIや自動テストを実践していることは強みではなく、むしろ実践していないことが弱み実践を推進しないマネージャも、弱みソフトウェア開発とQA開発者もテスト手法を学ぶ必要があるコードカバレッジなんて品質全然担保しないカバレッジを100%にするための作業が行われたりする今書かれているコードが全部通った、と言っているだけQAも開発がきちんと回っているのかに関心を持つまとめTDDとCIは必須QAとDevは開発の早い段階から品質を作りこむために協業すべき“作業はコンピュータに、人は創造的な活動を”質疑応答Q1API設計をできる開発がいない、は実感しているところ。開発とQA両方にそういった教育が必要。経験を積む以外に、教育手法や勉強方法になにがあるか。A1経験を積むには、レビューがちゃんとできる人に教えてもらう必要がある。エンジニアが一人でAPIを設計できるようになるよう教育もする。教育について間違っているのは、「教育をやっただけではだめ」ということ。「教育」と「現場での指導」は必ずペアでないとだめ。教育したのに、現場の上司が誰もできないとかありがち。教育では架空の例で説明をして、現場で実際の問題に適用をする。レビューの場において、最初は一方的に指摘をする。ある程度時間が経って、自分が指摘する前に周りが指摘しはじめる=チームが成長している。そのくらい教育をし続けないといけないQ2TDDやテストファースト、CIがまだ常識でもなんでもなかったとき。前例が少ないなか試行錯誤したと思うが、どういった苦労があったか、チームでどのように取り組んだか。A2失敗がどうこうではなく「このやり方でやっていかないとダメだ」と思っていた。