実践アジャイルテストの講演会の感想 #secafe
実践アジャイルテスト
【元ネタ】
翔泳社 実践アジャイルテスト イベントセミナー
実践アジャイルテスト トークショーつぶやきまとめ #secafe - Yukarin'Note
僕の感想はTwitterに色々書いた。
ジャネットさんの話よりも僕がソフトウェアテストで感じている疑問やいら立ちを書いた。
Twitter / akipii: 日本のソフトウェアテストは人海戦術。マンパワーがモノを言う。アジャイルは上流工程よりもテスト工程の自動化を優先する。発想が根本的に違うと思う。#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)による品質向上も一部の人に注目されているが、実際の運用例を聞くと、普通では見つけにくいバグ修正や、再現しにくいバグ修正に使われている時が多い。
つまり、ある程度の品質が担保されたソフトウェアに対して、探索的テストの代わりに形式手法を使って再現しづらい細かなバグ修正を行なっているように見える。
その意味では、形式手法もテスト工程の本質的改善策ではないように思える。
アジャイル開発がソフトウェア工学で新しい観点をもたらしたもののひとつは、保守性や移植性という品質に焦点を当てたことだと思う。
リファクタリングやテスト駆動開発は保守性という品質に直結しているし、継続的インテグレーションは移植性の品質確保に役立つからだ。
そして、形式手法、派生開発などの手法もソフトウェアテストの問題の解決に役立てるために生まれたと考えることもできる。
ソフトウェアテストについては色々考えてみたい。
」を読んでいると聞いて、ネット上で検索した結果をリンクしておく。
」にあるAntのリファクタリングカタログでは、If文やループ処理は書かないことを推奨している。
」によれば、15FP/人月がよく使われるらしい。
」で提示されたScrumによるストーリーポイント見積りは、見積りが計画づくりの重要な作業であることを認めた上で、見積りの手法やその注意点を細かく説明している点がとても優れている。
」を読み直すと、計画と見積りは密接に関わっている事実、更にそこにはもっと深い考えがあるような気がしている。
」では、
の勘定パターンが在庫モデルに適用できることを説明しているが、それは、会計と在庫という概念モデルとしては性質が異なるはずなのに抽象的なモデルでは構造が似ていることを意味している。
の本では、船舶の輸送モデルをドメイン分析していくと船荷証券(つまり荷為替手形ないし未着品)のような概念が出てきた例や、利息サービスの計算をドメイン分析していくと発生主義会計(つまり経過勘定科目、例えば未払利息や受取利息など)の概念が出てきた例が載っている。
」の一節に、フィールズ賞を受賞した業績である定理を証明する時、恩師の方から、問題をもっともっと難しくして理想的な形にすれば解けますよ、とアドバイスされたそうだ。
」が発売されるらしいのでリンクしておく。
」はプログラマの心構えを書いた本で僕は一番良い本と思うが、2003年頃に読んだ頃はバージョン管理はCVSやVSSが主流だった。
」では、タグのことを「リポジトリ資産にラベル付けする」という言葉で紹介しているが、これはITILの構成管理における構成管理データベース(CMDB)の構成管理アイテム(CI)を連想させる。
』において、上記のアルゴリズムは既に提示されているのに、今まで誰もうまく使いこなせていなかったこと。
」や「
」にも入れ子集合モデルの話が掲載されている。
最近のコメント