知識ゼロから学ぶソフトウェアテスト

link集/コーディング

juichi — Sat, 16 Jan 2010 12:19:40 +0900

コード品質好きにはすごーく役に立つサイトかも。

http://www.nbrains.net/php/pukiwiki/index.php?link%BD%B8%2F%A5%B3%A1%BC%A5%C7%A5%A3%A5%F3%A5%B0

IEEE Computer Aug. 2009: Combinatorial Software Testing

juichi — Thu, 14 Jan 2010 15:58:06 +0900

IEEE computerなのになぜか組み合わせテストの記事、でもいい感じの初心者用かも。

pairwiseでほとんどのバグがみつかるから、３つの組み合わせなんていらないよ！とデータつきの記事。

web serverのテストだと、２つの組み合わせだけで75%がみつかるよ、だって。

あとother empirical investigations have concluded that from 50 to 97 percent of software faults could be identified by pairwise combination testing.と書いてある。この記事の中ではそんなことはないんじゃないと否定している。私も否定派かも。

ISSRE 2009はつらい

juichi — Thu, 14 Jan 2010 15:17:49 +0900

ISSRE 2009はインドのマイソールであった。
インフォシスのキャンパスで開催で、太っ腹インフォシスは会場もタダ、参加者の宿泊施設もタダで提供していた。キャンパスは東京ドーム数十個分ぐらいの広い敷地で、シアトルのＭ社のキャンパスよりも広かった。

でもカンファレンス期間中はそこからほとんど出れないし、敷地内でお酒の持ち込み＆飲むことが禁止でつらかったのである。

ISSRE 2009

juichi — Thu, 14 Jan 2010 15:14:46 +0900

ISSRE 2009でプレゼンしてきた。

まあ一般的な組み込みテストについてのプレゼンだったので、内容的にそれほど素晴らしいものではなかったけど、やはりISSREクラスになると来る客がスキルがある。

テストケースの爆発についての話に対しての質問で、「operational profileは有限であるので、その入力定義をちゃんとすれば非現実的なテストケース数にならないではないか！」というするどい質問であった。さすが信頼性のトップカンファレンスoperational profileとテストケース数を組み合わせて品質を理解しているなんてすごい奴。

IEEE Trans. on Soft. Eng.: Impact of Budget and Schedule Pressure on Software Development Cycle Time and Effort

juichi — Thu, 14 Jan 2010 14:01:55 +0900

タイムリーな話題であるどこの会社も不景気で予算の削減＆スケジュールの削減。

まずはBrooksの法則
"Adding manpower to a late software project makes it latter". In other words, time and effort are not interchangeable.
しごくまっとうな理論である。

Yerkes-Dodsonの法則（そんなんあるんだー）→http://ja.wikipedia.org/wiki/%E3%83%A4%E3%83%BC%E3%82%AD%E3%83%BC%E3%82%BA%E3%83%BB%E3%83%89%E3%83%83%E3%83%88%E3%82%BD%E3%83%B3%E3%81%AE%E6%B3%95%E5%89%87

をＩＴに当てはめている。でもＩＴに関してはパターン分けしている。

