2018/6/16~17に、マホロバマインズ三浦で行われたWACATE2018夏に参加してきました。
嘘です。参加しています。
初日の夜に初日のレポートを書いておきます。
２日めのレポートはこちら
WACATE2018夏参加レポート〜２日目〜 - テストウフ
公式サイトはこちら→若手エンジニア向けワークショップ:WACATE （ソフトウェアテストワークショップ）
BPPセッション 2017年度のJaSSTを振り返ろう
2017年冬に行われたWACATEにおいてBPP賞を受賞したyoshitakeさんによるBPPセッションでした。
2017年の全国のJaSSTに参加された（！）レポートがベースだったのですが、友人であるというのを差し引いてもめっちゃいいセッションだったと思います。
このセッションではテストをまだ良く知らない、これから勉強していきたいという方向けに、どこにアンテナを貼って情報を得ていったらいいかの対象を広く紹介してくれた、と感じました。
話を聞いていても、本当にテスト自体やテストコミュニティが好きだということがひしひしと伝わってきたので、WACATEのはじめのセッションとしては最高だったんじゃないでしょうか。
特に良かったのが、実際にWACATEに参加している人の名前を出しながら「あの人はこんなことが得意」とか「あの人に聞くとこんな情報が得られる」といったことを話してくれたこと。
この話を聞いたことで、初参加の人が話しかけたくなったり、距離を縮めることができるようになったと思っています。
（この辺は発表中に私がツイートで嫉妬しまくっていました。
この発表資料を見ると、最近のテストイベントがおさらいできるのと、興味がある部分の情報をどう集めるかの一歩目が踏み出せると思います。おすすめです。
メモ
/wacate2018summerBPP/BPPセッションの関連資料
- テスト知らない人向け
- JaSST去年の全部行った
- 16コくらいあった
- 数とかどうでもいい
- なぜ行ったか
- そもそもなぜテストをはじめたか
- 大学院やめることになった
- 求人を調べた→テスターの募集をしている
- テスターを教育してくれといわれた
- 周囲の人の「良いテスター」のイメージ
- バグがいっぱいだせる
- 周囲の人の「良いテスター」のイメージ
- そうだ、JaSST行こう
- そもそもなぜテストをはじめたか
- 行く目的
- テストについて知りたい
- 良いテスターがなんなのか知りたい
- あわよくば界隈で有名になりたい
- JaSST＋wacateの話
- 各テーマをざっと紹介
- 特に印象に残ったものをピックアップ
- よかったこと/うれしかったこと
- JaSST新潟
- ユーザビリティ/UX
- 魅力的品質・当たり前品質を知った
- 狩野モデル
- 良かったこと
- ワニさんなそさんと知り合えた
- ユーザビリティ/UX
- JaSST東北
- テストエンジニアの教育
- やまさきさん
- テスターのスキルセットの話
- テストスキル
- ITスキル
- ドメイン知識
- ソフトスキル
- ものすごくハードル高いねQAって
- miwaさんとは
- あのチーム
- テストエンジニアの教育
- wacate2017夏
- テスト技法はいつもひとつ
- 細川さんのが響いた
- JaSST関西
- アイ、テスト
- また細川さんの話が聞けた
- あだちさんが来ていた
- SaPIDとは
- ソフトウェアプロセス改善手法
- 安達さんの経験
- VSTeP
- 西さんが考案したテスト設計の方法
- JaSST北海道
- その先の、道へ
- クオリティオブエンジニアライフ
- 知ったこと
- ユーザストーリーマッピング
- レビュー
- Quality of Life
- 特に良かったこと
- くっきーさんに会えた
- アフターツアーでテスト漬けの２日間
- JaSST九州
- 貢献
- 知ったこと
- テスト設計コンシェルジュ（中野さん
- 九州実行委員に面白いこといっぱい（中武さん
- 特によかったこと
- 中野さんイケメン
- テスト有名人いっぱい
- JaSST四国
- 知ったこと
- TPI NEXT
- 信頼性工学
- 特に良かったこと
- 実行委員距離近い
- 知ったこと
- TPI NEXT
- JaSST東海
- Change the way
- プロセス風土
- 知ったこと
- プロセス改善はちょっとずつ
- 短期的には諦め速く、長期的には辛抱強く
- 特に良かったこと
- 実行委員長すごい面白い
- Change the way
- wacate2017
- すべてがTになる
- 知ったこと
- ユーザビリティテストをやれた
- 特に良かったこと
- 知り合いが多かった
- なそさんに分科会で褒められた
- パインさんに出会えた！
- JaSST東京
- 知ったこと
- Googleすごい
- 日本のテスト界隈の現状
- 知ったこと
- JaSSTに行く目的は達成できたのか
- テストについて知る
- できた
- 良いテスターがなんなのかしりたい
- 知れた
- 今はあの資料とは別かなぁって思っている
- 自分の考えが持てるようになった
- 何をしたいか考えるのは重要
- テストについて知る
- テストを勉強する上で大きな悩み
- チームメンバーと認識乖離
- 知れば知るほど憧れの人が遠のく
- もうひとつ
- 転職
- 今取り組んでいること
- 福岡のテストを盛り上げたい
- ほか
- 最後に
- テストの人たちは優しい
- テストはクリエイティブである
- あなたのチャレンジは業界貢献！（だと思う）
導入：なぜモデリング？
朱峰さんによるモデリングの導入について、です。
モデリングの概要と、テストにおいてモデリングをどう生かしていくかの説明をしつつ、この２日間のワークの基礎となる部分を話していただきました。
私はUMLをまともに読み書きしたことがなかったので、これを機会に一歩踏み出せたら・・・と思ってました。
今回はテスト対象のふるまいをモデル化するということで、UMLの中でも振る舞いモデル、
- ユースケース図
- アクティビティ図
- 状態遷移図
を扱うということ。
また、モデルベーステストの概要と、UMLを記述して可視化するためのツールのデモを見せていただきました。
デモがあるとわかりやすいのと、astah*は全部有料だと思っていたので、無償版使ってみたいと思います。
メモ
- なんでwacateでモデリング？
- 仕様書が古い
- 仕様書が膨大すぎる
- 仕様書が読みづらい
- 仕様書がない
- ゴール
- 様々なモデリング視点／記法があることを理解する
- 汎用的な記法としてUMLがあることを理解する
- モデルをテストに活用できるこよを理解する
- 仕様理解
- テストケース抽出
- モデルをかくためのツールを知る
- モデルとは
- 対象物の振る舞いや性質を特定の観点で抽象化し、それを特定の文法で表現したもの
- ひとつのモデルで全ての振る舞いや性質を表現することは不可能
- モデルへ抽象化する作業を「モデリング」と呼ぶ
- 絵を各、はただのモデルの記述
- どういう切り口で、どう切り取るか、を考えるのがモデリングである
- モデルの記法
- まずは観点
- それを表現するための言語／文法
- UMLダイアグラム
- 表
- テキスト
- など
- 観点と文法
- テストエンジニアがふれるモデル記法
- 仕様モデル記法 ← 今日はコレ
- テスト独自のモデル記法
- 仕様モデル記法の例
- UML
- SysML from UML
- Systems Modeling Language
- UMLから派生したシステム設計用の言語
- 一部UMLの記法を再利用
- さらに文法を制限することでとっつきやすく
- UMLは表現力がすごいので、いろいろ制限し、使い所を絞って整理した。
- 原因結果グラフ
- 数理論理モデル
- 英語ではCFG(cause effect graph)
- テスト独自のモデル記法
- NGT@VSTeP
- Notation for Generic Testing
- FV表/FL表/ラルフチャート@HAYST法
- Function Verification Table
- テスト分析マトリクス@ゆもつよメソッド
- NGT@VSTeP
- モデリングの注意点
- 記法だけ覚えても仕方ない
- 学習／実践を繰り返して「抽象化」能力を磨く
- 「方法論」として整理された洗練された様々な抽象化手順／手法が存在
- RDRA
- UML
- OMGによって策定
- ISO国際規格にもなっている
- UMLの代表的なモデル
- 構造モデル
- クラス図
- 振る舞いモデル ← 今日はここ
- ユースケース図
- アクティビティ図
- 状態遷移図
- 相互作用モデル
- シーケンス図
- 構造モデル
- UMLを書くときの注意点
- 改めて、細かい文法にとらわれすぎない
- 多少のカスタマイズもOK
- ただしチーム内で合意
- UMLの文法／メタモデル
- 文法自体をモデルとして表記することが可能
- モデルベーステスト
- モデル変換技術の一種
- 仕様モデルから機械的なルールを用いてテストケースモデルを抽出する技術
- モデルベーステストの例
- ユースケーステスト／シナリオテスト
- ユースケースのインタラクションから、一定のルールに基づき、テストパターンを抽出
- アクティビティ図から、一定のルールに基づき、テストパターンを抽出
- 状態遷移テスト
- 一定のルールに基づき、テストパターンを抽出
- デシジョンテーブル生成
- ユースケーステスト／シナリオテスト
- モデルベーステストの注意点
- そもそも仕様モデルが必要
- 基本、Checkingに該当するテストケースが対象
- UML記述ツール
- astah* community
- 平鍋さんが社長
- communityは無料で利用可能
- PlantUML + お好きなエディタ
- プレーンテキストで書こうぜ、という並が来ている
- astah* community
ユースケース図とアクティビティ図とテスト
ワークが重かった・・・！
重かったというか、モデリングする場合のスコープが結構曖昧になってしまって、グループのメンバーごとにスコープが異なりました。
自分としては、モデリングする場合はある程度範囲を絞ったところに対してモデリングして（＝ユースケース図とアクティビティ図を書いて）、大きなプロセスについては絞った範囲のモデリングを組み合わせてやるのでは・・・？とかとか、悩みが止まりませんでした。
（明日実行委員や他のメンバーに聞いてみようと思います）
メモ
- ユースケース図
- 外部からの要求に対するシステムの振る舞い
- 誰が利用するのか
- 利用して何ができるか
- 要素
- アクター
- ユースケース
- サブジェクト
- 複数のユースケースをまとめる
- パッケージ
- 再利用を目的として複数のユースケースをまとめる
- より詳細に表現するには
- 汎化
- B is a A
- 包含
- A has a B
- 拡張
- 条件による振る舞いの追加
- 汎化
- ユースケース図あるある
- 汎化とか包含、拡張とかうまく区別つかない
- 使わなくて済むなら使わなくてOK。階層構造を持ち込むことになるので、複雑度が増してしまう
- どんな粒度で書いたらいいか迷う
- 汎化とか包含、拡張とかうまく区別つかない
- アクティビティ図
- 開始から終了までの処理の順序、手続き
- どのようにシステムを利用するのか
- 順序立てた手続きの流れが焦点
- 初期ノード、アクションノート×n、ノード
- デシジョン（ガード）
- 分岐
- フォーク
- 非同期
- 主体を明確にする
- パーティションを利用
- アクティビティの特性やリソースなどでグループ化
- パーティション間のやりとりが明確になる
- 手続きのぬけもれ、論理の飛躍などが浮き出てくる
- パーティションを利用
- アクティビティ図あるある
- どんな単位で作成すればいいかわからない
- 開始から終了まででひとつの意味を成す単位
- たとえばユースケース単位
- たとえば複数のユースケースの前後関係（流れ）
- 開始から終了まででひとつの意味を成す単位
- 線が複雑になりすぎて見にくい
- 書きたい範囲に対して具体的に書きすぎている？
- 全体の流れに影響ない線が多くない？
- しっかり厳選した上でそれでも複雑なのであれば、そこが（仕様的な）弱点かもしれない
- どんな単位で作成すればいいかわからない
- ユースケース図とアクティビティ図をテストに利用する
- ユースケースをテストする
- 何を確認したいか
- 個々のユースケースをテストしたい
- 例
- 社員が申請できること
- 管理職が承認できること
- 個々のユースケースにフォーカス
- ユースケース記述でHOWを明確化
- 例
- ユースケース全体の関係をテストしたい
- 社員が申請したものを管理職が承認できること
- 個々のユースケースをテストしたい
- 何を確認したいか
- ユースケースをテストする
- 合わせてテストしましょう
- アクティビティ図から操作手順を導出
- 分岐や繰り返しで複数の操作手順が存在する
- 最もレギュラーなパス
- そのパスが達成できないとシステムが成り立たない、というパス
- 伊藤：ハッピーパスと同義？
- 各分岐、繰り返しを１回は通る
- 最も多くイレギュラーを通る
- レギュラーとイレギュラーの組み合わせ
- 最もレギュラーなパス
- つまり、どこまでテストをすればいいの？というところで、目的にあったレベルのテストを上記の判断基準で選べるといい
- 小演習
状態遷移テスト
状態遷移図は書いたことあるしなんとかなるだろー・・・って思ったら、状態がネストしたりしてなかなか大変でした。
ワークということもあって、「どこまでモデリングするか」といったところでかなり迷っていました。
こちらもやはり、スコープを限定しないとどこまでも複雑な図・表になってしまって厳しい・・・
明日のグループワークの際には、スコープを定義してその外側の部分はグループ内で「こういうこととして仮定しよう！」という合意をとって進めるのが良い気がする。
メモ
- 状態遷移図
- ソフトウェアの動作を整理することができる
- システムの状態と遷移を表現する方法
- 状態遷移図を作成することで、ステータスと遷移するイベントを整理することができる
- 書き方
- 開始疑似状態
- 終了状態
- イベント
- エフェクト
- ステップ
- 状態とイベントを抜き出してみる
- とりあえず、図を書いてみる
- 足りない状態とイベントを追加していく
- より良い状態遷移図を書くコツ
- 状態
- 隠れた状態に注意する
- 状態遷移中の状態など
- 隠れた状態に注意する
- 状態
- テスト観点整理での状態遷移図
- システム設計者が作る状態遷移図と、テスト担当者が作る状態遷移図は、違うものになると思う
- テストの目的によって状態遷移図を作り直すのはアリだと思う
- できるだけシンプルな状態遷移図でまとめる
- 状態遷移表
- 状態とイベントの関係性の再整理を行う
- 状態遷移図に抜けがあることに気がついた場合は状態遷移図も修正する
- 斜線とハイフン、角田さんのスタイル
- 演習
- 状態遷移テストとは
- 状態遷移図・表をもとにテストケースを作成するテスト技法
- 状態とイベントのテスト
- 状態遷移表をベースに、テストケースを作成する
- 連続した遷移の確認は状態遷移図をベースにケースを作成
- 開始疑似状態から終了状態までを１テストケースとすることができる
- Nスイッチカバレッジ
- ループする状態遷移
- 繰り返し状態が遷移できることも確認する
- メモリ領域解法漏れ
- メモリのアクセス違反
- 配列のインデックスオーバー
- 繰り返し状態が遷移できることも確認する
- 演習
2日目に向けた復習と予習
明日のワークについてのヒント・・・があったのですが、明日のワークはかなりハードになるみたいです。
グループ毎に成果物を作るところまでいくので、ちょっと頑張らないといけませんね・・・。
まとめ
以上、簡単ですが当日のメモとレポートでした。
明日もがんばりまーす。