相手の気持ちを考えるテスト設計の伝え方｜JaSST'23 Tokyo参加レポート
はじめに
こんにちは。SHIFTでアジャイルQAエンジニアをやっているもりもとです。
2023年3月9日(木)～10日(金)開催されたJaSST’23Tokyoに参加してきました！
少し時間が空いてしまいましたが、特に印象に残っていた2つのセッション説明とそこから得た学びや感想などをひよこ（QAエンジニアなりたて）目線で書いていきたいと思います🐣
※セッション資料はこちら
執筆者プロフィール：もりもと
2023年1月にSHIFTに入社。
ブログ冒頭に小話を入れたいけど面白い話が浮かばず何も書けなくなるタイプ。
JaSSTについて
ソフトウェア業界全体のテスト技術力の向上と普及を目指して、NPO法人ソフトウェアテスト技術振興協会が全国各地で開催するソフトウェアテストシンポジウムです。 （参考：https://www.jasst.jp/）
結合テストの自動化にQAはどうかかわっていったのか(講演者：永田 敦)
結合テストの自動化の課題
QAの悩み：コードの構造理解、開発スキル、知識が不足していると思い踏み込めず開発担当者に任せきりになりがち
開発担当者の悩み：何をどうテストしたらよいか、どこまでテストすればよいかなど、テストの抜け漏れ、やりすぎがないか不安
開発担当者とQAの言葉の齟齬をなくすため、テスト仕様書にある「正しく表示できること」などの曖昧な表現を「～が～と表示されている」といったように明確にする
テスト観点の意図を伝えるため、一つ一つのケースに対しなぜ必要なのか、何を確認しているのかなど言語化を行った
そのうえでQAと開発担当者がテスト設計の議論を行ったところ、その観点で確認を行いたいのであればバックエンド側でテストを行った方がよいのでは？などの会話が生まれより適切な場所、レベルでテストを行うことができるようになった
結果テストの目的が明確になり自動化の設計がしやすくなる、実装がしやすくなり、実行も早くなった
Excelのテスト仕様書を見ながら開発担当者が開発を行うのは仕様書が見づらく、開発担当者も見慣れていなかったため、テストコード上にテスト手順を直接記載し、開発担当者がテストコードをつけたしていくようにしてみた
このテスト手順を行いたい場合はこういう風に書けばいいと学習し、QAがテストコードをかけるようになった
その結果、QAの垣根を越えて広く貢献できるようになった
ここが大事🐣
開発担当者の悩み、不安を考えた
それを解消するために曖昧表現の明確にしたり、テストコード上にテスト手順を直接記載するなどのアクションを起こした
感想
これすごく面白いと思いました！
自動化に対してのQA活動に限らず、私含め、QAってもっとこのプロダクトをより良くすることはできないか、もっと貢献できることはないかって考えている方が多いのではないかと思います。
そんな中このような貢献の仕方もあると知れたのは視野を広げるきっかけになりました！
個人的にチームをより良くしようとアクションを起こすには相互理解が必要で、相互理解をするには会話を行い関係性の構築が必要、そのためには歩み寄りが必要と考えています。
このチームはその部分がしっかりとできていたからこそ行えたこともあるのかなと思い、そこについてももっと聞きたいなと思いました！
テストの設計意図を届けよう2023～テストしたいことを、よりスマートに伝えるための第一歩 - テスト設計コンテストU-30セッション –(井芹 久美子、坂 静香)
※内容が濃かったので前半のみをご紹介させていただきます。
仕様をなぞったテストから脱却するためのヒント 自分たちができることを探す（暗黙的のうちに行っている活動を明確に定義する）
仕様書を読んだときのつぶやきや思い付きのメモ
メール、チャット、口頭でのやり取り
→普段行っているテストについて、テスト目的を改めて定義し、認識を合わせてみる
テストケースのパラメーターを抽象化する
抽象化することで足りないものを追加しやすくなったり、複数のテストで使えるようになる
テストケースをグループ分けして、観点を探る
イベントに対して状態遷移するか確認、設定値の通りにふるまうことを確認などグループに分けを行う
イベントに対して状態遷移するか確認であればそのグループに対してほかにどんなイベントがあるのか、設定値の通りにふるまうことを確認であれば設定を変えた時のふるまいについても確認が必要そうなどテストケースを増やしていくことができる
テスト設計成果物の妥当性を確認する
Why+αの問いかけをして検証する
テスト実行工数が少ない
どのくらい少ないか？
なぜ少ないのか
用意したテストを全て実行できない
すべて実行できなくてもよい根拠があるのか？
優先度の高いテストから、時間の許す限り実行していく
優先度はどうやって決めているのか？
この結果どうなるのか？
問いかけを受けて直し、さらに+αの問いかけをして改善する
納期の都合でテストの工数が2日しか確保できない
用意したテストは3日分ある
1日分のテストを削減する必要がある
優先度の低い低い画面表示に関するテストを実施しない
この結果どうなるのか？
テスト実施以外で対策をとるとしたら何があるだろうか？
画面表示に関するテストの優先順位が低い理由は？
このように問いかけと改善を繰り返し、そこからステークホルダーに知らせる、協力してもらうなど、様々な解決案を考えてみる
こうすることで今よりも説明しやすく、納得してもらえる伝え方ができるようになる
ここが大事🐣
相手のなぜを先に考え抽象的な内容に根拠をつける
今回の例ではテスト実行工数が少ないということにフィーチャーしているが、作成したテスト設計書についても同様にそのテストはなぜ必要/不要なのか、相手に伝える根拠をつけることができる
テストケースの抽象化を行うことで根拠をだす手助けになる
感想
本セッションを聞きながら、私自身テスト設計を行うとき仕様書に書かれている内容の確認ベースに設計していることが多く、仕様書に記載されていない内容については思い付きで記載しているところがあるなと感じました。
この思い付きの部分を、テストケースの抽象化やテストケースをグループ分けして観点を探すなどすることで、仕様書ベースの設計書から仕様外の観点に気がつくことができるようになりそうだなと思いました。
また、抽象化を続けていくことでナレッジも貯まり、それを横展開していろいろな場面で活用することで抜け漏れのない設計書に一歩近づけそうな気がしました！
成果物の妥当性を伝える部分について、いわゆるなぜなぜ分析ですが、これすごく大事ですよね！
私も自分の中でふんわりとした答えがあるときはその部分を明文化せずにしてしまうことはあり、そのふんわりとした答えにさらになぜをぶつけられると返せなくなるなってしまう、といった経験あります。
できて終わりではなく、一度立ち止まってできたものに対してセルフでなぜを問いかけブラッシュアップさせていくことを心がけたいですね！
後半ではWhyに答えられない、簡潔に説明できないといったお悩みへの解決案をお話ししてくれています！
個人的には定期的に見直したいセッションだなと思っているので、皆さんもぜひご一読を！！
まとめ
他にもいろいろなセッションを聞いたのですが、まだまだひよっこQAには理解できないことも多くありました。
それでも視野が広がるきっかけになったり、より良いQA活動の参考になる内容が聞けるいい機会だなと思いました！
また、インプットだけではなく学んだことを感想ベースでもアウトプットせねばと思いブログを執筆いたしましたが想像以上に大変だということも学びました。。
最後までお読みいただきありがとうございました！ よろしければスキ♡とSHIFT Group技術ブログのフォローの方もよろしくお願い致します！！
SHIFTの強さと面白さを多方面から公開！
SHIFTのアジャイルQAマガジン
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/