JaSST'21 Tohoku 参加報告
テストQAこんにちは！プロダクトマネジメント部クオリティマネジメントグループの芝山です。
今回、2021年5月28日に開催された JaSST'21 Tohoku に参加してきました。
私はMoTに2021年5月に入社したばかりで、今まで約7年QAエンジニアをやっていますが、JaSSTへ参加したのは今回が初めてです。
初めて参加してみた視点をみなさまに共有できればと思います。
JaSST概要
NPO法人ソフトウェアテスト技術振興会(ASTER)が主催する日本最大のソフトウェアテストのシンポジウムです。
JaSSTは日本全国8箇所で開催されていますが、その中でもJaSST Tohokuは、近年参加者全員で一つのテスト開発手法をテーマに丸一日ワークショップを行う特徴があるようです。
ゆもつよメソッド概要
JaSST'21 Tohokuのメインコンテンツであるゆもつよメソッドは 湯本さん が考案したテスト開発プロセスです。
今回はテスト分析の工程に着目した内容となっていました。
JaSST当日の流れ
今回のJaSST'21 Tohokuは、ZoomとDiscordを使ってオンラインで開催されました。
・オンラインワーク参加者(チームA,チームB)：各工程でワークを実施
・湯本さん：ワーク参加者へアドバイス・Discordでの質問の回答
・一般参加者：ワークの様子や湯本さんのアドバイスを見学・Discordで湯本さんとの質問のやりとりや参加者間の交流
私は一般参加者として参加しましたが、Zoomでただ見るだけではなくDiscordでインタラクティブに他の方の意見を聞いたり質問できたのがとても勉強になりました。
感想
ゆもつよメソッドについて
ゆもつよメソッドについて、特に気づきがあった工程を4つお話しします。
1. モデル図
テスト対象について仕様把握する際、みなさんはどう進めていますか？
私はPRDなどドキュメントを読む、テスト環境ですでに操作できるようであれば操作してみる、などの方法で仕様把握していました。（実際仕様把握の段階で操作できるものが手元にあることは稀なので、前者の方法がほとんどです。）
しかし、ドキュメントを読むだけだと機能間のつながりなどがしっかりわかりきっていない・イメージできていないということがありました。
わかりきっていないのでテスト分析・設計漏れも多々ありました。。
ゆもつよメソッドでは、論理的構造図という汎用的な図を使って整理する方法をとっています。
この論理的構造図を使いこなせるようになるには少し苦戦しそうだな・・と感じました。
ただ、ドキュメントを読むだけではなくて、「自分で手を動かして図にしてみる」という方法はかなり有用です。
使用するツールはなんでもよいので、自分で考えて図を書いてみることで不明点や矛盾点に気づくことができそうですし、個人でも取り入れやすいので今後やってみようと思います。
2.テストカテゴリ
私は今までゆもつよメソッドでの「テストカテゴリ」を「テスト観点」と呼んでいました。
「テスト観点表」など現場で使われている方、多いのではないでしょうか？
なぜゆもつよメソッドでは「テスト観点」という言葉が一度も出てこないのか、ふと気になりDiscordで質問しました。
回答について、詳しくは湯本さんがJaSST終了後にブログにまとめてくださったのでそちらを参照ください。
https://note.com/yumotsuyo/n/n0d661da5b906
回答を簡単にまとめると、「テスト観点は汎用的で抽象化された言葉で、人によって指しているものが異なる」ということでした。
今までなんの疑問も持たずにテスト観点という言葉を使ってきましたが、確かに「テスト観点は何を指しているのかを具体的に説明して」と言われたらなかなか言葉が出てきません。。
テストカテゴリという言葉できちんと定義することで、メンバー間での認識齟齬が起きづらくなるような形になっています。
また、プロダクトごとにマスタが作れればその後のテスト分析や設計で工数は削減しつつ人によって粒度がブレないようにできると思います。
3.起こりうる不具合検討
この工程では仕様項目・テストカテゴリごとに起こりうる不具合検討をしますが、テスト分析の工程でここまで細かく起こりうる不具合を検討すると工数がかなりかかってしまいます。
それにもかかわらずなぜこの工程を取り入れているのかが一番の疑問だったのですが、「テストカテゴリとテストしたいことの認識をメンバー間で合わせる」という目的で取り入れられている工程でした。
2つ目のテストカテゴリにも記載した「テスト観点」という言葉と同じように、整理したテストカテゴリも人によって認識が違うことがあるから、「起こりうる不具合」という具体的な事象を検討することで、確かに認識合わせができそうです。
またテスト分析とは関係ありませんが、起こりうる不具合検討はテスト実行者のスキルアップ的な使い方ができると思います。
稀にゴットハンドと呼ばれるような実行者を見かけますが、私はそうではありませんでした。。
私自身テスト実行が得意ではないと感じていたので、メンバーの教育をするにもどうしたらいいのか悩むことが多かったのですが、「起こりうる不具合検討」は分析や設計をしたことがないメンバーも意見が出しやすく、実行者も含めてワークを実施すれば不具合検知率の向上などのスキルアップにつながると思いました。
4.テスト分析マトリクス
ゆもつよメソッドではテスト分析マトリクスの工程でピポットテーブルを使って集計していたので、ピポットテーブルを使う理由が気になっていました。
項目が表示の確認なのか、機能面の確認なのかで実行工数が変わるので、そのレベルでざっくり分けて項目数をカウントすることは多かったですが、私はただEXCELで表を作ってカウントしていただけでピポットテーブルを使うほどではなかったためです。
メリットはいくつか説明がありましたが、その中でも一番いいなと思ったのは「仕様変更が入った時にどの仕様項目に変更が入ったのかのトレースがとりやすく、テストケースの修正が容易になる」という点でした。
過去にQA期間中に仕様変更が多発する現場も多かったですが、そのときはテストケースの修正漏れがどうしても発生してしまって大変でした。
トレースがとりやすければ修正漏れも比較的少なくなるでしょうし、影響範囲も考慮しやすくなりそうだと思いました。
初めてJaSSTに参加してみて
今までは、この業界に入った時に最初に勉強した少しの知識と、過去の経験・気力・体力でなんとかギリギリ乗り越えている・・という感じでした。
（最初に勉強した知識は忘れてしまったのも多いので、終盤は経験だけで頑張っていたといっても過言ではないです・・）
今回初めてJaSSTに参加してみて、全体を通して得たものは2点あります。
1.自分の認識≠他人の認識を改めて実感した
チームで業務に取り組んでおり、メンバーの経験も様々です。
自分が当たり前と思っていることは当たり前ではないということをしっかり考えて業務を進めたり、コミュニケーションをとっていく必要があると改めて思いました。
2.知っていると思っていたことでも新たな発見があり、知識のアップデートは大事
ゆもつよメソッドの各工程は、全く同じではなくてもなんとなく似たような工程を実施している方は多いのではないでしょうか？
私もJaSSTに参加する前は、「呼び方が違うくらいで似たようなことはやっているな」と思っていたのですが、実際にJaSSTに参加すると上で紹介した、「あの時知っていればよかった・・」と思うような新たな発見がいくつもありました。
知っているからもう学ばなくていいということではなく、知っていることも改めて学ぶ機会を設けてアップデートしていく必要があると思いました。
おわりに
感想に記載した通り、初めてのJaSST参加でたくさんの気付きを得ることができました。
今まで長年QAとして働いてきたのに、経験だけに大きく頼ってしまっていたことはよくなかったです。。
今後は積極的に勉強会にも参加して知識のアップデートをして、MoTの品管の一員として、よいサービスを届けていけるように努力していきます。
湯本さん、JaSST東北実行委員のみなさん、本当にありがとうございました。
そしてMaaS領域を牽引していくMoTにはチャレンジできる環境がたくさんあります。また、入社したばかりの私でも勉強会に参加する機会をくださったように、勉強会参加にとても理解がある職場です。私たちと一緒にチャレンジしてくれる仲間を募集中ですので、ご興味ある方は採用ページからご連絡ください！
▼QAポジションに興味がある方はこちら！
https://hrmos.co/pages/mo-t/jobs/4000000
▼もっとMoTについて知りたい方はこちら！
※引用・参照リンク
JaSST：http://jasst.jp/index.html
湯本さん Note：https://note.com/yumotsuyo