NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'20 Niigata

opening

当イベントは Zoom によるオンライン開催である。実行委員長の永井氏によるオープニングで始まった。初回の2011年から今回で10回目とのこと。コロナの影響で例年の開催時期を変更したが、100名を越える方々に全国各地から参加いただき感謝している、と語った。今回のテーマはテスト自動化であり、多くの方々が関心を持つテーマだと思う、と締めくくった。

基調講演
「組織にテストを書く文化を根付かせる戦略と戦術 JaSST 新潟版」
和田 卓人 氏（タワーズ・クエスト）

和田氏は自己紹介で、様々な企業の技術顧問の他に、技術書の出版を手がけており、最新刊は「Engineers in VOYAGE」と語った。また、自分を紹介するアスキーアートとしてライオンの画像を紹介した。この画像は、テストコードを書かない時に使われているようで、なまはげのようなものであり、そのため怖い人間と思われているが温和です、と語った。

戦略論

和田氏は、戦略論の前に、その根幹となる以下の話から始める、と語った。

• ITは事業のコアになり、ITの出来が事業の出来を左右する時代である
• ITのアジリティが競争力なので、最近のソフトウェア開発は繰り返すことが大前提である
• ITの開発速度／品質の指標として、４つのキーメトリクスが有効とされ、この４つは切り離せない
  • 開発速度の指標：リードタイム、デプロイ頻度　→　仮説検証プロセスを迅速に回す
  • 品質の指標：MTTR（平均修復時間）、変更失敗率　→　早く修復する、切り戻しを少なくする,
• 品質を作り込む発想で、テスト自動化を始めとした技術基盤が必要である

次に、2016年～2019年のDevOpsに関する調査からわかることとして、以下が紹介された。

• ITの開発速度と品質はトレードオフの関係ではない
• 先進的な企業（ハイパフォーマー）は、ITの開発速度と品質に関する全ての指標が良い
• ハイパフォーマーと、遅れている企業（ローパフォーマー）の差は年々開いている（2016→2019）
• 上記の両企業について組織的なIT投資の差が明らかである
• 他社（外注先）が開発したカスタムソフトウェアがある場合、ローパフォーマーとなる傾向がある

次に、戦略論として、2つの昔ながらの「ならわし」と、現代の解釈が紹介された。

• テストコードを書く時間はない　→　テストコードを書く時間がないのではなく、テストコードを書かないから時間がなくなる
• 動くコードに触れるな　→　「何もしてないから壊れる」時代へ（OS/Browserなどが勝手にupdateされる）

次に、現状テストコードを書いていない組織への自身のコンサル経験から、以下が紹介された。

• 近くのゴールを選択する（欲張らない）
• ToBe ではなく、NotToBe（やめたいこと）から始める

次に、権限を持つマネージャ層へは、ビジネスと関連させた説明をお勧めする、と語った。

• 保守性の低さ（技術的負債）を解消することは、ビジネス面での効果が期待できる
• 内部品質への投資の損益分岐点は１ヶ月以内に現れる
  • これが3年後だと、誇りや道徳の話になってしまう

戦術編

この章の冒頭では、和田氏から2冊の書籍が紹介された。

1. 「レガシーコード改善ガイド」には、最初に取り組むべきことが書かれている
   • レガシーコードに関する以下のジレンマを越えて、レガシーコードに触るための語彙と技法が整理された本である
     • レガシーコードは、後からテストコードを書きづらい
     • テストコードを整備するためには、コードを変更する必要がある
2. 「レガシーソフトウェア改善ガイド」には、レガシーコードを改善するための３つの選択肢が示されている
   • リファクタリング：一番大事なところに手が届きにくく、頓挫しやすい
   • ビッグ・リライト：全部作り直すため、ハイリスク・ハイリターン
   • リアーキテクティング：システムをサブに分けて刷新する。伊勢神宮式。お勧め

次に、どこにテストを書くか、どうテストを書くか、について説明があった。

• どこにテストを書くか
  • 大事なのは有効なところに手を打つことで、以下のトリアージが必要
  • テストケースの一覧に対して、以下を見積もり、優先順位を付けてから着手する
    • リスク、手動テストのコスト、テスト自動化のコスト
• どうテストを書くか
  • 自動テストにおけるテスタビリティは書籍「実践ソフトウェアエンジニアリング」が参考になる
  • 接合部を引き剥がしてテストを書くことについては、書籍「レガシーコード改善ガイド」が参考になる
  • こだわらない。理想形はさておき、現場では、最初から全部やろうとしない
  • こだわろう。良いテストとは、人間の手を介さずに再現可能であること。時間が掛かっていてもいいから実装する
  • テストがないのは既に設計が悪い兆候である。実装を確認するためのテストを書かないこと。設計を見直すこと

次に、自ら実践する大切さが語られた。

• 背中を見せよう。サンプルとデモが大事。真似してもらう。最初はコピペでもいい
• Social Change starts with YOU。自分が書けるようにならなければ、誰も書けるようにならない
• 私は github 上でOSSを作っている。テストコードも書く。受託開発を年3～4案件やるようにしている

和田氏は、最後に「テストはプロの嗜みである」と締めくくった。

筆者感想

第一人者としての、とても深みのある講演だった。危機感の醸成から始まり、精神論だけでなく、理論的にテストコードを書く意義が詳しく語られ、多くの方々に納得のいく内容だったと思う。和田氏のコンサルティング経験談も楽しかった。これからの時代、ITのアジリティが競争力となるので、テスト駆動開発、テスト自動化の重要性を、改めて認識することができた。

