ミルク蒼屋のチラシ

Colloid(コロイド)が何か色々と残したりするブログです

ソフトウェアテスト自動化カンファレンス2022のゆるい感想

技術 日記 勉強会 いろんな感想

testautomationresearch.connpass.com

聞きながらメモがてら書いてました。色々と乱雑な文面で読みにくくすみません。

参加した背景

今というか今年はずっとテスト自動化を担当していたから。
ちなみに私はQAの経験皆無です

基調講演 テスト自動化で起業した10年とテスト自動化普及の歴史を振り返る / 伊藤 望さん(株式会社MagicPod)

サッカーを見ずに100枚のスライドを作ったらしい。
自動テスト関係のテストの著者。
MablもノーコードだけどMagicPodもノーコード実装できしメンテしやすいらしい
5年前はSelenium強しという感じだったけど、今は色々あるとか →色々(CypressとかのSelenium以外のOSS、MagicPodやmablとかのノーコード等)
昔はSelenium一強なのは初耳、今の時代との差分が聞けて何より。

13年前の話

WebよりWinデスクアプリが多くあった頃。手動テスト負のサイクルに飲まれていたそうな(テスト不十分でリリースしてユーザーに不具合見つかったのループ)
下位バージョンのテスト省略した結果、お客様に不具合が。下位バージョンのテストを自動化したいというのが経緯
13年前はJUnitでユニットテスト、UWSCという癖の強い古のツール →なので自作していこうという動機
自作するにはひたすら調査エラーの繰り返し、成果ファースト、利用者不足等…
3年後に普及されたそうな →自動テストはいいぞという体験を得た

自動テストで起業

もともと起業したい欲があったそうな人？らしい。ということで起業へ
Web以外のソリューションを対象に自動テストエンジンを作るところからはじめたそうな →しかし1年後、開発難しく…
トレンドと比べるとかなり難しいことを挑戦していたそうな

Seleniumの日本展開

コンサル導入支援事業に転換をした。世間的にはテスト自動化普及されてないので、広めて行きたいと。
→ブログ執筆、コミュニティ設立、勉強会開催、カンファレンス開催など
結果普及は伸びた！しかし課題も多くある
一番は他人の作ったものを紹介するのは面白みが低いのが課題だった

再挑戦

テストツールにAI技術を使えば面白そうとのことで、AI付きテストソリューションを開発する方針に
→Magic Podが爆誕(Potという名前だったけど訳するとマリファナになるので名前を変えたらしい)
画像からテストを作成するツールを開発。
儲ける仕組みつくる必要がある

テスト自動化の今後

コードとノーコードの融合をしていきたい
→コードを書きたい開発、ノーコードでやりたいQA
画面でポチポチして設定したものがコードで表現できるように

感想

自動化の歴史とそれに対するアプローチや活動が知れて良かった。昔はSelenium強い時代だったのは初耳だった
今はノーコードが流行りな感じあるけど、自動テストでもむしろ両方のアプローチしていきたいというのはいいなと思う。

データ分析が変えるソフトウェアテストの未来 / 金井 慎治さん・後藤 香織さん

テスト自動化は一般化されている
→しかし自動化は予め用意していたものに対してAssertしかできない
これからは利用するデータを集める→分析して課題を見つけていこう
→データ活用へ
しかし、分析は難しく異常値の扱いがむずかしいという課題が
→データの質を高めて、データを扱うためのテクを得る

CICDと世界中のデバイスとの連携のデモ
データはグラフで表記、メモリやバッテリーの消費等パフォーマンスに関するデータが得られる
→ローディングの画面の表示率とかをAIで分析する
解析について、画面の動きや読み上げの音声品質とかのデータをつかって分析→ユーザー体験がどのような感じなのか知れる
データを使って、統計やKPIをの考え方を取り入れて、今後の方針を決定の資料として使う

感想

ただテストして終わりというわけではなく、テストをした結果をもとにテスト結果以外の部分をもとに分析したりするアプローチの発想はなかった。
データをもとに分析するということでは、経営陣に訴える資料として活用もできそうと思う。

ローコード開発におけるテストピラミッドの考察 / 坂下 聡さん

ローコード開発はコーディングと単体テストが短縮される一方、テストは変わらず存在するというのがよくある話らしいが、実際問題どうなのか
想定通りユニットテストは実際に減った。ユニットテストをしなくていいが、動作検証は結合テストで実施すべき。コードレビューが設定値レビューに置き換わる。
責任を明確にしていってテストの必要性を考えていく

感想

つぶやいた通りなんだけども、ローコードノーコードはそのローな動作という品質は製品側(ツール側)で担保されているので、ビジネス要件的な面のテストが中心になるのねということかーと。
これからはほんとローコードとかが流行りそうな中、テストの考え方も少し変わるのかなと思った。

世界のテストエンジニアから聞いた！ソフトウェアテストの情勢 / 戸塚 未奈さん

アメリカのエンジニアに対して、聞いてみたそうな。
Ranorexの紹介。(アンケートしたのがその会社)テストできる対象にWinFormsがあって驚き。

DevOpsと機能テストについて
リリースサイクルは2週間～1ヶ月が6割だそうな。
DevOpsのツールはJIRAやAWS/Azure DevOps
DevOpsの重要なプラクティスは自動化されたCICDのパイプライン
使うテスト手法は本番データを使ったテスト、テスト環境の構築(コンテナ化も含む)。本番環境でもテストするそうな

