少し時間が空いてしまいましたが、こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、connpassのイベントページから引用です。
Forkwell はこれまで「つくり手と、未来を拓く。」というビジョンのもと、第一線を走るエンジニアから統合的な学びを得る勉強会を継続開催してまいりました。
インフラ、フロントエンド、機械学習と技術領域にフォーカスした題材を多く取り扱う一方で、ソフトウェアテストの様な普遍的なテーマについてはこれまであまり取り扱ってきませんでした。 そこで Forkwell はソフトウェアテスト自動化プラットフォームの「Autify」を提供するオーティファイ株式会社と共同でソフトウェアテストに関する勉強会を開催します。
Test Automation Specialist の末村 拓也氏にモデレーターを依頼し、テストに関する思想や向き合い方、具体的な技術論までソフトウェアテストに関する幅広い学びを提供する場としていく予定です。 全3回をかけて行い、各回のテーマに沿った第一線を走るエキスパートの方々にお話を伺っていきます。
会で印象的だったこと
テスト自動化モデルを組織へ適合する
テスト自動化を考える際のモデルとして、
- アジャイルテストの4象限
- テストピラミッド
- Testing/Checking
- バグフィルター
などといったモデルの紹介があった後、これらのモデルをどのように組織に適合させていくかという話が挙がっていました。
モデルにあるような形は理想ではあるものの、現場(特にテスト自動化が進んでいないような場合)のコンテキストに適合させるためには、距離が遠すぎる可能性もあり、アンチパターンであってもいいのでまず前に進める手もあるというお話が挙がっていました*1
テスト観点を作ってから自動化するのではなく、自動化するテスト観点を洗い出す
テスト自動化の際に陥りがちな事象として、一度作ったテスト観点に対してテスト自動化をしようとして、自動化がしにくく苦しむ、という話が挙がっていました。
その対策として、テスト観点を洗い出す時点から、この観点は自動化するのか？というのを考えるというお話が出ていたのですが、この発想はこれまでなかったので、ぜひ試してみたいと思いました。
(可読性が高いテストコードがある前提で)テスト仕様書って必要なのか？
以下の理由から、テストコードの可読性があったとしても、テスト仕様書は必要だと思っているというお話がありました。
- どういう目的でテストをしているのか？テストの間引きをはじめとしたテスト戦略はどのようなものか？というのは、テストコードから読み取れない
- テストコードが仕様として正しいことを判断するのに困る場合がある
自分の周りだと、テスト仕様書は不要だという意見を聞くことが多かったので、実体験をもとにテスト仕様書が必要だという意見を聞くことができて、面白かったです。
自動テストの人的リソース配分をどのように考えるか？
ベストなやり方だとは思っていないものの、開発者への負担を少なくしていくやり方の方が経験が多いし、抵抗がなく自動化も進めやすいというお話がされていました。
トレンドとしてテスト自動化をみんなでやっていこう、という考え方はあると思いますが、上でも出ていたように理想までの距離が遠くなかなかテスト自動化が進まないということも多いと思うので、選択肢の一つとしては出ていた回答も持っておきたいなあと感じました。
結合テストが書きにくい
システムを構成するサブシステム通りの関わりをテストするもの、という定義で話をしていくと、結合テストが書きにくい時点でサービスのつながりや設計が間違っている可能性があるというお話がなされていました。(マイクロサービスアーキテクチャの導入など)
会全体を通した感想
QAエンジニアとしてテストの自動化に取り組んでいるところだったので、非常にタイムリーで参考になる内容でした。
他のイベントと比較して、「こういう状況の現場ではあまり役に立たない考え方」というのを明示した話が多かったのが、個人的にはいいなあと思いました。
