プログラマの思索

Googleのソフトウェア品質管理、テスト管理の記事があったのでリンクしておく。
感想をラフなメモ書き。

【元ネタ】
クラウド時代のソフトウェア品質管理。それは健康管理と同じだとグーグルのテスト担当者 － Publickey

開発とテストの融合こそゴール。続、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？ － Publickey

グーグルが行っているビルドとテストの種類。続々、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？ － Publickey

グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？ － Publickey

(引用1)
かつてのようにソフトウェアは単に、開発してリリース、とはならない。ソフトウェアは成長するように構築されるものではなく、出荷されるものでもない…それは単に利用可能になるのだ、文字通り、スイッチを入れるように。

組込製品やパッケージ製品、公共インフラのような高信頼性を要求される製品の場合、WF型で開発してテストした後にリリースの儀式がある。
しかし、Web2.0のようなソフトウェア開発は永遠のベータ版と言われるように、頻繁なリリースは当たり前であり、リリースとは大げさなものではなくシステムが利用可能になるだけ、と主張している。

(引用2)
品質管理と品質保証について、父親の時代のソフトウェア、デミング博士のモデルでは、私たち（テスト担当）の役割は検査官（Inspector）にあたる。しかしそれとは対照的に、いまの私の仕事は内科医のようなものだ。
実際のところ、医療の例えはソフトウェアテストについて考えるとき興味深い類似点がある。内科医にとっての病院は、私たちにとってのデータセンターだ。つねに活動があり、多くのことが並行して起きている。
(中略)
さあ、テスターが診ることができるように、生体活動をモニタするための機器を取り付けよう。人間の患者のように、アプリケーションには脈拍があり、データは血液の流れのようにコードのあいだを流れていく。

品質管理や品質保証を内科医に例えているのが面白い。
ソフトウェアテストは健康診断みたいなもの。
その喩えから類推すれば、システムの品質を数多くのメトリクスで出力することが大切になるし、どのコンテキストでどんなメトリクスが有効なのか、という問題に発展するだろう。
特に最近はプログラミング言語がとても強力なので、コードの静的解析だけでなく、ソフトウェアの動的な構造やアーキテクチャを検証する技術をプログラムで自動化する方向へ発展しているように思える。

(引用3)
プロジェクトとレポートラインを分けることは1つのチャレンジだ。これまでは、テスターは（製品チームにとって）外部のリソースだった。製品チームにとってテストとはあまりに多くのリソースを必要とするため、それを適切に維持することができなかったのだ。
そう、グーグルではテストチームではなく、製品チームが自身で品質管理を負っている。各デベロッパは自身でテストすることを期待されている。テスターの仕事は、自動テストのインフラを確立することと、それによってデベロッパ自身がそれをプロセスの中で実行できるようにすること。テスターはデベロッパーがテストできるようにするのだ。

(引用4)
品質とはどのように実現するものなのか？ という問いに対して、Whittaker氏は次のように書いています。
(中略)
この難問に対するシンプルな答えは、開発とテストを分けて考えるのを止めることだ。（略）品質を確保することとは、テストを行うことと同じではない。それは開発とテストをそれぞれの区別が付かなくなるまで融合させていくことなのだ。
そして、開発とテストの融合こそ、グーグルのゴールであると。
実際にコードを書いている人たち以上にうまくテストできる人がどこにいる？ コードを書いている人以上にうまくバグを見つける人は？ バグのないコードを書きたいと思っている人は？ グーグルがわずかな専門テスターだけで済んでいる理由は、デベロッパーが品質に責任を持っているからなのだ。
品質とは開発の問題であって、テストの問題ではない。これを推し進めて、私たちは開発の中にテストを組み込んでいる。ハイパーインクリメンタルなプロセスを作り、だれかがバグを組み込んでしまったらそれ以前の状態にまでロールバックできるのだ。

品質保証部門やテスト部隊の必要性は分かっていても、その人達はコストセンターになりやすい。
テスト前の工程ではテスターは暇だからだ。
むしろ、プログラマが自身の成果物に関する品質の最終責任者であるし、テスト技術を持ってもいい。

(引用5)
ほかの多くの企業よりも少ない人数のテスターでグーグルはよい結果を得られているが、その鍵となっているのが、多くの機能をいちどに提供することをほとんどしない点にある。
もし実際の利用でバグが発見されたら、テスターはそれのためのテストを作り、それぞれのチャンネルのビルドに対して修正がちゃんと実装されたかどうか実行してみる。
(中略)
強調しておくと、グーグルではスクリプトによるもの、もしくは探索的なマニュアルテストのどちらも重要なものとして扱っている。
先進的なレコーディング技術によってマニュアルテストは自動テストへと変換され、ビルドの後再実行することでレグレッションを確認できるようになる。そしてこれが、マニュアルテスターがつねに新しい問題にフォーカスすることを可能にしてくれる。私たちはマニュアルテストの繰り返しとバグレポートの提出も自動化している。

ソフトウェアテストの技法で探索的テストは頻出されるが、実際の運用はとても難しい。
テストケースも関係なく、テスターの経験値を信頼して、自身で作業ログを取りながらバグを見つけて探っていく。
だから、新人のテスターやシステムの仕様が分からないテスターは探索的テストに向かない。
又、探索的テストはテスト工数を見積りにくいため、テストに際限がないリスクもある。
しかしながら、最近はPC上で操作ログを動画で記録したりできるので、バグの再現性を保証しやすくなってきた現実はある。

RedmineやTestLinkを使った経験から、テスト管理や品質管理の技法はかなり研究されているものの、タスク管理に比べると全くIT化されていないと思う。
ソフトウェアテストでは今でもExcelが幅を効かせていて、テスト結果の記録も手間がかかるし、集計するのは更に面倒だ。
だから、せっかくテストしても有効な知見が蓄積されないので、同じようなミスを何度も繰り返す時も多い。
アジャイル開発ではWF型開発よりも、はるかに高度な品質管理が要求されているのに、実際の現場ではIT化されてないためにボトルネックになっている時も多い。
色々試してみる。