TEST Study #2「ソフトウェアテストにおける自動化」

https://forkwell.connpass.com/event/249851/

に参加してきたので、そのときのレポート

資料を見ながら口頭で説明していただいた部分のメモ

基調講演「ソフトウェアテスト自動化、一歩前へ」

ソフトウェアテストの自動化

ソフトウェアテストの自動化は広い意味を持っている
日頃どんな部分で関わっているかで、イメージするものが人によって違う
自分が認識している以外の部分も、色々な側面から見るのが大事

テストは領域に分けられて、自動化が適している領域がある

• チェックの意味
  • 正しい結果を知っていて、その通りになること
• テストの意味
  • 想定外のことを発見する

自動化が向いているのはチェック

テストピラミッド

ピラミッドでいうところの領域を確認し、その領域に適したツールで領域を絞ってテストすることで、効率よくテストができる

アイスクリームコーンのテスト

画像

効率が悪いので、なるべく避けるべきだと言われている。

他にもモデルはいくつかある

バグフィルター

画像

網目がバグのありかを表している。
Unit テストは網目が細かいが、まかないきれない範囲がある。
逆に下の層に行くほど、網目が大きいが、範囲が広くなる

学び

Unit テストどうしようか、E2E テストどうしようか。ということを考えてしまいがちだが、

全体を通してどうテストしていくかを考えることも大事。

一歩前に進める現実的なやり方

理想的には自動化したいが、現実的に整備されてなくて、進められない現実がある。

その場合は段階的に進めていくのが良い、という提案をすることがある。

今ある手動実行前提のテストをそのまま自動化しない

人が読む前提で書かれたケースがあるので、そういうのは機械に解釈させるのが難しい場合がある

視聴者Q&A / パネルトーク

Q1. テスト仕様書のようなものを書いた上でテスコードを書いているのですが、テストコードを書くならテスト仕様をドキュメントとして残すのは無駄に感じてしまいます。

テストコードを書く場合でもテスト仕様書は必要なものなのでしょうか？

A1. テスト仕様書を E2E でやっている前提だと捉えると、一概には言えないが、必要だと思う派。

テスト仕様書を残すと、全体としてどんなテストをしてどんな結果だったかを整理してみたい、という目的があったとして、それをするにはテストコードだけでは難しいところがある。
例えばテストコードが、バグのパターンを正しいと思って書いている場合がある。
そうするとプロダクトオーナーに仕様を聞くことになる。
テスト仕様書を書くとプロダクトオーナーの頭の中にある仕様書を表現することになる。

Q2. エンジニアが頑張りテストを充実化させていくことに限界を感じています。

組織を巻き込んでテストを根付かせる方法論をお聞きしてみたいです。

A2. 後半の組織の話になると、実はそれは私も知りたい。

これをやると組織に根付く、というものはない。
まずは、いま苦労しているものが楽になるイメージを持ってもらって、じゃあどうしようかみたいな建設的な会話ができたりする。
そういうソフトスキル面が大事かもしれない。

Q3. E2Eテストの自動化を一定進めたとして、テストピラミッドの形に移行するためにとるべき重要なアクション紹介いただけますでしょうか？

A3. アイスクリームコーンの上の部分を自動化したとして、その後の話だと思うが、その前提で話すと。

E2EテストでテストがNGだったものを洗い出し、それはE2Eテストじゃないといけないのか？ということを考える。
それはUnitテストだよねとか、見つけていったりする。

Q4. 自動テストが少ない既存のプロダクトに対して、自動テストを増やしていく際の人的リソースの配分におすすめの方法はありますか？

例えば専門のチームを組む（開発チーム全体に知識を共有するのが難しそう） or 既存の開発チームが〇%時間を割く（なかなか進まなさそう）など

A4. 難しい問題だと思います。

日頃自分は専門チームで自動化をするチームを組むことが多い。
テストのノウハウを教えるということはあまりない。
自分たちにテストを依頼する現場は切羽詰まっていることが多い。
なのでノウハウを伝える時間はないことが多い。
専門のチームを組むのが難しい場合があるが、専門者がいると進めやすいなと思うことは多い。
兼任でやると中途半端になることが多い。

Q5. 単体テスト、E2Eテストについてはある程度どういったテストを書けば良いのかはわかりやすいのですが、 結合テストについて、どういったテストケースを書けばいいのか悩んでしまいます

どういったテストケースが向いている、こういった観点で書いていけば良いなどありますでしょうか？

A5. まず結合テストとは？

会社によって結合テストでやっていることがバラバラな状態。
自分の中では、サブシステム間のテストと捉えている。
マイクロサービスなアーキテクチャだと、責務が分離されているので分かりやすいが、
結合テストをやりたい部分で何をテストすべきか？が分かりづらいから結合テストが難しいのだと思う。
テストを書く前にリファクタリングできると良いかもしれない。

Q6.協力会社がテストを書かない、かつ自分のチームにテストを書く文化がない状態で、何から始めるのが良いでしょうか…？

A6. ちゃんと契約書に書くとかになってくるが、この問題がある状態というのが、納品されたものに問題がある状態だと思う。

なので、テストを用意してそれがパスしたものだけ納品する、という形もあるとは思う。（幸せになりづらいが）
協力会社に書いてと言って失敗したことがあって、現状テストできるように設計していないので設計しなおす料金はどうするという話になってしまった。
テストがない状態というのは、テストのメリットを分かっていないのかもしれない。

Q7. 自動化の過渡期について チーム内の単体テストを一部ツールで自動化し始めました。

しかし、そのツールの範囲外の部分は従来通りの手法(Excel)で実施することになってしまい、負担が増えてしまいます。 どんどんツールを使ってもらいたい一方で、負担はあまりかけられない、この過渡期を乗り切るポイントが知りたいです。

A7. 現場を度外視した外側からの意見だけでいうと、ツールに問題があるかもしれない。

ツールを変える選択肢もあるが、現実的に変えられないこともある。
過渡期を超える上で、あとどのくらいで過渡期を超えられるというゴールをチームで持って、そこまで頑張るとかかもしれない。

Q8. 自動化によるコストをどう回収できるか、どう判断したら良いでしょうか？

A8. 開発費を含めた経費を計算することだと思う。

また、インシデントをどう防ぐかという話をすると、コストとかじゃなくてやるしかないという話になる。

参加して個人的感想

• テストの自動化は、サービスの規模が大きくなってくると途中からやるのはとても大変なので、最初からある程度設計していたほうが良さそう。
  • そうもいかないのが世の常かもしれないが。。
• 途中から自動化する際は、最初から全部を理想系にするのではなく、部分的かつ段階的に進めていくのが良いのというのは、テストもそうだし、いろいろなことに当てはまりそう。
• チェックとテストの意味の違いは、なるほどと思った
  • 言葉の定義がどうというよりは、そういうふうに分けて考えるとイメージしやすいよなと思った。
• テスト自動化を当たり前のように取り入れている環境もあれば、そうではなくまず受け入れられなけばならない環境もあり、組織や文化も関係している。
• 経営目線の人にテストについて理解してもらう際は、開発が楽になるという話よりは、コストを減らすことができますという会話のほうが、相手にも理解してもらいやすそう。