アジャイル開発になったらQA担当者はどうなるの? 〜「実践アジャイルテスト」で学んだこと〜 その3
こんにちは、品質マネジメント部の磯です!
書籍「実践アジャイルテスト」にて学んだことをアウトプットしていくエントリその3になります。
前回は「アジャイルテストの4象限」について書きました。
今回は「テスト自動化の阻害要因」についてです。 自動化というとQA/テストエンジニアとって、実現すればあらゆる苦行から救ってくれる魔法のように思えてしまいますが、果たして実際のところはどうでしょうか。 どういった効能があり、どういった阻害要因があるのかについて、学んだことをアウトプットしていきます。
では、そもそもなぜ自動化する必要があるのか?という点から始めたいと思います。
なぜ自動化するのか?
本節にでは自動化する理由が8つ挙げられています。
- 手動のテストは時間がかかりすぎる。
- 手作業は間違いを起こしやすい。
- 自動化は人々を自由にし最高の仕事を行えるようにする。
- 自動化されたリグレッションテストはセーフティネットを提供する。
- 自動化されたテストはより早く頻繁にフィードバックを与えることができる。
- コーディングをこれまで以上にできるようにするためのテストと例。
- テストが文書化を提供してくれる。
- 自動化は投資上の十分な見返りがある。
(P256 13.1 「なぜ自動化するのか?」より)
ふむふむ、自動化を試みようとするエンジニアは大半が上記のようなことが「できたらいいな!」と思うのではないでしょうか。(しかしながら、いささか多くを求めすぎでは・・という危惧も抱きます。)
気になったものについてピックアップしてみます。
- テストが文書化を提供してくれる。
静的な文書を最新の状態に保つことは難しいことです。しかし、もしシステムが変更された際に、自動化されたテストを更新しなければ、テストは失敗します。私たちは、ビルドプロセスを「グリーン」に保つために、それらを更新しなければなりません。自動化されたテスト>は常に、私たちのコードがどのように動作するかを正確に書いたものであるということを意味します。
(P262 13.1.7 「テストは偉大な文書化である」より)
これはテストケース自体が仕様書になるといっているのだと思いますが、この考えは絵に描いた餅になりがち・・・。新鮮な状態に保ち続けるのはなかなか難しいと思います。 テスト対象の規模や歴史が積みあがってくるごとに増していく自動テストケース。重複するコードを共通化してシンプルにするも、新たな機能に対応していくうちにどんどんとメンテが困難になってしまう、なんてことは自動化あるあるではないでしょうか。
さて、自動化するにあたっていろいろな心配事が湧き上がってくると思います。これらは「自動化を妨げる障害」として著者の経験が纏められています。
自動化を妨げる障害
- プログラマの姿勢
- 痛みのこぶ
- 初期投資
- 常に変化するコード
- レガシーシステム
- 恐れ
- 古い習慣
(P263 13.2.2 「私たちのリスト」より)
これらについては一つずつ見ていきたいと思います。
プログラマの姿勢
ここではプログラマの姿勢について論じられています。
従来的なチーム編成ではDEVチームQAチームといった具合に別個の組織として存在しており、DEVチームは機能テストの自動化についてまったく考えたことがないでしょうと言っています。 アジャイルな体制においてはDEV, QAといった役割を超え、一体的な体制で開発していくことが良しとされているため、そのような意識では困りますよ!ということです。
また、自動化用のコードを実装する場合にはDEVよりの経験が必要となるため、プログラマにもQAレイヤーでのテストに対して積極的な姿勢が必要です。
痛みのこぶ
(特にテスト自動化に限ったことではありませんが)初期段階においては多くの時間がかかります。 これを時間に対する作業量のグラフとしたとき、ポコッとこぶがあるような見た目になります。
この状態を乗り越えるには適切な指導やマネジメント層の支援も必要となってきます。適切な指導/支援が受けられる環境であれば、組織としてテスト自動化への積極的な取り組みが行われているように思えますね。こぶも小さなものとなりそうです。
初期投資
自動化を始めるに当たってはどのような技術を使って実現するのか、十分な検討が必要となります。
自前で作ったものをフレームワークを使用するのか、すでにあるものを使うのかどうか。 高価なソフトウェアを導入しても、実現したいことに対してはオーバースペックである可能性もあります。
十分に評価できる時間(つまりはお金ですね!)を事前に投資できるとよりよい成果をうみだせるのではないでしょうか。
常に変化するコード
GUIに対しての自動化は困難を伴うと予測されます。なぜなら頻繁な変更がおこなわれ、その都度追従していくのは多くの手間がかかってしまうからです。
このような状況を改善していくにはプログラマとテスターの協調関係をより強めることが必要といっています。頻繁に変更が行われたとしても、機能としての意図は大きく変わらないはずなので、そこに着目してテストを編成していくのがよいとしています。
たとえば何らかの計算をする機能であれば、適合するテストデータをあらかじめ用意しておき、それを流し込むテストコードを変更に強い設計にしておく、といったことなのかと思います。
レガシーシステム
過去に実装されたコードにはテスタブルな状態にないものも存在します。これらはリファクタリングするなどしてテスト可能な状態に持っていくことが重要ですが、新規開発も行いながら過去のコードも触っていくというのはなかなか困難な作業となります。
実現にあたってどのような戦略を持てばよいのか、次の章で紹介されていますので次回のエントリでアウトプットしていきたいと思います。
恐れ
この項は著者の思いがかなりでているところなので、原文を引用します
プログラミングを行わないテスターはアジャイル世界において提供するものが何もないと、しばしば言われてきました。私たちはそうではないと信じています。どのように自動化すべきかをテスター個々人が心配する必要はないのです。これはチームの問題です。
(P268 13.2.8 「恐れ」より)
それぞれの知識を持ち寄って、協調していくことにより、恐れをはねのけていきたいですね!
古い習慣
困難にさいなまれたとき、ついつい居心地のよい古い習慣に戻ってしまうことがあります。インクリメンタルな自動化を行っていくべきところで、毎回手動でのテストを実施するようになってしまう、といったことです。これでは変化への柔軟性に大きく影響が出てしまう恐れがあります。後々大きなバグが生み出され、ビジネスにも影響してしまう可能性があります。
まとめ
今回の章は「テスト自動化」についてのものでした。記述内容からどのレイヤーなのかがちょっとわかりづらいところもありましたが・・、ざっくりとまとめると・・。
- 自動化によって開発工程におけるセーフティネットが築ける
- ネガティブな阻害要因は必ずでてくるが、恐れずチーム全体で解決していく
と理解しました。
次回は・・・
テスト自動化にあたっての戦略について、アウトプットしてきたいと思います!
ではまた次回。