2018/6/16~17に、マホロバマインズ三浦で行われたWACATE2018夏に参加してきました。

１日めのレポートはこちら。

WACATE2018夏参加レポート〜１日目〜 - テストウフ

今回は２日めのレポートです。

詳細なプログラムなどは公式サイトWACATE2018 夏　プログラム内容 – WACATE （ソフトウェアテストワークショップ）をご覧ください。

受けてみよう。UMTP認定試験！

２日めの最初は、今回からWACATE実行委員に加わった岡内さんによるセッション。

UMTPという試験は私は今まで知らなかったのですが、岡内さんの説明がかなーりわかりやすかったです。

UMLの資格試験の主なものには

  • UMTP
  • OCUP

の２つがあって、UMTPのほうが実務寄りであること。

UMTPのレベルには４段階あって、私のように「WACATEのこのセッションを受けて存在を知った」という人が当面の目標にするL1とL2についてのレベル感などを教えてもらいました。

L1は読めればOKで、L2は普通に読み書きが出来るレベルを求められるそう。実務で使う場合は読むだけでなく書くことになるのだから、最初から読み書きができるように勉強するのがおすすめだよ、とのこと。なるほど確かに。

ちょうど初日のワークでUMLをいくつか書いてみて、「こんなときはどうするんだろう」とか「これで合っているのかな？」という疑問が何度も出てきたので、勉強のモチベーションを維持する意味でも、資格取得を目指すのは良い方法だなーと思いました。

他にも、試験中・試験終了時の雰囲気など、実際に受けて合格した人の生の感想を聞けたというのがよかった。

あと内容関係ないですが、岡内さんの喋りがこなれていて、マネしたくなりました:-)

メモ

  • UMTP知ってる人ー！
    • ぽつぽつと
  • 注意
    • 後ほどスライドを公開しｍさう
    • UMLの資格試験の話なので、そんなにテスト寄りではないよ
    • 本編のワークのヒントも出ないよ
  • 目的
    • モデリングのトレーニング手段として、UTMP認定試験の概要を理解する
    • CBT形式の資格試験の受験方法を知る
  • 岡内さんとモデリング
    • 仕様記述の整理をするツールとして考えている
    • 文字だけで整理するよりも、モデルで検算ができる
  • モデリングの資格試験
    • UMTP：実務寄り
    • OCUP
  • UMTPを受験するために知っておくこと
    • 公式ページより
    • レベルは４段階
      • 上位を受けるには下位の合格が必要
      • いきなりL3を受験できるキャンペーンもある
      • L1
        • UMLが読めれば合格できる
      • L2
        • UMLモデルの読み書きが普通にできる
    • 受験料
      • 16200円
      • 80分
    • 出題カテゴリー
    • 開発プロセス/モデリングの基本概念
      • UMLが向いている開発プロセス
      • オブジェクト志向の基本概念
      • モデリングって何
  • 構造モデリングの例題
  • 要求モデリングの例題
  • CBT形式の資格受験
    • パソコンで受ける
      • 会場にある
    • ポケットに手を入れたらカンニング扱い
    • 回答終了したら即結果が出る
      • 「やった！」って言うと不合格になる？
  • 受けようと思ったら、本などがある

ワークショップ＆ワーク成果発表

今回のWACATEのメイン、モデリングのワークショップ。

5, 6人のグループでそれぞれ与えられたお題に対してモデリングを行い、テスト項目を出してみよう、というものでした。

  • お題
    • 簡易稟議システム
  • 期待する成果物
    • 仕様モデル一覧
    • 各仕様モデル
    • 各仕様モデルに対するモデルベーステスト基準
    • 各仕様モデルからモデルベーステストで抽出されたテストパターン一覧
    • 仕様書の不明点一覧と班内での決め
  • ~12:10総合演習
    • 途中定期的にヒントを配布
  • やりきること。

この「やりきること」を念押しされていて、グループでも度々「やりきろう！やりきろう！」と何度も言い合ってすすめました。

このワークについては別記事にまとめます。

当日は、まずタスク出し＆時間配分決めを行って、それに従ってワークを進めていきました。かなり厳し目の時間配分の中で作業を進めていなかければいけないということで、まぁ大変でした。といいつつ、この大変さを味わって、成功した点と失敗した点を持って帰って加速するのがWACATEの醍醐味でもあります。

WACATE後は５日間くらい、TwitterとかLINEとかSlackとかいろんなところで、ワークについてあーだったこーだった話をしていました。

原因結果グラフと WACATE は僕に何を教えてくれたのか

加瀬さんによるクロージングセッションでした。

原因結果グラフ、は聞いたことはあったもののちゃんと使ったことがなかったので楽しみでした。

原因結果グラフは、

複雑な仕様を持つテスト対象に対して、入力・状態・イベントと出力の論理関係をグラフで表現して、デシジョンテーブルに変換する組み合わせテスト技法

