JaSST'20 Kansaiに参加してきました！

9/12(土)にオンラインで行われたJaSSTソフトウェアテストシンポジウム-JaSST'20 Kansaiに参加したので、気になったセッションをレポートします！　関西は初参加！
今回のテーマは「テストについての分解・再構築」です。
本文中にリンク貼った書籍や資料は、当日のTwitterで教えていただきました。
当日のまとめはこちら
JaSST'20 Kansaiまとめ（オンライン） - Togetter

「テストの視点でシステムを分析する」

見えないものと取っ組み合う

望月 信昭（ウェブレッジ）さん
＜概要＞
テストベース分析で困りがちなこと

• ソフトウェアは目に見えない　→　何となく理解した感じで作業を進めてしまう

対象をテスト視点で理解する

• モデル化してみる（図を描く）
• 記法とかがハードル高いと感じる人は「テスト技法を使って問題を解いてみる」と考えてみるのも手（対象を理解するためのツール）
• ただし対象に対してどの技法を使うのが適切かを選ぶのもハードル高い
• →ちょっと使ってみて考える。失敗してもこの対象にはこの技法は会わないという学びをゲット

対象の振る舞いを理解して、見えないものを見えるようにすることができる

テストの視点でシステムを分析する

堀川 透陽（ベリサーブ）さん
＜概要＞
テストのシフトレフト
前提

• ビジネスモデルキャンバス（ビジネスゴールを導くためのツール）

顧客・tesuto 対象をビジネス視点で書き出していく

• PEST分析　仮想課題から気付きを得る

外部環境の変化から生まれる要求、見直される要求があるのではないか

USDM（要求仕様記述手法）による要求と仕様の再構築
言葉にする→言葉にかけないものを作ってはいけない
メリット

• 要求と背景が明確になることで、テストのゴールも明確化される
• 合意形成しながら進めることで、仕様の妥当性があがる

デメリット

• 作成に熟練を要する（作り直し）
• 合意形成のための工夫が必要

USDM作成→テスト設計HYST法のFV表、FL表へ接続できる

＜講演中で触れられてたことの参考文献など＞
USDM参考書籍