事例紹介-1
「継続的なテスト自動化のための取り組み事例」
山内 佑二 氏（オムロン）

セッション概要

山内氏は、画像センサのシステムテスト（性能、負荷、タイミング）を自動化したのに次のプロジェクトでテストが動かない課題に取り組んだ事例を紹介する、と述べた。紹介された課題と対策は以下の通りである。

1. 新しいテストをどう追加すべきかわからない
   • スクリプトを理解しやすく、再利用できるようにした
   • 見て理解するのが容易な構造で、テスト追加のための工数を削減、手順化も可能になった
2. テスト環境の組み替えの手間
   • 効率のよいテスト順序、実⾏時間を⾒積もった
   • テスト環境の組み替えや完了待ちを最小限にすることで、自動テストの稼働時間を効率化できた
3. テスト環境の設定ミスによる後戻り
   • 誰でも正確なテストができるようにした
   • 実行ミスやトラブルを回避し、テスタからのQ＆A数も削減された
4. テスト結果の確認に時間がかかる
   • テスト結果のエビデンスを適切に残した
   • 妥当性チェックのためのテスト再実行回数やスクリプトの分析工数が少なくなり、工数を削減できた

最後に、肥大化している自動テストのメンテナンスコストを下げ、実行効率を上げることで、今後も無理なく自動テストの運用を継続できるようになったので、今後の展開として、自動テスト環境のテスト工程以外への展開、遠隔テストや検証の検討が必要であると締めくくった。

筆者感想

画像センサという、自動テストの難易度が高いプロダクトに対して自動化に取り組んだ事例だった。自動テストは使い続けることが重要で、その効能として、品質問題だけでなく価値創造にパワーをシフトすることができる、という言葉に感動した。

事例紹介-2
「APIテストを自動化してリグレッションテストにしたら、安心で安全な開発ができて気持ちが楽になった」
伊藤 潤平 氏（ウイングアーク１ｓｔ）

セッション概要

伊藤氏は冒頭で、オンライン講演は反応がないと寂しいので「今日のランチは何を食べましたか？」と問い掛け、チャットに多くの書き込み（ランチで食べたもの）が表示され、嬉しいと語った。そして、自身は Scrum Fest Osaka 新潟トラックオーナーなどの社外活動をしていると語った。

そして、事例紹介に入った。プロダクトの開発にスクラムを導入し、品質保証側（我々）はこれまで通りにやることにしたが、Quality Gate を通過できないことが度々あり遅延が発生したとのことである。そこで、開発チームへのヒアリングを通して、開発工程で品質を高め、スムーズな検証作業を行なうことに取り組むことにした、と語った。

伊藤氏は、開発部門に Software Engineer in Test (SET) をアサインし、以下の改善を実施し効果があった、と語った。

• 改善①：テストのルール作り
  • テストレベルの定義付けをおこない、実装者、SET、QAの役割分担を決めた（下記）
  • コンポーネントテスト（実装者）、結合テスト（SET）、機能テスト／システムテスト／受け入れテスト（QA）
• 改善②：WebAPIテストの自動化
  • テスト観点を作成し、API仕様書からテストケースを作成する
  • JUnitを使用してテストケースを実装し、Antでテスト結果のレポートを作成する

次に、現在は体制を変更し、以下の役割分担にした、と語った。

• 開発部門（実装者とSET）が、実装からシステムテストまでを実施し、QA部門は受け入れテスト（監査）を実施する
• 開発部門は、PBI（プロダクトバックログアイテム）毎にリーダを任命し、リーダがメンバを選出し、実装からテストまでを実施する
• QA部門は、マスターテストプランをPBIとひもづけて段階的に品質を積み上げるフェーズテストプランを作り、その過程を見る

最後に、現在のWebAPIテスト自動化の課題は以下の通りで、誰か一緒に取り組みませんか？、と締めくくった。

• テスト結果分析という新たなタスクが生まれた
• テストケース数が膨大で実行に時間がかかっている
• テストコード自体のリファクタリングが必要

筆者感想

最初にスクラムの考え方とやり方を導入して効果を出してから、体制を変更して自分たちのやり方を生み出していった経緯は、素晴らしいと思った。アジャイル開発は、つい実践自体が目的となりがちだが、伊藤氏の現場では、常に課題を見据えて積極的に変化させている。今後の更なる変化が楽しみと思った。

closing

再び永井実行委員長から締めの挨拶があった。基調講演ではテスト自動化の基礎的なところ、事例紹介は現場での具体的な話をしていただき、日頃の業務に役立つ内容だった、と語った。そして、分野が異なる人に対してもヒントになるのではと思う、と締めくくった。

筆者感想（全体）

筆者が初めてJUnitに出会った時、テストコードが開発を支える安心感をプログラマーとして感じたことを思い出す。それから17年が経った現在、今回の講演や事例発表を聴講し、ビジネスの成功にはテスト自動化が欠かせない時代になったと確信した。Web／組込みの分野を問わず、現場の最前線では、テスト自動化を用いて現場の課題を解決し、ビジネスに貢献しようとしていて、関わっている方々は楽しそうだ。これからますますテスト自動化が必要となることは間違いなく、私の周囲の人達に、現状の危機感と、技術者としての楽しさを伝えていこうと思った。