JaSST’24 Tohokuに参加したよ
こんにちは。ささきです。
2024年5月31日に開催されたJaSSTソフトウェアテストシンポジウム-JaSST’24 Tohokuに参加してきました。
きっかけは、スクラムフェス新潟で
「JaSST東北はワークショップで楽しいから参加した方がいいよ！！」
と教えていただいたことでした。
ということで、スクラムフェス新潟に引き続き、印象に残ったことをまとめていこうと思います。
1.現地に赴いて
スクラムフェスではワークショップ参加は1枠のみでしたが、JaSST東北はワークショップが基本のカンファレンスで、1日中ワークショップを行いました。
ちなみに場所は仙台だったので、岩手民からするとアクセスが良くなじみのある地域でとても行きやすかったです。
2.参加の感想/学び
ここからは、参加した感想や学びを振り返りたいと思います。
１基調講演：説明できるテストをつくるためにできることを考える
日々テスト業務の中でテストを作っています。が、作ったテストの説明ができるのだろうか？
基調講演では、説明できるテストをつくるためにできることを
頭と手を動かしながらお話しいただきました。
印象に残ったことをベースにつらつらと記載します。
★想定されるバグが想定できているのか？
テスト原則のひとつに欠陥の偏在があります。偏在していると想定すると、不具合や欠陥が潜んでいそうなところを想定できます。が
上手く想定できているのだろうか…？
そんな時に以下のことを気を付けると良いとのこと
〇3Hの確認（変化、はじめて、久しぶり）
欠陥が潜んでいそうな想定をするべく役立つのが、開発者の不安です。
どんなところが不安？と聞くのも良いですが
変化：手順や方法に変更された作業
はじめて：初めて行う作業
ひさしぶり：久しぶりに行う作業
これらの作業においては、普段に比べミスや失敗が発生しやすいです。
３Hを聞くことで、漠然とした不安から一歩進んだ詳細な不安を聞けるかもしれません。
〇自分の範囲外でも違和感は拾っていく
チームで動いているうえで、何もかもを背負って作業するのは非現実的でしょう。しかし、自分の範囲外でも気になった違和感や疑問については、他のチームが気づいていないお宝情報かもしれません。
自分の範囲外の違和感かもしれませんが気になってしまったら範囲を気にし過ぎず動いていこうと思います。
★うまくバグが考えられない時の乗り越え方
テスト対象の理解が不十分でうまくバグが考えれないこともあります。
不十分だから、仕様書や設計書を読んで理解を深めよう！と動くと思いますが、それでも理解ができないなぁ...という時は
得た情報を整理する必要があります。そこで、モデルを描いてみます。
モデルを描くとは
得た情報を整理することができます。
モデルを描くことで、全体像が把握でき、着眼点に沿って理解や検討がしやすくなります。
上記画像のようなモデル以外にも
テスト対象を⼊⼒調整、貯蔵といった 要素で分解した、ゆもつよメソッドの 論理的機能構造など モデルを描く際はテストで使われる考え方を参考にできます。
今回ワークとして作成したモデルの手順は以下です。
1 着眼点を決める （シンプルに小さく始める）
2 インプット情報をまとめる
3 要点の調整 （ここで様々な人へ確認が走る）
4 関係性をまとめる
モデルを描くワークをした感想は、1着眼点を決めるが難しいなと思いました。書いている途中で脱線した要素を書いてしまっていたり着眼点からズレた情報を集めてしまったりとワーク中は適切な着眼点がわからずでした。
4の要素をまとめる際に要素の不足に気が付き再度情報収集したり、と行き来することも多いですが、可視化することで開発とのコミュニケーションが増え不具合を考える要素を整理できるのかなと思います。
ワーク中ふとこれってQAが用意するもの？とも思いましたが、すでにある場合でも「テスト」として着眼点があっているかどうか確認しなければいけないので「着眼点」についてはどんな時も考えるのです。
★思いつきの言語化ができているのか
そういやこの機能○○に影響あるのではないだろうか？テスト観点追加だーー！！！
よくやります。
もちろん、今までの経験や分析手法、製品知識などから思いついたテスト観点や、ふとした時にひらめいたテスト観点もだめだとは思いません。それに、担当製品は特に機能が多く経験がなによりの力だと思います。
しかし、その思いついた観点が説明できないと、せっかくの積み上げた経験もただの勘となり説明のできないテストになってしまいます。
思いつきはダメではないですが、テストに対し意図や設計のよりどころを
理解し説明できるようにしていきましょう。
ランチタイム
2 同値分割・境界値分析について
親の顔より見た技法。
ワークショップ中、幾度となく
「同値のテストケースを書け」
と書いてあるのに、境界値のテストケースを書いていました。
日本語しっかり読んでから問題を解きましょう。と学生時代に先生に言われていたことを思い出しました。
同値分割・境界値分析は
不足なく、重複なく
3 クラシフィケーションツリー技法
図（ツリー）とデシジョンテーブルを組み合わせたような図を作るワークショップを行いました。
クラシフィケーションツリーとは
ブラックボックステスト技法のひとつで、クラシフィケーションツリーを使用してテスト設計を行う技法です。
改めて説明を見るとデシジョンテーブルの作成は技法外のことでした。
なるほど。
技法を使用するメリット
・組み合わせテストを整理しながら作れる
・理解しやすいのでレビュー向き
技法を使うタイミング
・何をどう組み合わせればいいかわからない時
クラシフィケーションツリーの使いどころは、わかっていない時で
テストケースがわかっているときは向いていないそうです。
クラシフィケーションツリーについて、自身の作業内でも似たようなことはやっているのに、何この初めて感...という感覚を持ちました。
他の参加者との会話の中で、コミュニケーションツールとして使うのが良いのではないかという解釈を聞き少し理解が深まった気がします。
作るうちに疑問や会話が生まれ、抜け漏れや説明が不足している点が洗い出せる。
その結果、もれなく不足の無いデシジョンテーブルが完成するのではと。
一つのクラシフィケーションツリーを作るのは結構な時間を要します。
すべてのテスト観点に対しては現実的ではないですが、何かしらでチームで実際に試してみます。
3.ぼっち回避の懇親会
知り合いがいない状態での参加でしたが、いろいろな方のお力添えによりとても楽しい時間を過ごすことができました。
気にかけてくださった方、急な突撃をしたのに会話してくださった方々、
ありがとうございました。
4.最後に
自分はテストをするにあたり、テスト観点作成→テストケース作成→実施という流れでテストしているのですが
テスト観点って作成してるのってなんでだっけ…？
説明できるテストじゃなくて、機能を書き起こしているだけじゃない…？
とJaSST東北に参加してから自身の作業にもやもやが生まれました。
なぜ？なぜ？と考えることはやめず、どこか切り出して改善できないか
少しずつ順序立ててテスト業務をよりよくしていけたらと思います。
ところで、自担当製品以外のテスト設計ってなかなか見る機会がありませんでした。みんなどんなテスト設計してるんだろう…と思ったら講義内で紹介していただけました。
テスト設計コンテスト (aster.or.jp)
参考にしてみようと思います！
とても学びの多い１日になりました。ありがとうございました！