[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?

テキストマイニングによるテスト分析、リスクベースドテストへの応用の詳しい事例
https://www.veriserve.co.jp/asset/pdf/tim-verinavi-vol19.pdf

テストの視点でシステムを分析する　～アジャイル開発を例に

江添 智之（バルテス）さん

• 仕様化以前の状態で品質を考える
• 何ができればOKか　を上流工程から考える
• エピック→スプリントに入りきらないユーザーストーリー → 受け入れ条件を考えるとユーザーストーリ―に分割できる
• 要求の「完成」の定義と受け入れ条件で整理する

「スペックアウト」でソースコードを理解しよう

池田 祐一（AFFORDD関西部会）さん

スペックアウトとは

設計書の不足を補うために、ソースコードから必要な設計書を起こす行為
知りたい機能、知りたいこと、必要な調査資料、投入できる時間etcを目的を明確にして取り掛かる
　

スペックアウトの手順例

1. 資料やソースファイルの一覧を用意する
資料、内容、用途などを表にする
2. 関数の一覧を用意する　ファイル名、関数名、説明（目的語と動詞を各）を表にする
3. 変数の一覧を容易　ファイル名、変数名、説明（名詞を書く）

4. データ参照関係を調査する　関数と変数のマトリクスにCRUDのどれを行っているのかをつけていく
5. 知りたい機能の処理構造を調査する　変数名表からあたりを付けて構造図に落とす
6. 必要に応じて処理手順を調査する（複雑なパターンなど）　処理パターンを抽出してPADフローに表現
7. 要求仕様を復元する　コードや構造図を参照しながら、イベントから始まる一連の動作を表現する
8. テスト仕様を作成する
9. テスト結果を記入する

＜講演中で触れられてたことの参考文献など＞

• https://affordd.jp/conference2017/affordd_conference2017_poster1.pdf
• プログラム構造表記法（PAD）

究極のプログラム設計図 PAD解説: 構造化チャートによる設計図法 － 素晴らしいPAD図 － 究極の技シリーズ (計算機屋さんの技)

テクノロジーセッション

「試験に役立つモデリングのススメ」

渡邉 豊幹（サイボウズ）さん
サイボウズさんの米国市場向けの販売管理システム開発チームの話

問題点

• 影響範囲が把握しにくい
• 新規メンバー/他チームへの教育コストが高い

対策

• モデルを作成してみる。文書より図の方が人間には分かりやすい

モデルとして残すもの

• Keeps

- システム全体の構造shisutemuzentainokouzou
- 業務で扱う対象とそれらのつながり
- システムの（ユースケース図、コミュニケーション図）渡されるデータや実行APIを記載

それ以外はTempsとして一時的な資料、メンテナンス等はあまり考えない

結果

• 概要が把握しやすい、俯瞰しやすい
• モニタリング対象の洗い出しやE2Eテスト

「Global QAチームを目指して ～日本とシンガポールの2拠点QAチームを築く上での気づきと大切にしたこと～」

角 尚美（チームスピリット）さん

シンガポールで採用

QAエンジニアの役割定義をアップデート

• コアスキル(ISTQBのFLレベル)
• スペシャリスト(ISTQBのFLレベル＋α)

の2軸で定義

リモートでも2か月で立ち上げ
　開発チーム全体でSG-QAのオンボーディングのサポート

招待講演

「ゆもつよメソッドによるテスト分析の成り立ちと狙い」

湯本 剛（freee / ytte Lab）さん

例：西暦和暦変換アプリのテスト

テスト分析

テスト対象フィーチャ：和暦西暦変換
テスト条件（仕様と期待結果）：西暦の年月日から和暦へ変換した日付を出力する

テスト設計方針
テストケース：この辺で一般的なテスト設計技法を活用

分析と設計について

分析：対象を把握する→分析結果は客観的、誰が見ても分かる
設計：枠組みを考える、アイディアを決定する→設計結果は主観的。人によって答えが異なる

要求分析：システム要求を分析して仕様を作成する

あー、テスト分析だと確かにインプットするものの名前じゃないので分かりにくいのかも。文脈にもよるだろうけど、より正確にはテスト要求分析というと誤解がないのかな

テスト分析では理解したことを以下のように整理する

• 仕様項目の特定と列挙
• 期待結果の特定と列挙
• テストパラメータ列挙（テスト設計時により明確に定義していけばよい）

テストカテゴリー
　テスト条件を見つける際に一貫性のある解釈をするために論理的昨日構造の各要素にテスト対象から見てふさわしい名前付けをしたもの
テストカテゴリと意味づけ

テスト設計
テスト設計方針を決める→テストパラメータ導出方法、同値のサイズ、組み合わせ方法

テスト条件を網羅するためのテストケース設計モデルの選択をする　技法の選択とか

モデル化する：必要なものを取り出し、不要なものを削る

テスト設計の変遷
テストカテゴリーをベースにしたテスト分析の方法

テスト分析手法の概要

• ドキュメントフォーマットと実施順序のルール化/テスト分析マトリクス
• 論理的機能構造→テストカテゴリー
• 仕様項目特定パターン（研究中）

メリット
大きくとらえてテスト対象を網羅しているかが分かりやすい
テストしなければならないことを先に洗いだすことができる
→テスト条件（仕様項目）の段階でテストが十分か、漏れがないか、といった確認が可能になる

ドキュメントフォーマットと実施順序のルール化

複数人でテスト設計するときの記述内容を合わせる
テストカテゴリーは確認箇所を汎用化させたもの

論理的機能構造

テストカテゴリーになるべきものを決めるためのモデル

• メンバ全員が参照モデルを深く理解する必要はない、テストカテゴリに対する認識合わせが最も重要

仕様項目特定パターン

テスト実行時のデータ入出力パターンですべて特定
テスト実行によって呼び出される小機能の結果確認

感想

「自分たちが扱っているシステムやプロダクトで何がしたいか」をどう整理すればよいかを改めて考える機会になりました。
色々な手法があるけど、どうとらえてチームでどう納得するか、というところがミソなんだろうなと思います。
ゆもつよメソッドの話をちゃんと聞いたのは今回が初めてだったんですが、論理的機能構造をどう作っていくかが私の中で落とし込めてないので、そこをもうちょっと深めたいです。

関西は今回が初でしたが、オンラインで開催していただけて自宅から参加でき、移動ゼロで素敵なお話が聞けてありがたかったです！
登壇者、運営の方々、参加者の皆様ありがとうございました！

おまけ：いろんな方から紹介いただいた理解の助けになりそうな資料

• JaSSTで話題になったテスト設計をモデル化してみた - Qiita
• テスト設計をより良くするモデリングと観点分析/ Improve Test Design with Modeling - Speaker Deck