STAR(テスト自動化研究会)主催の「ソフトウェアテスト自動化カンファレンス2022」に登壇してその振り返り|STAC2022
STAR(テスト自動化研究会)主催の「ソフトウェアテスト自動化カンファレンス2022」に登壇してきました
これはウイングアーク Agile and DevOps Transformation Stories のAdvent Calendar 2022、2022年12月20日の投稿です。
去る2022年12月3日、STAR(テスト自動化研究会)主催の「ソフトウェアテスト自動化カンファレンス2022」が開催されました。
きっかけは、今年のふりかえりも兼ねて、わたしが1年間PE*としてどのような活動したかな？と思いまして、ついでに登壇もしてしまおう！ということです。
*注釈
PE：Pipeline Engineer。ウイングアークQAが定めるロールで、一般的にいうSET系の活動を中心としたジョブ。
後日（例年通りであれば2023年1月中）に、youtubeに発表動画はアップロードされます。
合わせてご覧ください。
テスト自動化研究会
テスト自動化研究会 (STAR: Software Testing Automation Research Group Jp) の公式チャンネルです。…
www.youtube.com
また、過去にもウイングアーク１stから登壇しています。
2021年度
2020年度
今回は、2022年度に参加したふりかえりです。
すべては難しいので、いくつかの発表に、わたしの感じたことをお伝えします。
テスト自動化で起業した10年とテスト自動化普及の歴史を振り返る
登壇者は、株式会社MagicPod CEO 伊藤望さんです。
MagicPodの起業から、自動テストの歴史と併せて発表されました。
その中でも、MagicPodの未来を聞いて、ふりかえってみます。
開発とQAの協調こそE2Eテスト自動化成功のカギ
自動テストを実装するときに、QAがノーコードのツールを使用します。
すると、開発とQAで分断（サイロ化）が起きます。
それは、ノーコードがゆえに、コードで実装する開発のプロセスには、合わないからです。
そもそも、自動テストの目的は何でしょうか？
わたしは、発見した欠陥を、開発に早くフィードバックすることが一番の目的と考えます。
なぜなら、遅いフィードバックは、欠陥の原因の調査が困難になるからです。
それは、開発にとっては、悪いことです。
では、早いフィードバックを実現するにはどうすればよいでしょうか？
それは、開発のプロセスに、QAが入る協調が必要です。
それには、QAがコードを読み書きできることが、必須です。
当然、QAからみると、コードを読み書きするハードルは高いです。
そのハードルを下げてくれる、MagicPodの未来である「コード」と「ノーコード」の融合（コードのノーコードの相互変換）はとても楽しみです。
世界のテストエンジニアから聞いた！ソフトウェアテストの情勢
登壇者は、テクマトリックス株式会社 戸塚 未奈さんです。
アメリカにいる自社のDevOpsチーム、またはGUIテストチームに対して、ソフトウェアテスト状況をアンケート結果に発表されました。
その中で、気になったアンケート結果を1つ例に挙げて、ふりかえってみます。
2022年にあなたの組織でとってどのようなテストアプローチ、または、テスト戦略が重要になるでしょうか？
アンケート結果は、以下のとおりです。
API Testing | APIテスト | 59%
Continuous testing | 継続的テスト | 59%
End-to-end testing | E2Eテスト | 54%
Performance testing | 性能テスト | 50%
UI testing | UIテスト| 42%
わたしは、API（WebAPIと仮定します）とE2Eが逆転していることに驚きました。
つまり、GUIテストをしているチームがE2Eではなく、APIからテストアプローチすべきと判断したということです。
理由は、敢えて考察しません。
E2Eのテストが大きくなりすぎることによる、歪みを感じ始めたのではないでしょうか？
また、性能テストがUIテストより上というのが意外でした。
近年はクラウドシフトした製品が多くなりました。
その結果、性能に対してテストアプローチが必要になったのではないでしょうか？
ローコードツールを用いてチーム全員で自動テスト導入 -mabl で自動テスト-
登壇者は、エムスリー株式会社 窪田 純士さんです。
mablを導入して、1年経過時の成果や課題をまとめた発表をされました。
その中でも、運用の評価について、ふりかえってみます。
CIへの組み込み戦略がまだ立てられない
多くのテスト自動化のSaaSサービスは、実行回数で課金されます。
CIは実行回数が、予測できません。
予測できないと、そのサービスを使うための予算を、立てることができません。
その解決策の予定として出された、ローカル実行（課金対象にならない）をCIに組み込みが、どのような手段なのか？とても興味があります。
今後のエムスリー様のブログをウォッチしたいと思います。
ノーコードテストツール導入時の決め事
登壇者は、株式会社ウェブレッジ 阿部 尭史さんです。
MagicPodを導入した、業務共有アプリを事例として、発表されました。
その中でも、テストシナリオの作り方をふりかえってみます。
どのようにして作成するかのみでなく、実行を想定した作成を行うことが必要
自動テストでは、実行時に失敗の想定もしなければなりません。
例えば、手動テストでテスト実行時に、途中で手順を間違えたとします。
再度、テスト実行時には、途中までで変更したテスト対象の内容は、テスト実行前の状態に戻します。
それは、テスト条件を揃えるためです。
人の手で行う手動テストでは、当たり前にやることです。
しかし、自動テストは、そこまで行ってくれません。
ですので、自動テストはテスト実行時には、どのような場合でも、テスト条件を揃うことを考えて、実装する必要があります。
手動テストを自動テストに置き換えすることを目的にすると、抜けてしまう考えなので、注意が必要です。
まとめ
登壇者の方々の振り返りに熱が入って、長くなってしまいました。
ですので、わたしの発表のふりかえりは無しにします。
発表資料だけ置いておきます。
今回、登壇させていただいて、今年1年を整理することができました。
それは、発表という緊張感のおかげです。
毎年、1年をふりかえりたいけど、できてないな〜という方は、発表をする！という枷を作ってみてはいかがでしょうか？
