前の10件 | -
link集/コーディング
コード品質好きにはすごーく役に立つサイトかも。
http://www.nbrains.net/php/pukiwiki/index.php?link%BD%B8%2F%A5%B3%A1%BC%A5%C7%A5%A3%A5%F3%A5%B0
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
IEEE computerなのになぜか組み合わせテストの記事、でもいい感じの初心者用かも。
pairwiseでほとんどのバグがみつかるから、3つの組み合わせなんていらないよ!とデータつきの記事。
web serverのテストだと、2つの組み合わせだけで75%がみつかるよ、だって。
あとother empirical investigations have concluded that from 50 to 97 percent of software faults could be identified by pairwise combination testing.と書いてある。この記事の中ではそんなことはないんじゃないと否定している。私も否定派かも。
pairwiseでほとんどのバグがみつかるから、3つの組み合わせなんていらないよ!とデータつきの記事。
web serverのテストだと、2つの組み合わせだけで75%がみつかるよ、だって。
あとother empirical investigations have concluded that from 50 to 97 percent of software faults could be identified by pairwise combination testing.と書いてある。この記事の中ではそんなことはないんじゃないと否定している。私も否定派かも。
ISSRE 2009はつらい
ISSRE 2009はインドのマイソールであった。
インフォシスのキャンパスで開催で、太っ腹インフォシスは会場もタダ、参加者の宿泊施設もタダで提供していた。キャンパスは東京ドーム数十個分ぐらいの広い敷地で、シアトルのM社のキャンパスよりも広かった。
でもカンファレンス期間中はそこからほとんど出れないし、敷地内でお酒の持ち込み&飲むことが禁止でつらかったのである。
インフォシスのキャンパスで開催で、太っ腹インフォシスは会場もタダ、参加者の宿泊施設もタダで提供していた。キャンパスは東京ドーム数十個分ぐらいの広い敷地で、シアトルのM社のキャンパスよりも広かった。
でもカンファレンス期間中はそこからほとんど出れないし、敷地内でお酒の持ち込み&飲むことが禁止でつらかったのである。
ISSRE 2009
ISSRE 2009でプレゼンしてきた。
まあ一般的な組み込みテストについてのプレゼンだったので、内容的にそれほど素晴らしいものではなかったけど、やはりISSREクラスになると来る客がスキルがある。
テストケースの爆発についての話に対しての質問で、「operational profileは有限であるので、その入力定義をちゃんとすれば非現実的なテストケース数にならないではないか!」というするどい質問であった。さすが信頼性のトップカンファレンスoperational profileとテストケース数を組み合わせて品質を理解しているなんてすごい奴。
まあ一般的な組み込みテストについてのプレゼンだったので、内容的にそれほど素晴らしいものではなかったけど、やはりISSREクラスになると来る客がスキルがある。
テストケースの爆発についての話に対しての質問で、「operational profileは有限であるので、その入力定義をちゃんとすれば非現実的なテストケース数にならないではないか!」というするどい質問であった。さすが信頼性のトップカンファレンスoperational profileとテストケース数を組み合わせて品質を理解しているなんてすごい奴。
IEEE Trans. on Soft. Eng.: Impact of Budget and Schedule Pressure on Software Development Cycle Time and Effort
タイムリーな話題であるどこの会社も不景気で予算の削減&スケジュールの削減。
まずは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
をITに当てはめている。でもITに関してはパターン分けしている。
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
と定義している。
まずは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
をITに当てはめている。でもITに関してはパターン分けしている。
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
John Musaが亡くなったらしい
http://www.issre2009.org/content/john-musa
彼の本は日本語に訳されてないので、日本で知ってる人はほとんどいないと思うがソフトウェア信頼性工学の第一人者である。
アメリカにいたときチュートリアルを受けて、アメリカ人にしては非常に親切で穏やかだったのが記憶にある。
ソフトウェア信頼性工学が、いいかげんな信頼度成長曲線を書くことと誤解されている日本に彼のような人は必要だったなー。
彼のような実際のエンジニアリングを理解した研究者はちゃんと日本に呼んどくべきだったのかもしれないと、いまさら後悔。
http://www.issre2009.org/content/john-musa
彼の本は日本語に訳されてないので、日本で知ってる人はほとんどいないと思うがソフトウェア信頼性工学の第一人者である。
アメリカにいたときチュートリアルを受けて、アメリカ人にしては非常に親切で穏やかだったのが記憶にある。
ソフトウェア信頼性工学が、いいかげんな信頼度成長曲線を書くことと誤解されている日本に彼のような人は必要だったなー。
彼のような実際のエンジニアリングを理解した研究者はちゃんと日本に呼んどくべきだったのかもしれないと、いまさら後悔。
Test Principles Revisited 続き
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.
だって
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)
Test Principles Revisitedの記事で、テストのprinciplesについてかkれていた。なんか昨年の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
だとASTQBの人は主張している。いいかげんな私はどっちも正しいからいいじゃんとか思ってしまうが...
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
だとASTQBの人は主張している。いいかげんな私はどっちも正しいからいいじゃんとか思ってしまうが...
International Conference on Software Testing(ICST 2008)
頼んでいたICST 2008のproceedeingが届いた。ちょっと高かったけど、お買い得。ICSTは新しいカンファレンスであり、採択率の低い、質のいいカンファレンス。ISSTAがあるけど、これも採択率は低いが鬼のように狭き関門である。なのでISSTA非常に難しい内容を書かないと通らない。そして論文自体は実体の現場とはかなりかけはなれていて、あまりテストの現場で使えない論文が採用されたりしている。事実私が読み続けるのが困難な論文がほとんどだ。ということは一般のテストな人はまず読めない。
ICSTはそれに比べとっても楽しい論文が並んでいた(もちろんISSTAと比べてだが)。引用文献が少なく、自分の主張を展開したものも採択されたりして、現場の目線で書かれた論文が多かった。
今度ICSTに行こうかと思い、いつもの某先生に聞いたら学会自体はあまりおもしろくないと言っていたので、今年はICSTestでも行こうかと思う今日この頃。
ICSTはそれに比べとっても楽しい論文が並んでいた(もちろんISSTAと比べてだが)。引用文献が少なく、自分の主張を展開したものも採択されたりして、現場の目線で書かれた論文が多かった。
今度ICSTに行こうかと思い、いつもの某先生に聞いたら学会自体はあまりおもしろくないと言っていたので、今年はICSTestでも行こうかと思う今日この頃。
クラウドのテスト
最近ネット上にファイルを保存するツールをdropboxからzumodriveに切り替えた。dropboxもよかったのだが、ファイルイメージをPC側に持ってしまうので、どうしてもノートPCではHDスペースをくってしまうのでzumodriveにした(zumodriveはローカルにファイルを持たない)。
しかしこれが失敗だった、すさまじく品質が悪い。変にCPUを食ったり、システム全体を不安定にしたり。いろいろ調べてみると、amazonのEC2をzumodriveは使っているらしい。EC2が悪いのかzumodriveが悪いのかわからないが、毎週ソフトウェアアップデートのお知らせがくる。
まあやっぱこの辺のクラウド系のテストは難しいのであろう。クラウドのテストは今後注目される分野なのかな。クラウドが広まることはテスト的にはいいことなのと思う。なぜならクラウドのテストは非常に難しいので、テスト屋のスキルが著しく問われる。テストは「キーボード叩いて、画面見て動いていることを確認すればいいや」という世界だと思っている人が多いなか、そんなことでクラウドのソフトをテストしたらたいへんなことになる。zumodriveも、基本的な機能は動いているのだ、でも品質が悪い。
例えばサーバーの機能を理解していない人はクラウドのテストはできない、ネットワークの基礎知識がない人はクラウドのテストはできない。テスターの地位向上のためにはクラウドは歓迎すべき状況かもしれない。
しかしこれが失敗だった、すさまじく品質が悪い。変にCPUを食ったり、システム全体を不安定にしたり。いろいろ調べてみると、amazonのEC2をzumodriveは使っているらしい。EC2が悪いのかzumodriveが悪いのかわからないが、毎週ソフトウェアアップデートのお知らせがくる。
まあやっぱこの辺のクラウド系のテストは難しいのであろう。クラウドのテストは今後注目される分野なのかな。クラウドが広まることはテスト的にはいいことなのと思う。なぜならクラウドのテストは非常に難しいので、テスト屋のスキルが著しく問われる。テストは「キーボード叩いて、画面見て動いていることを確認すればいいや」という世界だと思っている人が多いなか、そんなことでクラウドのソフトをテストしたらたいへんなことになる。zumodriveも、基本的な機能は動いているのだ、でも品質が悪い。
例えばサーバーの機能を理解していない人はクラウドのテストはできない、ネットワークの基礎知識がない人はクラウドのテストはできない。テスターの地位向上のためにはクラウドは歓迎すべき状況かもしれない。
前の10件 | -