DiscussionMemo TestAutomation1st - AIshiji/SoftwareTestAutomation-ReadingCircle GitHub Wiki

第1回テスト自動化標準ガイド読書会におけるディスカッションメモです。

テスト自動化標準ガイド「第２章キャプチャーリプレイはテスト自動化ではない」の53ページ、詳細な手動テストスクリプトを自動化すれば、テストオートメーター がアプリケーションやビジネス、テストケースについて理解する必要がなくなる、という記載ついて、第1回勉強会で、参加していただいた方々の意見を聞いてみました。

賛成派は若干名でした。賛成派は、エンジニアは技術が売り、仕様やビジネスなど多様なエリアを両方理解できるような人材の確保は難しい等の意見がありました。反対派は、ソフトウェアの拡張性や発展性考慮のためには、テスト自動化担当者も仕様やビジネスも理解してほしい、またテスト自動化を効果的に運用していために理解は必要なのではないか、等の意見がありました。

賛成

• 理解している人が（テストスクリプトを）書ける = テストドキュメントが正しく記載している、となるので

• （だって）実装するだけじゃん！（テストドキュメントが完璧であるという想定で）

• （ビジネス理解まで求めてしまうと）スキルセットが限定できないので

• エンジニアは技術スキルが売り。（ビジネス等の理解は）学習コストが無駄になるかも

• 学習コストが高くなってしまう

• （オートメーターに諸々の理解が必要なら）コストがかかる

• 人材が探せなくなる（技術もビジネスも理解できるような人材確保は大変）

• 大量の人材が確保しにくくなる

• 手順が確立され、ツールに成熟しているなら、（ビジネス等に理解がなくても）可能ではないか

• ビジネスに興味がないケースが多そうなので

反対

• アプリの構造が分かっていないと、自動化戦略がたてられない（はず）

• ビジネスについては理解が必要

• ビジネスやテストケースを理解することで、自動化の最適化ができる。コストを抑えることができると思う

• 重要な箇所が分からず、時間を効果的に使えない

• コミュニケーションコストがかかるはず

• 会話が分からないと悔しい

• コミュニケーションのとっかかりになるはず

• サービス／プログラムの発展性まで考慮しないといけないので

• 保守性の高いソフトウェアを書くためには、ドメインの理解が必要と考えるから

• テスト自動化を専門にする人も、業務知識があれば、もっと良い自動化を思いつきそう

• 自動化の対象の、テストのしやすさを検討してもらってから、自動化をしてもらった方がよいのではないか、と思うから

• 間違ったテストケースが作られてしまうかもしれないから

• 通常のソフトウェアと同様に、テストプログラムも完全な仕様を書く事できないから

• 自動化で手順を読み替えたい時、テストの意図や製品について理解していないと、できないため

• テストケースを理解せずに自動化できるほふど具体的になっていることが少ないと思うから

• 役割として、詳細なテストケースがある状態であるなら賛成。しかし、現実的に今の状態を考えると、そこまでの状態を作りにくい。挙手の結果もそれを示しているのではないか（参加いただいた方で、賛成は若干名でした）

• 仕様の相互チェックができないのではないか

• 優先度の判断ができないのではないか

• （テスト対象となるソフトウェア）の拡張性も考慮しないといけないので

• 逆説的に言うと、テスト者が考える必要がないまで、詳細を詰める必要があるという事となりコストが膨大になるのではないか

• 理解する必要がないのは、スクリプト化した先の話ではないか

• 最終的には、人の方がエラーを多く、正しく発見する、と思う

• 携わるサービスへの参加意識を持ってほしい

• モチベーションがダウンする（何を作っているか分からない）

• 何も考えずに実装可能だとしたなら、（テスト自動化ツールが進化することで）いずれ自動化できる範囲が広がり、（テストオートメーターという役割も）必要なくなるのではないか。今後もテスターとテストオートメーターの役割分割は、永遠に続くものなのか？

• （賛成、反対というよりも）逆に、テスターがオートメーター側を知っておくべき、だと思う