WACATE2018 夏 ～もちもちモ・デ・リングで、もぐもぐテスティング～ 参加レポート #WACATE

はじめに

おばんです、MacBookのマイクでのPodcast収録が限界だったため、ちょっと良いマイクを買っちゃった田中です。

先日、WACATE(Workshop for Accelerating CApable Testing Engineers)という、テストエンジニアのための合宿に参加したのでそのレポートをします。イベントは座学のセッションとワークショップを交互に行う形式でした。資料とTwitterの呟き、それからその他気づいた点などまとめていきます。

WACATE2018 夏 ～もちもちモ・デ・リングで、もぐもぐテスティング～ 開催概要 - WACATE （ソフトウェアテストワークショップ）

参加の目的

  • 開発エンジニアとして、テストエンジニアが集まる空間で知識と雰囲気を感じて視野を広げるため
  • レガシーコードを整理し改善するためのヒントとして、モデリングやテストの方法を知るため
  • 機能開発とバランスをもってテストしていくための方法を知るため
  • テストエンジニア界隈を知るため

参加する前にやったこと

はじめて学ぶソフトウェアのテスト技法

はじめて学ぶソフトウェアのテスト技法

上の書籍を途中まで読んで、以下のことを学んだ。 これはやっておいてよかった。事前学習なしだとだいぶ厳しかったかもしれない。

参加してわかったこと

UMLには複数種類ある

  • クラス図、ユースケース図、アクティビティ図、状態遷移図などはUMLの中の種類

ユースケース図はシステムの全体像を掴むのに有用

  • システム屋以外の人間でもわかりやすいという利点もある

アクティビティ図はアクターがやることの流れを掴むのに有用

  • シーケンス図との違いは、実装に寄っているかどうか
  • シーケンス図を書く場合、どういうデータをどういうプロトコルで受けわたすか、などの詳細設計が行われる
  • アクティビティ図はアクターがどういう行動をするかという概要を時系列順に書くもの

状態遷移図/表は仕様の抜け漏れを探すのに有用

nスイッチカバレッジ

  • 状態遷移をテストする組み合わせの話
  • 0スイッチカバレッジは1つの状態が少なくとも1回のパスを通る組み合わせ
  • 1スイッチカバレッジは1つの状態が少なくとも2回のパスを通る組み合わせ
    • 状態A→状態B→状態A(戻り)→状態B、みたいな

モデリングとは、ある側面から見た概念の捉え方

  • 目的に合わせたモデル(UML)を使って、概念を記述する(文法)
  • UMLに複数種類あるように、モデリングの仕方は様々ある
  • どういう視点でモデルを構築するかが、ある程度体系立てられている
  • これまでは雰囲気でやっていたモデリングだったが、UML書きが体系立ててモデリングをトレーニングする方法になりそう

テストは常に何を切り捨てるかという選択

  • 「全件をテストすることは不可能である」という前提がある
  • その前提に基づいてテストを考えるということは、「なにをテストするか」というより、「なにをテストしないか」ということに焦点が当てられる
  • 2日間のワークショップの中でも基本的に時間不足の状況が作られていて、実戦に近い形でテストを考える必要があったので、とても良いワークショップ設計だった

「テストの視点からのモデリング」 by 朱峰 錦司

twitter.com

「ユースケース図&アクティビティ図 モデリングからテストまで」 by 中村 仰志, 越中谷 郁美

twitter.com

「状態遷移テスト」 by 藤原 洋平, 角田 俊

twitter.com

深夜の分科会

WACATEの夜は分科会という、各々が持ち寄ったテーマについて語り合う時間があります。が、その時間についてではなく、その後の自由時間に行われた深夜の分科会が個人的にとても楽しかったので、そこをピックアップして紹介します。

深夜の分科会で話したテーマはTDDでした。

twitter.com

  • ブロッコリー(@nihonbuson)さんによるTDDのデモ
  • テストファーストとTDDの違いは？
  • 金融系のような大きなプロジェクトをTDDでやることができるか？
    • できるかもしれないが...?
    • 仕様がガッチガチに決められている場合にTDDはできない
      • 「もし入力がほげほげだったら出力はふがふがである」というような仕様を日本語で決められている場合には厳しい
      • それ以上の改善が行えないから
      • これは「誰が書いても同じように実装できるように」ということを主軸に置いたやり方だから(人海戦術を効果的にまわすため)
      • 「動作する汚いコードから、動作する綺麗なコードを目指す」TDDに対して、「綺麗な設計から、動作する綺麗なコードを目指す」アプローチで、ちょうど対になっているはず
    • 長期プロジェクトでのウォーターフォール開発とアジャイル開発の違い
      • ウォーターフォールの場合
        • 2年かかるプロジェクトだったとして、完成時のそのプロダクトの価値判断が2年前のもの
        • 2年後に価値がどうなっているかはわからない
      • アジャイル開発の場合
        • 小さな歩幅で振り返りながら進めるので、プロダクトの価値基準を見直す機会が多い

感想とその後

テスト自体の理解が進んでよかった。また、テストは一人で学習して仕事に投入していくにはかなり高いハードルがあるが、合宿を通してテスト設計をする手順について知れたことで、ハードルを超えられた気がする。周りの参加者と会話やワークをしていくことで、これまで散り散りで理解していた知識をつなげることができたのも、大きな収穫だった。

WACATEは「若手IT技術者が世界に羽ばたく為の加速装置」と銘打っているが、加速するかどうかはこの後にかかっていると思った。 ので、帰ってきてから早速PlantUML + Atomで環境構築をして、手元の処理の流れをシーケンス図で記述していってみている。なかなか良さそう。

あと一番大きいのは、レガシーコードに向き合う勇気がもらえたことかもしれない。一段飛ばしはできないものの、一歩ずつ理解を進める手立てを得られた。