WACATE 2019 冬に行ってきましたその1 の続きです

セッション2: 物語を想像して問いを立ててみよう

資料
- スライド
- ワークショップでの体験や学びで、現実世界の悩み事を解決してみよう＠WACATE2019冬の分科会でのお話
「私はある大きな物を想像しています。今からそれを皆さんで当ててみてください。
ただし、私は "はい" か "いいえ" しか答えられません」
というお題から始まったこちらのセッション。
- これは 「物語を想像」 して 「問いを立てる」 というアクションを体感するものです。

「問い」って何だろう

「なんで？」「どうして？」 は問いなのか
- 「なんで (私の言う通りにしないんだ) ？」
- 「こないだ説明しませんでしたっけ？ (ちゃんとやってくださいよ)」
- こうすると「問い」は 凶器のような指示 に変わる
他にも……
- 「どうしたの？」という問いかけに「すみません」と答えてしまう
- こんな感じの前に進まない会話、よくありますね
そのモヤモヤ、問いをうまく使えたら乗り越えられるかも！

こうして解決する

例) 環境が変わって自分の意見をうまく出せない、という悩み相談
- 遠慮なのか言語化できないのか
- 自信がないのか
- 対立が怖いのか
- 自分の立場が変わったからなのか
「環境が変わった」と「意見が出せない」の間に何があるのか考える
- まず2択にしてみる
- その2択に対する答えが追加情報になる。そこから更に問いを立ててみる。
問いを立てると事実が残る
- 事実と事実の間にある物語を考えてみよう

ワーク1

スライド　53〜77ページ
冒頭のような「はい」か「いいえ」で答えられる問いを立てて、相手が考えているお題を当ててみよう
- 質問は5回まで
  - どのように問いを立てれば有効な絞り込みができるかを考える

ワークをやってみて……物語、ありましたね？

相手の知らない言葉で質問してしまった
相手によって意味が違っていた
自分と同じ答えのはずがないというバイアスがあった

ワーク2

スライド　81〜97ページ
「100件中50件しかテストが終わらなかった」という報告に対して、なぜ終わらなかったのか「物語」を考えてみよう
- 88ページの「事実」を付箋に書いてみて、付箋と付箋の間にどんな物語が隠れているか想像する
考えた物語をチームで共有してみる

まとめ

全体的に以下のような流れで「物語」を想像して「問い」を立てます。

観察
階層、グルーピング、抽象と具体
物語を構築していく
問いを立てる点を決める
問い方を決めて問う (文言、ふるまい、手段など)

実際はそれぞれのステップを行きつ戻りつしながら紡いでいきます。

応用範囲は無限大！

1on1
問題分析、改善活動
探索的テスト、仕様確認
- 狙って狭めて、というあたりが探索的テストに似ている

感想

caori_t さんと初めてお会いしたのは夏のテスト酒場なのですが、
これまでなぜcaori_tさんが ゆるぱし という名前でソフトウェアテストの学びの場でファシリテートに力を入れているのか、そういえばあまりちゃんと聞いたことがありませんでした。
そして今回のセッションでやっとその意図が少し見えてきたような気がします。

QA は Quality Assurance の略であって決して Q&A というわけではないのだけれど(笑)、
自身との対話で、またはプロジェクトメンバーとの間で「問いを立てて物語を紡いでいく」力が特に必要となるポジションではないでしょうか。

セッション3: 形式手法って何だろう

スライド
参考
- ”形式的検証”と”組み合わせ爆発”から学ぶ入力バリデーション
- いまさら聞けない形式手法入門

形式手法とは

仕様を記述、検証する手法
数論理学で 厳密に定められた文法 で記述することで、自然言語(日本語とか)のような冗長さと曖昧さを少なくした仕様が作成できるというもの
- なるほど、「xは3より大きい」と書くよりも「x > 3」とした方が断然簡潔で伝わりやすいわけです。
ではプログラミング言語を使用すればいいのでは？
- プログラミング言語にはプログラミング言語ならではの不確実性がある
  - 配列から特定のデータのみ取り出したい場合、多くのプログラミング言語ではループ処理が使われる
  - このループ処理中に欠陥が混入する可能性が出てくる
  - 結局その処理で何がしたかったのかがコードから読み取りづらい

仕様の検証方法

正当性検証 : Verification
- 開発した製品が仕様と合致しているか評価する
妥当性検証 : Validation
- 要求に対して仕様が妥当なものか評価する
- 通常なら受入テストのフェーズで行われるが、形式手法なら設計段階での確認も可能になる
形式検証
- 定理証明
  - 仕様に論理的な破綻が無いか検証する
    - X機能で A→B なら、Y機能でも A→B であるべき
- モデル検査
  - 実装されたモデルがとりうる状態を全網羅して検証を行う
  - 並行処理の仕様の検証に有効

形式手法で書いてみよう！

今回はVDM++の基本的なところを学びました

要求を読み込み、振る舞いを分析する
モデルに起こす
形式手法で記述
- クラス定義
  - クラスの中に以下の定義が含まれている
  - 型定義 : データの概念
  - インスタンス変数定義 : クラスで用いる変数
  - 操作定義 : クラス内の変数の操作
    - 陰定義 (事前条件 / 事後条件)
    - 陽定義 (実際の処理で行う操作の仕様)
検証
- 整合性特性検査、仕様齟齬チェック
  - 型・構文
  - 部分演算子
  - 不変条件
- ツールでのテスト実行
  - VDMTools

ワーク

スライド　65〜73ページ
サンプルコードの穴埋め問題です

大事なこと

何が複雑なのか、どこで形式手法を用いたいのかを考える
どのように検証するか
- 並行処理がやりたい？
- 仕様の整合性の検証？

感想

プログラミングのように見えてプログラミングのようではない、という点で当日は困惑していました。
Twitterで弱音を吐いていたら「少しずつ馴染んでいけばいいから大丈夫だよ！」とフォロワーさんに励ましてもらったので、同じく心が折れかけた方、元気出していきましょう。
今改めて資料を読み返すとシビれますね。不確実性への、人間の飽くなき挑戦のように感じました。

夜の分科会: モブで探索的テストをやってみよう

夕食後、いくつかのテーマでグループに分かれてワークをします。
私が参加したのは halspring さんのグループ。

この分科会のために Twitter風のサイトを自作したのだそう。すごい。

探索的テストではテストエンジニアがどれだけ野生に還れたか が大事だとテスコンチュートリアルでにしさんがおっしゃっていましたが、
まさにその時は自分含め参加者全員 野獣の目をしていたので 、オーナーは相当怖かっただろうと思います。ごめんなさい。
白熱すると収集がつかなくなるので、モブテストをする場合は冷静と情熱の間が良さそうです。

やっとここまでで 1日目だよ！！！！！！

その3 書きました