で、

  • 複雑な論理関係を整理できる
  • テスト条件を自動生成できる
  • 論理関係のテストを効率的に実施できる

といった利点があるそうです。

実際にCEG（原因結果グラフ）を書いてみるワークもあって、雰囲気はつかめたかも！と思っています。自然言語で書かれた複雑な仕様を誰かと共通理解するときや、逆に「眼の前に動くものがある」という状態で、そこから対象を分析してテストを考えなけれればいけない場合などに使えそうだなーと思っています。

まずは身の回りにある論理関係が複雑そうな問題に対して、原因結果グラフを書いてみて勉強する予定です。

メモ

  • 本日のゴール
    • 原因結果グラフというツールを知ること
    • 原因結果グラフの描き方を知ること
    • 使いこなす第一歩目を経験すること
  • 資料はあとで公開
  • 原因結果グラフの解説（描き方編）
    • 定義
      • 複雑な仕様を持つテスト対象に対して、入力・状態・イベントと出力の論理関係をグラフで表現して、デシジョンテーブルに変換する組み合わせテスト技法
    • メリット
      • 複雑な論理関係を整理できる
      • テスト条件を自動生成できる
      • 論理関係のテストを効率的に実施できる
    • CEGの使い方手順
      • テスト対象を分析・変換・整理する
        • ラルフチャートを用いて、斜め右上から左下にかけて線を引いて分けた場合、左側に原因、右側に結果が来る
        • ポイント
          • 短文で考える
          • キーワードを見つける
            • 論理関係に関わりそうなキーワードに注目
            • 英語にするとシンプルになることが多いので、英語にしてみる
            • グルーピングする
      • 結果とその要因を見つけて論理関係を作る
    • グラフを描く
      • 結果とその原因を見つけて論理関係を作る（再掲）
        • 秋山さん
          • 「原因から考えると混乱するよ」
        • 加瀬さん
          • YesかNoかで答えられるか、でノード名を考える
            • 命題にする
          • 「他にないか」と問いかける
          • 「どういう時に？」と問いかける
      • CEGの描き方
        • AND条件
        • NOT条件
          • ノードの名前は肯定がベター
        • OR条件
        • 秋山さん
          • テストケースを作るときに間違わないことが大切
          • なるべくわかりやすいノード名を
      • CEGの用語
        • 原因ノード：テストをするときの条件
        • 結果ノード：テストをしたときの期待値
      • 中間ノードをどう考えるか
        • オフサイドの例
        • なぜ中間ノードを作るか
          • わかりやすくする（粒度を粗くする）
          • 中間ノードの真偽を知りたいとき（局所化）
          • 例外や特別な追加条件と思われるとき
  • コーヒーブレイク
    • 開発で品質改善
      • テストをしないで品質を上げたい
      • 開発者が増えるようなワークショップになると、QAの人もやりやすくなるはず
    • 自動化
      • ムダなテストしてるな、と思った
      • 自動化していても、あまり効果的なテストができていなかった
  • 制約を見つける
    • 定義
      • 原因ノードや中間ノードに対して、取りうる組合せに制限をかけること
    • メリット
      • ありえない組合せを排除できる
      • 論理関係のテスト網羅性を高める
    • ORから探す
      • ことばとしては「あるいは」など
      • EXCL
        • エクスクルーシブ制約
        • いずれか一つのノードが真になる場合（高々一つ）該当するノードに制約EXCLをつける
    • 制約５つ
      • ONE
      • EXCL
      • INCL
      • REQ（今日は紹介のみ）
      • MASK（今日は紹介のみ）
  • デシジョンテーブルへの変換（軽く）
    • CEGのテスト条件の生成は難しい
    • CEGTest
      • ワークの模範解答はCEGTestの「クラウドから取り込む」においてある
  • CEGを使ってみる前に
    • すべてのテスト対象に使えるかというと、そういうわけではない
    • テスト対象を分析してみた結果、どんな方法でテストするかを検討する必要がある
    • ソフトウェアテスト技法ドリルも参照

クロージング

なんと今回、ポジペ３賞のひとつ「バイアスドフェイバリットペーパー賞」をいただきました。

これは招待講演者の加瀬さんに選んでいただいたものです。

ポジペには

  • wacate初参加のときは「うわーみんなすごいー」で終わってしまったこと
  • そこから、ブログを始めたり、JaSSTに出たり、社内でLTしたり、社外向けの講演に出たり、社外で個人発表したり、と加速していったこと

などを書きました。

この辺の流れに共感していただけたようで、とても嬉しかったです。あー、間違ってなかったんだ、このままもっと加速していこう！という気持ちになれました。

冬は参加できなさそうですが、またそのうちWACATEに戻ってきて、何かしらコミットできたらなぁと思います。

参加者のみなさん、実行委員のみなさん、ありがとうございました。

おかげで加速しつづけられそうです。