テストチームについて
GUIテストは開発側がやることを期待している、次点で外部にお願いしていくという意見が多いらしい
テスト戦略はAPIテストが重要視しているらしい。自動化はわりと当たり前らしい。
GUIテストの課題として、テストのシナリオ(自動化)の作成と維持が課題。これはどこもそうだなーという印象。
QAチームでやっているは他にコンプライアンステスト(ライセンス確認や規格の確認)をしている

自動化テストの状況について
テストの自動化は100%ではなく、効果のある部分(リグレッションテストとか)中心に自動化している
自動化の満足度は半分くらいの人は満足らしい。
自動化への障壁は金と雇用とトレーニングだそうな

感想

海外事情、おもったより日本と同じような悩みを抱えていたのは驚いた。効果のある部分の分析とかどうしてるか知りたいわね。

APIテストにおけるテスト駆動テスト実装のすゝめ / 引持 力哉さん

APIのテストが無いのでやりたかったというのが動機
APIは期待した値がちゃんと返ってくるのか確認するのがAPIテスト
→レスポンスを考える。正常系だけではなく、異常系もやることで仕様の考慮漏れを検知する
テスト起動テスト実装という考え方
→APIの概要から見て、テストを実装

感想

APIテスト、今まさにやってるのでめちゃくちゃ為になった。

APIテスト観点については質問して回答を得れたのでうれしみ。
APIテスト、APIによってケースがあるものはあるので、その新しいテスト観点を他のAPIテストに反映していきたいわねーと思うなど。

E2E自動テスト導入のつらみ・解決・ふりかえり / honaminさん

導入にあたっての
1.テストツール選定
チーム希望をヒアリングした
ツール差分の調査
社内外の知見の調査をした
→選定は納得の行く理由が必要、移植性を大切

2.テスト実行環境
自動テスト環境が無いので用意しにといけない
→会社の有識者に聞く＆話し合う等
実行環境は後回しになりがちっぽいので、最初にテストを実行する環境は用意したほうが良さそう

3.導入フェーズ中に参画
なぜE2E自動テストをしたいのか。知るためになぜやりたいのか等をヒアリングをする。
ツールはほぼ決まりかけていたけど選定しなおし
自動テストを導入する目的と効果等を確認&イメージすることが大切

ノーコードテストツール導入時の決め事 / 阿部 尭史さん

実際の事例もとに知見の共有
決めておくべき所

1.自動化ができる所、できないことの整理
事前にまとめずに自動化するとできなかった場合のリカバリが遅くなるのがつらくなる

2.テストシナリオの作り方
実行を想定したテストシナリオの作成 →トラブル発生時やメンテナスの時など

3.運用時のルール設定
アプリ更新時のバージョン管理、テストシナリオ実行時間の上限、テスト結果の作成及び利用方法(これを明確にしないとなぜ実施したのかがわからなくなる為)

感想

上記2つのセッションまとめてで申し訳ないが、導入はやはりチームや周りの理解や同意を得ることが大切。そのために必要な調査や環境等はちゃんとやるべきと思った。

runnによるAPIのシナリオテストの導入と自動化 / 小山 健一郎さん

シナリオをYAMLで定義してそれを実行(自動化できる)するツール
CIに入れやすく、SQLやHTTP等色々対応されている
シナリオ間で値連携ができる
負荷テストもできる。色々できそう
curlのリクエストを引数でテストステップの生成も簡単に
YAMLを書くだけなので、開発者もホイホイ作成できる

感想

このツールはどちらかというと開発者向けだなーと思った。開発未経験だと慣れるまで時間かかりそう。
マイクロサービス、恐らく他APIの依存ありきのAPIとかありえると思うのでそういう時便利だなとか。
APIテストも開発でやるという方針であれば普通に使うと思った。

CIにおける、UIテスト自動化のメリットを最大限に引き出す方法 / 片瀬 聖乃さん

自動化のメリットとして、作業時間の削減、人的ミスを防ぐ等ができる
→しかし実行までの手間や結果管理の手間があるとメリットは得られない
CIと組み合わせてやると良い
→CIツールで定期実行する仕組み、テストケースを常に最新な状態を保つ仕組みを入れたりすると、上記の手間がなくなる。

CI組み込みやすいUIテスト自動化ツールを選定するのが良い(当たり前)
→CIはコマンドラインを使えればよさそうなので、自動化ツールもコマンドラインで実行できれば良いのではと思う
またCIに対して公式にサポートできるようなものが提供されているか等…
テスト管理ツールは自動テスト手動テスト両方管理できるものが良さそう(TestRailとか)

感想

UI自動テストの課題として並列実行とかスケーリングがあるのかなと思っている。UI自動テスト、量が多いとどうやってCIでスケーリングしてるの…？

全体的な感想

今回初参加だったけど、色々とためになる話が聞けてよかった。そしてDiscordとZoomを組み合わせたカンファレンスの運営がすごく参考になった。特にセッション毎にチャンネルを作るのは実際(オンライン)の部屋分けてわいわいする感じがあって良かったなぁと。
個人的には自動化をするということは、自動化をする目的や結果をどうしていくか等をプロジェクトとしてどうしていくかを、自動化ツールも含めて決めていくのがすごく大切なんだろうなと思った。ここを端折るとなぜなのか…と思いながら実装していくことになると思ったので。モチベーションもこういう課題を解決する！みたいな目標がないと続かないだろうな…。
そんな感じでした。運営の皆さん、登壇者の皆さん、貴重なイベントを開催して頂きありがとうございました！