実践アジャイルテストの講演会の感想 #secafe

実践アジャイルテストの講演会に行ってきた感想をメモ。

【元ネタ】
翔泳社 実践アジャイルテスト　イベントセミナー

実践アジャイルテスト トークショーつぶやきまとめ #secafe - Yukarin'Note

僕の感想はTwitterに色々書いた。
ジャネットさんの話よりも僕がソフトウェアテストで感じている疑問やいら立ちを書いた。

Twitter / akipii: 個人的には品質の定義がアジャイルとWFで違うと思う。膨大な仕様書と照合して合致すると良いのがWF。回帰テストで確実に動くのを保証するのが良いアジャイル。同じように聞こえるが本質的に違うと思う。

Twitter / akipii: #secafe?　品質はそれ自体追いかけても手に入らないように思う。ソフトウェア特有のプラクティスを複数組み合わせた結果現れるものではないか。品質は掴み所がない。ソフトウェアの品質は特に測定しづらい。

Twitter / akipii: #secafe　ソフトウェア特有のテストはポーティングテストだと思う。同じ機能なのに環境やライブラリのバージョンアップや移植ですぐに動かなくなる。システムはウォーターフォール開発で作ってもすぐに陳腐化する。回帰テストがソフトウェア開発はとても重要。

Twitter / akipii: 日本のソフトウェアテストは人海戦術。マンパワーがモノを言う。アジャイルは上流工程よりもテスト工程の自動化を優先する。発想が根本的に違うと思う。#secafe

Twitter / akipii: 仕様書に従って動くのをテストするウォーターフォール開発と確実に動くシステムを早く納品するのをテストするアジャイルはテストの考え方が本質的に違うと思う。 #secafe

Twitter / akipii:アジャイルがこの考え方であるのは理解できる。品質の意味が違う。 RT @digitalsoul0124: ソフトウェアを個別に考えるのではなく、顧客に価値を提供するソリューションの全体像として考えるべき #secafe

Twitter / akipii: 探索テストは経験者でないと効果出ない。バグの再現が難しい。@digitalsoul0124 変更がないのであればテストを自動化する必要はない。価値が提供できるならば、やり方にこだわる必要はない／探索型テストをやらなくてよいほどシンプルなシステムにであったことはない #secafe

Twitter / akipii: 日本のSI企業らしい発想。テスト工程で人を増やしリリース間近で一気に減らす。何か違う。 RT @yattom: #secafe (アジャイルテストの外注という発想がすごい。今日の話をどう聞いてたんだろう)

Twitter / shin_semiya: テストの人海戦術は「意味のある頑張り」か？改善を考えないとにかく力押しが国内には多すぎる気がするんだが。あれ顧客価値をシステム屋の都合で損ねてるだろ #secafe

Twitter / shin_semiya: 手動中心だと「直す時間がないからここは諦めようぜ」が大量に発生して結果として負債積み上がりが発生したので私は好きじゃない。自動化しようぜ。 #secafe

ソフトウェアテストでは、回帰テストがとても多い。
理由は、ソフトウェアそのものとソフトウェアを巡る環境に変化が多いから。
ソフトウェアそのものが頻繁にVerUpするのはSNSでも業務系Webシステムでも同じだ。
それだけでなく、ソフトウェアを配置している環境、つまり、OSやDB、ライブラリなどシステム基盤やミドルウェアのVerUpも頻繁に起きるため、機能がデグレードせずに正常に動くかどうかのテストも重要だ。

2000年代の10年間だけでも、WindowsOSは2000→XP→Vista→7と4つもOSがVerUpしているし、今も毎日セキュリティアップデートと称してOSのVerUpは分からないぐらい多い。
スマートフォンも、iOSやAondroidのOSのVerUpはWindows以上に激しい。
最近のスマートフォン開発では、AondroidOSのバージョンの互換性維持がとても難しく、それがSNSやスマートフォンアプリの開発の足かせになっているように思える。
RedmineもRubyやRailsのVerUpに追いつくのさえ大変だった。
他のシステムやWebアプリも同様だろう。

つまり、ソフトウェアの品質特性の中で移植性(ポータビリティ)は、作業の中身が理解しやすい割には作業がとてもまどろっこしい。
そして、移植性の維持のコストは半端なく大きい。
移植性の品質確保には、継続的インテグレーションによる回帰テストがとても有効だ。
Jenskinsでは、マルチ構成プロジェクトという機能があり、JDKやAnt、Mavenなどのライブラリのバージョンを変えて、同じモジュールを常時ビルドする機能がある。
この機能を使えば、同じソースだが、OSやJDK、C++のバージョンが違って、コンパイルしたビルドモジュールが異なる状況をテストすることが可能になる。
そうすれば、移植性のテストを自動化できる。
移植性の品質は、回帰テストの自動化ととても相性がよいと思う。

清水吉男さんが提唱されているXDDPによる派生開発は、組込製品における移植性に焦点を当てている。
例えば、組込製品はiPod/iPhone/iPadのように、似たような仕様の製品をたくさん作り、カスタマイズしながらVerUpする作業が多い。
すると、以前作ったソフトウェアを流用して移植する作業が多くなり、保守性や移植性の観点のテストが多くなる。
派生開発はそのような現場の困難な状況に対し、一つの解決方法を示している。
その意味では、現場に根ざした開発手法だと思う。

日本のソフトウェアテストは、自動化という発想があまりない。
その理由は、ウォーターフォール型開発によるV字型モデルにテストケース作成が依存しているからだと思う。
仕様がきちんと書かれた膨大なドキュメントを元にテストケースを作りたいために、仕様書をきちんと書かなければならない前提条件が課されているからだ。
確かに、仕様書が正確に書いてあれば、仕様通りに作られていることを確認するテストケースをプログラムを見ることなしで作成することができる。
この方法を中心として日本の品質管理技法は発展してきたように思える。

だが、このやり方は最近壁にぶち当たっているのではないかと思ったりする。
ビジネスの変化、ソフトウェアの変化に仕様書の変更が追いつかないので、品質の良いテストケースを作ることが難しくなっている状況があると思う。
W字型モデルは設計工程でテスト工程の観点や作業を含めて、上流工程の品質向上につなげるやり方だが、実際に動くプログラムを作るわけではないから、実運用は難しいだろうと思う。

形式手法(Formal Method)による品質向上も一部の人に注目されているが、実際の運用例を聞くと、普通では見つけにくいバグ修正や、再現しにくいバグ修正に使われている時が多い。
つまり、ある程度の品質が担保されたソフトウェアに対して、探索的テストの代わりに形式手法を使って再現しづらい細かなバグ修正を行なっているように見える。
その意味では、形式手法もテスト工程の本質的改善策ではないように思える。

アジャイル開発がソフトウェア工学で新しい観点をもたらしたもののひとつは、保守性や移植性という品質に焦点を当てたことだと思う。
リファクタリングやテスト駆動開発は保守性という品質に直結しているし、継続的インテグレーションは移植性の品質確保に役立つからだ。
そして、形式手法、派生開発などの手法もソフトウェアテストの問題の解決に役立てるために生まれたと考えることもできる。

ソフトウェアテストについては色々考えてみたい。