【初心者向け】JaSST Tokyo（ソフトウェアテストシンポジウム）で学んだ、QAチームで行うテスト運用と自動化のエッセンス３選
今年の3月10日、11日で JaSST'22 Tokyo （ソフトウェアテストシンポジウム2022東京）というイベントに参加しました！ちなみにこちらはオンラインでした。２日間に及び、とても充実した内容だったので、だいぶ前のイベントですが記事にしました。
JaSSTソフトウェアテストシンポジウム-JaSST'22 Tokyo
JaSSTとは
JaSSTってなに？という方も多いかもしれません。
簡単にいうと全国各地で行われる「ソフトウェアテスト」にテーマを絞ったイベントです。
ソフトウェアテスト技術振興協会が中心となって、日本各地でシンポジウムを開いており、テストに関わるエンジニアやテストの自動化ツールに携わる複数の会社さんが参加されるようです。開催地は札幌・関西・東北など複数ありますが、今回のJaSST Tokyoは年に１度の日本国内最大のソフトウェアテストシンポジウムでした。
前提
私がシンポジウムに参加した目的、解決したかったこと
私自身、仕事をしながらなんとなく「これ知りたいけどどこで学べるんだろ？」とモヤっとした疑問を感じていたことがありました。具体的には、
🤔 他社のQAエンジニアって普段何を意識して仕事をしているのだろう？
🤔 一般的に、チームでテストを行う際の課題はなんだろう？
🤔 テストを自動化したい時は何に注意したらいいのだろう？
といったもやみでした。
これは、組織とプロダクトが大きくなっていく過程で、チームとタスクの運用を運用する中で、今後どんな障害があり、何に気をつけていったらよいかを予測したい、という気持ちから生まれた疑問でした。
QAEチームもメンバーが少ない上に自分自身も経験がまだ浅すぎる状態（QAEになって４ヶ月目..）だったので、大まかに大量の情報収集をしたいと思い、たくさんの登壇者が集まる大きなイベントに参加してみました。
この記事の対象となる人
🐤 QAエンジニアの経験が浅い人
🐤 複数人のチームでテストを運用を始めたいと思っている人
🐤 テストの自動化を始めたいと思っている人
こんな人にはちょっとだけ参考になるかもしれません。
はじめに：そもそもQAの仕事とは？
例えばですが、弊社のチームが普段取り組んでいることは
- プロジェクトの際にQAチームの参加・不参加を他チームと相談する
- テスト実施のプランを立てる
- テストケースを書く
- テストケースのレビュー
- テストの自動化を一部考慮して、効率的に回せるように仕組み化する
- テスト結果に基づいて、バグ報告をする
・・・・などなど・・・・
ついでにこちら、他社のQAエンジニアさんが書かれたものですが、とても参考になる記事を社内の上司から共有頂いたので、おすすめします👇QAの仕事をより深堀って書いてあります。
あくまで個人的な考えですが、QA（品質保証）の定義ってすごく広いと思っています。
例えば、プロダクトの１機能がきちんと動くこと、バグがないことだけでなく、エンジニアが最大限のアウトプットを出しつつ納期に間に合うようにタスク調整するOps的役割だったり、顧客が満足に製品を使えるように、カスタマーサクセスから受けた要望を満たせるようにエンジニア側と話しあったり、バグの数や顧客からのフィードバックを分析してよりよいプロダクトにアップデートして、品質全体が上がっていくことを数字で示したり。
自分はまだQAのキャリアは一年未満なので「それ違うでしょ」「全然分かってない」とかいう感想を持たれる方もいるかもしれません😓。また、上記を完全にマスターするのはほぼキャパシティ的にかなり厳しいと思うので、理想論になっているかもしれません。
でも、それくらいQAができることの世界は幅広いのではないか？と思っています。
幅広いからこそ方向性に迷うつらみ
幅広いということは選択肢が多いということ。人は選択肢が多いほど選べないと言われています。（ジャムの法則というらしい。）
選択のパラドックス（多すぎると選べない）：行動経済学とデザイン05｜ジマタロ｜note
そこで、冒頭で書いた自身の
❗️QAエンジニアは普段何を考えてテストをするのか
❗️チームで行うテスト運用
❗️自動化する際のポイント
という悩みを解決するヒントになりそうなエッセンスについて、シンポジウムで学んだことを３つ、まとめてみました。
💡エッセンス１：プロダクトにとって適切かつ、チームにとって扱いやすいツールを選定する
何をもって適切かは会社のプロダクトやチームの方針によると思うのですが、テストをより効率的に行うためにさまざまなツールがあります。テストをするだけではなく、それらのツールを利用してテスト自体を管理することも、QAエンジニアが意識すること、ということを学びました。例として、以下のようなツールがあります。
便利なツールたち
（１）自動化ツール
自動化ツールに関しては、
Autify
Ranorex
などが有名でしょうか。ちなみに弊社iCAREでは、UI選択型のmablというツールを使っています。自動化ツールにはどうやらたくさんの種類があるようです。👇下の記事は、シンポジウムの内容とは無関係ですが、知識としてわかりやすかったので紹介します。
🙄. 。(この中から何を選べばいいんだ....)
といった迷いが生じると思います。
その場合、テストスクリプトが修正しやすい（メンテナンスがしやすい）ものを選ぶと良いとのことです。これもアプリケーションにあったもの、テストしたいこと、チームにとって合っているものを選定すればよいのでは、という解釈です。
（２）テスト管理ツール
エクセル形式でテストケースを管理する方法もありますが、楽に、手早く、かつ分析までやってくれるツールもあります。
シンポジウムで紹介されていたのは、
TestRail
Quality Forward
です。テストを管理するってナニ？、と思うかもしれません。一言で言うと、テスト結果をまとめる作業を減らすもの、らしい。実際に使ったことがないので正確なことは書けないのですが、具体的にやってくれることは、
・テストの結果を集計、比較、分析してくれる。
・画像や値などのテストデータを登録でき、テストに関わる情報を一元管理できる
・テスト全体のサマリーや進捗、メンバーのアサイン負荷などを提示してくれる
などなどがあるそう。使いこなせるかわからないけど便利そう。。！
親和性が高いツールを組み合わせる
自動化ツール単体でも、結果の推移などを自動で表示してくれる機能はあるのですが、テスト管理ツールを組み合わせることでより便利にテストを運用することができます。
例えばTestRailであれば、代表的な課題管理ツールJIRAと連携して、テスト結果の分析から得られた課題を登録することができるようです。そんなことまでできるのか.....すごい、といった感想。
一歩進んでテストを楽にしたい、かつその結果を楽に可視化したい、というチームには向いているのかもしれません。ここまでできたら、自動化できなくて手動で行うべきテストに、時間と労力を十分に割くことができそうですよね。🧐 わーい。
💡エッセンス２：複数人でも管理しやすいテストを考える
前項にも関連する内容かもしれませんが、アプリケーションが成長するとテストケース数も増えて、管理が大変になります。またチームメンバーも増えることで誰がどこまで何を管理しているか混乱することもあるのではないでしょうか？
最初にできそうなこと
チームやテストが複雑になる場合、最初に以下のことを取り組むとよさそうです。
（１）１つのテストケースを単純にする
単純にすることで、誰もがわかりやすく、メンテナンスがしやすいテストになる。
（２）変化に強いオブジェクトを作成する
テスト内容に若干の変化があったとしても、メンテナンスコストが低いテストを作ることで、アプリケーションの成長に対応しやすくなる。
複数箇所で使用するテストのデータはテスト管理ツールなどで一元管理すると楽。
（４）テストの「目的」別で簡単に選定できるようにする
緊急用の最低限のテストとか、ユーザーの受け入れテストなど、目的に絞ったテストを整備することで、よりアプリケーションが成長し、障害や新機能リリース時などでテストしたい状況が異なる時に素早く対応することができる。
テスト関連でその他考えること
テストケース作成だけでなく、テストをチームで運用していくためには以下のことも大切であると感じました。
・仕様は開発と共に更新していく
・チームで品質の定義を考えてみよう
・誰がどこの品質を担保するか明確にしてみよう
仕様についてまだまだ言及できる立場ではないので今回の記事では割愛しますが、２・３個目についてはチームメンバーが揃った段階で取り組むと良いのではないか、と思います。これらが大切だと思った理由は、
チームで目指す「品質」の定義が明確になり、誰がどこの品質を守るかが整理できるから、です。特に、絵やポストイットを使って図にして可視化すると、楽しくかつわかりやすく理解できるみたいですよ。
前提でも書いた通り、品質という意味は幅広いので、このようにチームで運用する場合は整理することで、チームが目指すところ
・何を守り
・そのために何をテストしたいのか
について共通認識を得ることができます。
そこで初めて、実践するTO DOとして、前項に書いた適切なテストツールの選定をすることにつながるのだと思います。
💡エッセンス３：テストを自動化する時の注意点
テスト自動化研究会という団体があり、そこのHPで「テスト自動化の８原則」
というポイントがまとめられています。
こちら見るとすごくわかりやすくまとめられているのですが、この原則の中でもシンポジウムで取り上げられていて、個人的に印象的だったものを抜粋。
・闇雲に自動化するのは危険
「テストを自動化するほど楽になるのではないか？」と一見思いがちです。私もQAを始めたばかりの頃はなんとなくそう思っていました。しかし思いつくままに、なんとなく大事そうなテストケースから片っ端から自動化していくのは良くないらしい。
理由としては、
テストメンテナンスの手間が大きくなる、実行時間が伸びる（手動でやってしまった方が早い）という事が生じてしまうため。
本末転倒・・・・
自動化に向いてないテスト？
ではどんなテストは自動化を避けるべきなのでしょうか？
・探索的テストのような明確な仕様がない
・手順が複雑で自動化するのに手間がかかりすぎる
・結果に人の判断を必要とする
・新機能のため、まずは手動で実施して結果を確認したい
などといったもの。確かに自動化には向いてなさそう。。。。。（としか言えない泣）挙げてみると、確かに手動にしかできない部分な気がします。
・自動化の初期設計で自動・手動を効果的に組み合わせよう
上記のような事案になるのを防ぐために、テストの自動化を考える初期段階から設計することが大事。自動化するテストにも「向き・不向き」があり、それを最初の段階で整理すると、余計な自動テストを作ってしまって混乱したり、無意味な作業をするコストを削ることができます。
自動テスト、手動テストの良いところ・得意なところをそれぞれ理解して組み合わせるテストの設計をすることで、より効果的なテストを行うことができます！
まとめ
前提が長くなってしまったかもしれませんが、初心者QAエンジニアにとって共感できるところはあるのではないかな〜と思い、この記事を書きました。
QAエンジニアはエンジニアの比率の中でも少なくてニッチな立場なので、他のチームから「QAって一体何してるんだ？と思われてるかも・・・」なんていう気がしたり、社内にもメンバーが少ないしなかなか情報を集められない、という困りごともあるのでは。 この記事では、JaSSTのようなイベントがあること、そこから似たような課題感を感じている人がいることを知ってもらえたら嬉しいです。
また課題に対しての方向性を考えるためのヒントになったら幸いです。
自動化についてもまだまだ弊社でも進めている初段階でして、詳しいことが書けないのでちょっと悔しいです。これからも勉強していきたいと思います！
では👋