They see that a low level of job-related pressure often means a lack of challenge. When employee` (e.g. software developers) cannot fulfill their fundamental need for challenge, they tend to be in attentive and board and, thus do not perform well.

論文では
Budget Pressure = (Team estimated budget - Customer negotiated budget)/ Team estimated budget

Schedule Pressure = (Team estimated time- Customer negotiated time)/ Team estimated time
と定義している。

John Musa

juichi — Thu, 29 Oct 2009 11:57:15 +0900

John Musaが亡くなったらしい

http://www.issre2009.org/content/john-musa

彼の本は日本語に訳されてないので、日本で知ってる人はほとんどいないと思うがソフトウェア信頼性工学の第一人者である。
アメリカにいたときチュートリアルを受けて、アメリカ人にしては非常に親切で穏やかだったのが記憶にある。
ソフトウェア信頼性工学が、いいかげんな信頼度成長曲線を書くことと誤解されている日本に彼のような人は必要だったなー。

彼のような実際のエンジニアリングを理解した研究者はちゃんと日本に呼んどくべきだったのかもしれないと、いまさら後悔。

Test Principles Revisited 続き

juichi — Thu, 03 Sep 2009 08:43:42 +0900

IEEE softwareのいいところが、その反論が必ずのる。
ASTQBのEverettの意見に対して、Meyersの反論がのっている。読んでいて結構子供のケンカみたいなのだがおもしろい。

Meyersは
"ISTQB syllabus is not usable standard, whether according to academic or industrial criteria.

すげーここまで言い切るかー

そしてEverettは
I am not surprised at Mr. Meyer's dissatisfaction with the ISTQB syllabus's academia quality. It was written by a professional society, not an academic committee.

だって

Test Principles Revisited (IEEE Software July/Aug 2009)

juichi — Thu, 03 Sep 2009 08:09:49 +0900

Test Principles Revisitedの記事で、テストのprinciplesについてかｋれていた。なんか昨年のIEEE computerの8月号にSeven principles of software testingという記事で、それの批判のようだ。

ASTQBのEverett君が批判している（Rexの差し金？)

test principlesでは
"An effective testing process must include both manually and automatically produced test cases"

書いてあり、それをASTQBの人は、「mustではない、あるプロジェクトでは自動化はされないかもしれない」と批判している。なんかどうでもいい小さい批判に見えるのだが．．．

さらにISTQBのシラバスでは以下の件はagreeしないと書いてある

"To test a program is to try to make it fail"
"A testing strategy's most important property is the number of faults it uncovers as a function of time"

ISTQBのシラバスでは
"What is testing" asserts that software testing's purpose is to reduce software user business risk

だとＡＳＴＱＢの人は主張している。いいかげんな私はどっちも正しいからいいじゃんとか思ってしまうが．．．

International Conference on Software Testing(ICST 2008)

juichi — Sun, 24 May 2009 14:22:27 +0900

頼んでいたICST 2008のproceedeingが届いた。ちょっと高かったけど、お買い得。ICSTは新しいカンファレンスであり、採択率の低い、質のいいカンファレンス。ISSTAがあるけど、これも採択率は低いが鬼のように狭き関門である。なのでISSTA非常に難しい内容を書かないと通らない。そして論文自体は実体の現場とはかなりかけはなれていて、あまりテストの現場で使えない論文が採用されたりしている。事実私が読み続けるのが困難な論文がほとんどだ。ということは一般のテストな人はまず読めない。

ICSTはそれに比べとっても楽しい論文が並んでいた（もちろんISSTAと比べてだが）。引用文献が少なく、自分の主張を展開したものも採択されたりして、現場の目線で書かれた論文が多かった。

今度ICSTに行こうかと思い、いつもの某先生に聞いたら学会自体はあまりおもしろくないと言っていたので、今年はICSTestでも行こうかと思う今日この頃。

クラウドのテスト

juichi — Sun, 24 May 2009 09:16:41 +0900

最近ネット上にファイルを保存するツールをdropboxからzumodriveに切り替えた。dropboxもよかったのだが、ファイルイメージをＰＣ側に持ってしまうので、どうしてもノートＰＣではＨＤスペースをくってしまうのでzumodriveにした（zumodriveはローカルにファイルを持たない）。
しかしこれが失敗だった、すさまじく品質が悪い。変にＣＰＵを食ったり、システム全体を不安定にしたり。いろいろ調べてみると、amazonのEC2をzumodriveは使っているらしい。EC2が悪いのかzumodriveが悪いのかわからないが、毎週ソフトウェアアップデートのお知らせがくる。

まあやっぱこの辺のクラウド系のテストは難しいのであろう。クラウドのテストは今後注目される分野なのかな。クラウドが広まることはテスト的にはいいことなのと思う。なぜならクラウドのテストは非常に難しいので、テスト屋のスキルが著しく問われる。テストは「キーボード叩いて、画面見て動いていることを確認すればいいや」という世界だと思っている人が多いなか、そんなことでクラウドのソフトをテストしたらたいへんなことになる。zumodriveも、基本的な機能は動いているのだ、でも品質が悪い。

例えばサーバーの機能を理解していない人はクラウドのテストはできない、ネットワークの基礎知識がない人はクラウドのテストはできない。テスターの地位向上のためにはクラウドは歓迎すべき状況かもしれない。

ドコモ、ＮＥＣ製携帯電話機を発売初日に販売停止

juichi — Sun, 24 May 2009 09:06:40 +0900

ひさびさに大きそうな不具合。まあこういうのがたくさんあるとメシの種になるので、おこってもらうとうれしかったりする。

NECの携帯は事故多いのかな？
http://k-tai.impress.co.jp/cda/article/news_toppage/43542.html

まあ誰に聞いても、携帯の開発現場は地獄だというので、それは開発体制も厳しいものがあるのだろう。別段どこの会社の携帯の品質がいいということはない。Nokiaはあまり知らないが、少なくともサムソンも同じように悲惨である。

携帯のソースは確実に300万行を越えていそうなので、Windows 95とかいうレベルなのかな？Windows 95だってハングしまくりだったのだから、携帯もハングするのは当然である。そのうちリセットスイッチが見えるところにつくようになるのでしょう。

コードを書く

juichi — Sun, 17 May 2009 16:29:06 +0900

ここ一ヶ月ぐらいずっとコードを書いていた。ＧＷはトータルで100時間ぐらいは書いていたと思う。残念ながらもう仕事でコードを書くことがなくなってひさしい、でも論文を理解＆展開するのにどうしてもコードを書かねばならなくなり書き始めたのだが、軽くできると思っていたのがなんだかんだで、数千行にもなるコードになってしまった。
アカデミックな実証のコードはいつもいいかげんでglobal変数バリバリ、コメントなし、クラスは絶対使わない、スピード命なので、かなりいいかげんだ。常日頃からコード品質についてうるさく言う私も、自分には甘い。

ただ2000行を超えたあたりでいいかげんなコードはなにがなんだかわからなくなってきた、その時点でクラスを作成して、global変数をなくしてprivateメンバーにするといった作業をしだした。かなり不毛なつまらない作業だった。

若い頃にはわからなかったが、としを取ってわかたことだが、コードを書くのは頭脳労働ではない。floatだのintだのを間違えると動かないし、==と=をタイプミスをするし。いわゆる作業の７０％ぐらいはどうでもいい、誰でもできるコーディング作業だったような気がする。昨今オフショアが盛んだが、コーディング作業なんて全部オフショアに出すべきだなと思う今日この頃。

逆にテストケースを書く作業というのは「すごーく知的」と思うのは間違いであろうか。

想定されないバグ

juichi — Mon, 06 Apr 2009 09:34:31 +0900

私はよく日本信号のトラブルの例を出して話すことが多い
http://juichi.blog.so-net.ne.jp/2007-12-22

あるときその説明に対して質問が出た。「たしかにあの件はバグだが、日本信号のある人に聞いたら想定されないユースケースだったと言っていた。そういう場合はどうやってテストで未然に防ぐのですか」

この業界に長くいると、だいたいの質問に対して水が流れるように答えることができる。ただこの質問はちょっと困った。想定されないユースケースは無限にある、それをすべて要求仕様として定義するのは非常に困難である。また全ての異常系のテストをするのもまた困難である。

そのときなんと答えたかというと、基本的には日本信号のケースはテストしていないswitch文に入ったバグなので、default処理なり特別な例外処理に関してはすみやかなシャットダウンや、なんらかのフェールセーフルーチン処理をするべきだと答えた。

すべてのコードはテストできないはもう現代のソフトウェアでは常識なので、制御できない状態に陥った場合に、システム全体に影響を与えないエラー処理ルーチンはとっても必要だと思う。

品質に交渉の余地はあるか？

juichi — Mon, 06 Apr 2009 08:50:16 +0900

なんかぐぐっていあら「品質に交渉の余地はあるか？」
http://www.infoq.com/jp/news/2007/12/4

なる記事をみつけて。変な学説より、とっても正直な意見である。
もしも顧客が、「完璧なコード」は求めておらず、要求したことを行ってくれる限り品質の低いコードで満足だ、と言ったら、あなたはどうしますか？顧客の要求に応えることが我々の役目ですよね？では、品質については手抜きをしますか？私はそうはしないでしょう。私は顧客が考えていることを理解したいと思うでしょうし、もしそれが、短期的な思惑（「最も費用のかからないソリューションにしたいから品質は気にしない」）あるいは無知や単なる愚かさによるものだということがわかったら、私はほうっておくでしょう。私の良心は、自分の仕事の品質を妥協することを許しません。

ほんとそうだよねー、今の不景気な時代、品質なんてどうでもいいんだ赤字さえ減らせばという風潮である。でもそういう企業って景気が上向いた場合厳しい状態にさらされるんじゃないかなー

私は、少し前にA社を訪ねたのですが、A社のソフトウェアは競合のB社のものよりもよく売れていて、B社を倒産に追い込むことができるくらいです。私が話した人はこういっていました。B社の製品は多機能で速く、そしてA社のものよりバグが少ないのですが、B社は、A社のような現場の専門家がサポートする組織を作らなかったのです。彼らの顧客から見たら、A社の製品はB社のものに比べ、「より高い品質」を備えていたのです。単にバグを減らし保守性の高いコードを書くだけでは「品質」は実現できません。それでも誰かが買わなければなりません。それを買うと決めることは、「何を品質とみなすか」という尺度です。「品質」には数えきれない側面があり、それをどの順で評価するのかを十分に話し合わなければなりませんし、そのほぼ全てが必要なのです。倒産したら、「バグがなくて保守性が高い」ことには価値がないのです。

はげしく同意。品質とは話し合いによって決まるもので、バグの数ではないのである。ましてやバグ曲線で品質を語るものではまったくもってない。

A Practitioner's Guide to Software Test Design

juichi — Mon, 06 Apr 2009 08:28:05 +0900

まあソフトウェアテスト関連の本は一応買っておいて、本棚でこやしになっていくが、ちょっと時間があったので多量の読んでいない本を見始めた。
A Practitioner's Guide to Software Test Designという本がほとんど読んでなく中を見始めた。タイトルは素晴しい、この本はテスト設計について教えてくれるのである。私を含めテストの専門家はテスト設計が重要と言っているが内実は、テスト設計のスタンダードはないに等しい。まあIEEE 829 test designのテンプレートがあるが、それを使っている人はみたことがない。ソフトウェア設計のようにＵＭＬなるものはテスト設計には存在しないのだ。
話は本に戻るが、中身を見ると設計というよりは手法なのかなー、あまり設計のことは書かれていない。と思ったら、日本語訳が出ていた「はじめて学ぶソフトウェアのテスト技法」。うーん、こっちのほうが正しいタイトルかもしれない。

MSの中の人”がホンネで語る

juichi — Tue, 24 Mar 2009 08:10:57 +0900

http://www.itmedia.co.jp/enterprise/articles/0903/23/news011.html

でQFE(Quick Fix Engineer)の話がでてきて、ああなつあしいなーと思った次第だ。リリースした後のサポート体制は、本当に外資系はうまくやっている。MSもそうだし、SAPも同様の強固なシステムを採用している。たぶん予想ではＩＢＭもちゃんとやっているのだろうなー

日本の会社はこの辺をうまくシステマティックにできないので、メインテナンスコストの正確な算出ができない。さらに専門のメンテナンスチームをもってなかったりするので、メインの開発チームのスケジュールにもインパクトを与える。

日科技連ニュース

juichi — Sun, 22 Mar 2009 18:13:25 +0900

2009年3月号

「品質中心の組織文化：ソフトウェア品質の基盤」

野中先生の記事、累積欠陥摘出率の推移が失敗プロジェクト＆成功プロジェクトの間では典型的な差異が認められないといったもの。まあそれがいい悪いという話ではなく、多面的アプローチが必要だということ。

たぶん組織や、製品ドメイン、製品開発の時間やコスト等々とってもたくさんの多面的な要素をいれなければならないのかなー

こういった調査を会社の中で、きっちりちゃんとやっていけば、同様な製品ラインナップ、同様な組織形態なので結構高い予測（失敗プロジェクトなのか、成功プロジェクトなのか）ができるのかなー

IEEE Trans. Soft. 9月号

juichi — Mon, 04 Feb 2008 18:38:25 +0900

やっと暇になったので机の上の整理をはじめる。IEEE Trans. Softの9月号をやっと読む。

regulaer paperの４つのうち３つが品質関連だった、すごい。10年前では考えられないことだ、昔は数ヶ月に一個ぐらい品質に関するペーパーがあったが、最近は月に一つは平均であるんじゃないかと思う。
code cloneに関して２つの論文があったので、code clone好きなひとは読むのもいいであろう。

ASTA

juichi — Sun, 03 Feb 2008 12:15:51 +0900

ASTAという活動をしている
http://aster.or.jp/activities.html

Asiaのテストの地場力を上げていこうという活動である。韓国人のWonilとISTQBのミーティングに出ているときに、このままだとアジアのテスト業界はヨーロッパやアメリカの従になってしまい、アジアはテストの世界でもだめになってしまうというのがモチベーションだ。

ヨーロッパは今元気である、たぶんテスト関連のいろんなことはヨーロッパ主導で決まっていくであろう。その中にあって、極東はただの英語とスキルのない、そして安いものを売ったり勝ったりする２流国の集まりである。実際どこの国際会議にいってもアジアの意見は通らない。人口がいくらいようとも。

そんじゃあアジア一国ではなく多数国で協力してヨーロッパと戦っていくしかない。

そんな活動の一環としてアジアの人に来てもらってJaSSTの中で発表してもらった、話としてはおもしろかった。日本の発表は結構重箱の隅をつつく技術的な話が多いのだが、彼らはテストプロセスとか大きいことを話す。そしてヨーロッパの人たちもどうやってプロセスをするかを話す。ひょっとしたら日本はアジアの中でもおいていかれてしまうのかとも思ってしまう。

ケーパーズジョーンズ

juichi — Sun, 03 Feb 2008 12:03:15 +0900

ケーパーズジョーンズと結構話すことができた、まあ役得である。

結構おもしろいというか、彼の話は共感を持てる。あの言い切り型もいい。FPで全て語れると言い切ってしまうが、それに文句を言える人はいないだろう。なんせあの豊かな経験、そして数値をばりばい言われてしまうと。

話していてすぐに数値がばりばり出るのには驚いた、あの歳でよくあんだけの数値を覚えてるなーと関心する。デマルコもそうだし、ケーパーズもそうだけど年齢というのを感じさせない、なんなんだろう。

マイケルジャクソンの無謀さにも驚いた、皆アメリカの年配は元気である。見習うべきである。

知識ゼロから学ぶ ソフトウェアテスト