WACATE2009 冬まであと1ヶ月。
==
クロージングセッションではシステムクリエイツの清水吉男さんのお話が聞けるということなので、事前に清水さんの書籍を読んでおこうと。SE（ここではシステム・エンジニアでもあり、ソフトウェア・エンジニアでもある）の心構えというか、持つべきスキル、時間の使い方などが、ハッとさせられます。ホームページをお持ちで、今度じっくり読んでみようっと。
「硬派」ソフトウェアエンジニアのためのホームページ
http://homepage3.nifty.com/koha_hp/
また、WACATE2009 冬は今回もさっそく満席になり、60席まで拡大。
| 固定リンク | コメント (0) | トラックバック (0)
今回の目玉はいろいろイベントレポート。意外とソフトウェアテスト関連のイベントは多いですね～。また、先月に引き続き、「勉強会のモデレータをやってみよう！」を書かせていただきました。
| 固定リンク | コメント (0) | トラックバック (0)
今日はフェデラーだ！
==
システム開発ジャーナル Vol.10
システム開発ジャーナル、今回の特集は「エンジニアのためのソフトウェアテスト術」です。最近ディベロッパーズテスティングという言葉がよく見られるようになった気がします。
| 固定リンク | コメント (0) | トラックバック (0)
久しぶりの本紹介。
理系思考術 (ソフトバンク新書)もともと僕は理系ですが、数学全般や論理に関する基礎的な素養はどういうふうに教えたらいいのかな？と思って、購入。第1章が待ち行列の話。第2章は最短経路の話。第3章はゲーム理論。第4章はベイズ理論。例えば、第4章ではこんな例がでてました。
どちらも比較的有名なお話ですね。みなさん、同僚で同じ誕生日の方はいますか？＾＾
| 固定リンク | コメント (0) | トラックバック (0)
週末丸善で購入。
ディペンダブルシステム―高信頼システム実現のための耐故障・検証・テスト技術最後のほうに「テスト技術」というのがあって、そこが目当てでしたが、なかなか面白い。基本的にはソフトウェアというよりはカードとか回路とか、そういう世界の話で難しいが、少しずつ読んでいこうと思う。静的マスクはコスト高いなあ。自分が扱ってるシステムは基本動的マスクかつフェイルセーフかな。
数学のロジックと集合論こちらはZ言語を勉強する第1弾として、集合論を復習したかったので購入。培風館は大学の頃よく買ってましたね。本当は例題、演習を解きながら読んだほうがいいのだろうが、すっかり頭が鈍ってます。
==
[2009/04/09追記]
「数学のロジックと集合論」の正誤表・補足はこちら。
| 固定リンク | コメント (2) | トラックバック (0)
テストPRESSの最新号が1月末でますね。個人的な注目としては「WACATE」についての記事と「CFD法の極意 前編」の記事でしょうか。
ソフトウェア・テスト PRESS Vol.8
| 固定リンク | コメント (0) | トラックバック (0)
「品質力」の磨き方 (PHPビジネス新書 73)
「○○力」という言葉は最近よく聞かれますが、この本では「品質力」という造語を使っています。著者の経験を通じて、品質＝顧客の期待値、を作ることについていろいろな具体例やたとえを使って解説。登場するさまざまなエッセンス（品質と品種、品質とブランド、重要だが緊急でないこと、科学的手法と技術的手法、TQCとTQMなど）はエンジニアだけに必要なテーマではない気がする。科学的手法と技術的手法ってはじめて聞いた。
高品質を低コストで実現するひとつの方法として直交表を取り上げています（L9直交表）。1つの例を取り上げている程度で詳しい適用法などはありませんが、立体表現するというのが「直交する」「均一に存在する」という性質をとても直感的で、印象的でした。
6面どの位置から射影しても○が9つそろうように見えます。なるほどねえ。
| 固定リンク | コメント (2) | トラックバック (0)
自分がいなくてもまわるチームをつくろう!この本に登場するMBAとは不在のマネジメント（Management By Absense）のことで、リーダーがいないチームをまわすことについて書かれています。自分の境遇もそうだし、ソフトウェアテストという視点で見ても必要かなと思い、手に取りました。
時間管理やミーティング管理など、基本的な指摘ではあるものの、実践している人は多くはないかもしれません。また、「チームの評価は顧客がする」ということも、少し考えれば納得できることですが、なかなかそういった思いには至らないかも。自分に足らないところ、気づかされたことをかいつまんで読むといいかな。
| 固定リンク | コメント (0) | トラックバック (0)
2008年度のデミング賞本賞・実施賞・日経品質管理文献賞が発表され、ブログでも紹介していた「SQuBOK Guide」と「HAYST法入門」が受賞されました！どちらもシステム開発に携わるエンジニア全般におすすめできる書籍ですね。
ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方ソフトウェアテストの勉強室： [書籍]「ソフトウェアテスト HAYST法入門」 で入門してみる
ソフトウェア品質知識体系ガイド―SQuBOK Guide| 固定リンク | コメント (0) | トラックバック (0)
ちょっと路線の違う書籍の紹介。
2008年度版 日本経営品質賞 アセスメントガイドブック
画像は経営品質協議会より
ソフトウェアテストとは少し離れてしまいそうですが、「経営品質」とは、というくだりでは、以下のような言葉がありました。
日本では「品質」という言葉は、製品の機能や特性を表すものととらえられてきました。ものの質だから、「品質」だという概念が定着しています。
（中略）
品質は「クオリティ」という言葉を訳したものです。クオリティの語源はギリシャ語の「クオリス」です。この言葉は「ものの明らかさ、適切さ」を意味しています。
（中略）
ある目的で適切なことであっても目的が違っていれば適切でなくなるのです。急いでいるお客様に対しての時間価値を目的としたサービスの質と、ゆっくりとくつろぎたい人むけの時間価値を目的としたサービスの質は異なります。このように品質は目的と深く関係している考え方なのです。
品質＝顧客満足度ととらえることはこの「クオリティ」という言葉の語源からもしっくりくる考え方です。この本ではいかにして「経営」品質を向上させる組織を築くかについて書かれていますが、これらは同時にソフトウェア品質を向上させる組織・チームの築き方が隠されているようです。
amazonでは販売していませんが、いろいろな場面で活用できるテキストだと思います。
| 固定リンク | コメント (0) | トラックバック (0)
ピアレビュー―高品質ソフトウェア開発のために
ピアレビューとは「同僚による査読」であり、品質向上のためのツールのひとつ。この本はタイトル通りこの「ピアレビュー」をテーマにした1冊。その中でも「インスペクション」と呼ばれる公式レビューについての解説が厚い（第4章～第9章）。公式レビューは、概要説明、準備、インスペクションミーティング、修正、フォローアップという5段階を踏み、モデレータや記録者、読み手という役割が必要となるが、それに見合う欠陥検出効果が見込めるという。実際には、プロジェクト計画において品質目標、規模などを考慮して公式レビューを取り入れるのかどうかを見極めることになるので、必ずしも公式レビューである必要はない。とはいえ、こういう手法を知っておくのはいいことだ。
第4章でも言及されているが、インスペクション（準備をしてミーティングによって欠陥を指摘する）がどれほどの効力があるかについては議論の余地があるようです。この本以外の書籍についてもあわせて読むことを薦めたい。たとえばソフトウェア・テストPRESS vol.2でインスペクションについての記事が載っている。また、ドロシー・グラハムのソフトウェアインスペクションも読んでみたいな。
| 固定リンク | コメント (0) | トラックバック (0)
ソフトウェア・テスト PRESS Vol.7内容紹介 ソフトウェアの品質に注目したテスト専門誌。Vol.7では、特集1として「ソフトウェアテストの見積り」を取り上げ、ソフトウェアテストを見積もる際の考え方や見積りのタイミング、見積り時の注意点、歴史などを解説していきます。また、特集2では「世界のテスト事情」と題して、世界と日本のテスト業界をマクロに紹介し、その比較の中で、日本のテスト業界が今後どのように発展していくべきかを探っていきます。特集3では「探索的テスト手法」を取り上げ、テストにおける“経験と勘”をいかに積み上げていくかを見ていきます。
半年振りのソフトウェア・テストPRESSは、個人的には特集３と、巻頭カラー部分に期待してます。
| 固定リンク | コメント (0) | トラックバック (0)
システム開発ジャーナル Vol.5こちらで紹介したページの最後のほうに「ソフトウェアテストの方法論・手法・技法のトレンド」について解説している、と書かれていたので。というか、この雑誌をよく知らなかった。テスト設計技法については「日本発」なものが増えている気がする。SQuBOKも日本発だし。バックナンバーから読みたい。
| 固定リンク | コメント (0) | トラックバック (0)
Webアプリケーションテスト手法
Webアプリケーションを開発する側にたち、テスト手法を「テストの自動化（駆動開発）」「非機能テスト（性能、セキュリティ）」を中心について解説。対応言語（Perl、ActionScript、PHP、Ruby、JavaScript）の専門家が執筆しているところも特徴的。この本で学んだものをより効率的・効果的にテストへ活かすには、テスト戦略・設計にかかわる本もあわせて読むと相乗的に品質を上げることが可能かも。
| 固定リンク | コメント (0) | トラックバック (0)
思いがけずにこんなサイトを発見。
【レポート】エキスパートが薦める、夏期休暇に読んでおきたい書籍 - テスト/品質保証編
間もなく夏期休暇。まとまった休みを目前に控え、余った時間を知識に変えるための良書をお探しのエンジニアも少なくないだろう。本誌では、そうしたエンジニアの要望に応えるべく、数回にわたり、各分野のエキスパートが薦める書籍を紹介していく。今回、推薦を依頼したのは豆蔵 シニアコンサルタントの大西建児氏。10年以上にわたって品質保証活動に携わり、NPO法人 ソフトウェアテスト技術振興協会や財団法人 日本科学技術連盟のSQiP(ソフトウェア品質委員会)で活躍する同氏から、ソフトウェアテスト/品質保証の分野でお薦めの書籍をピックアップしてもらった。
豆蔵の大西氏による、品質保証・ソフトウェアテスト分野の「夏に読もう」的な書籍紹介。
ソフトウェアテスト293の鉄則ひゃ～まだ読んでない。どこかしこでもオススメ本として紹介されてますね。
ソフトウェア品質保証入門―高品質を実現する考え方とマネジメントの要点品質保証とは何たるかをABC的に教えてくれる良本です。僕自身も帰りの電車を待ってる間と電車の中で読みました。コンパクトさでいうと「293の鉄則」よりも持ち運びやすいと思います。感想については詳しくは、こちらを。
ゆとりの法則 \x{ff0d} 誰も書かなかったプロジェクト管理の誤解トム・デマルコの「ゆとりの法則」。見た目もそうだし、内容もそうだし、これが一番夏休み図書っぽい。ゆるゆるとまではいかないが、読み終えて少し時間を置いて頭の中で発酵させてから実践する、という意味で。
ステップアップのためのソフトウエアテスト実践ガイド (日経システム構築)個人的にはデスクにおいておきたい一冊ですが、実践的・泥臭い内容、著者の経験が読み取れる本ですね。
| 固定リンク | コメント (0) | トラックバック (0)
ウェブと書籍で「Webアプリケーション」のテストに関するウェブサイトと書籍が登場。書籍についてはまだ未読だが、
本書は、Webアプリケーション開発におけるテスト手法をはじめて本格的にまとめた、開発者待望の1冊です!
本書が注目しているのは、テストの自動化、つまりテストコードと呼ばれるコードを書き、自動的にテストの処理を行う手法についてです。 本書は、「テストを書く」という手法について知らなかった方や、聞いたことはあっても実践したことはなかった方、多少はテストを書いたことがある方をターゲットとして、テストの基礎的な考え方や、Webアプリケーションでよく利用される各種言語での具体的なテストの手法、さらには運用の際に重要となるスケーラビリティや使い勝手など、Webアプリケーションにおいて必要となる様々なテクニックを解説しています。
Webアプリケーションのテストは、不快なデバッグ作業を軽減し、問題やミスを少しでも早く簡単に発見するために発展してきたものです。デバッグを行うよりも、はるかに楽で(ある意味おもしろみもある)作業を行うことで、デバッグのコストを軽減し、早く、バグのないプログラムを書くことができることを目指しましょう。
どちらかというと自動化、効率化などに特化した内容でしょうか。言語ごとにスペシャリストが登場するので、多様な言語の多様な手法が垣間見れるかも。
ソフトウェアテスト基本テクニック：第6回 Webアプリケーションのテスト｜gihyo.jp … 技術評論社
ソフトウェアテスト基本テクニック：第7回 キャプチャ／リプレイツールによる機能テストの自動化｜gihyo.jp … 技術評論社
Webアプリケーション特有のテスト観点、テスト結果評価などについても言及されています。またSeleniumやJameleonといったフリー系自動ツールの使い方などは第７回以外でも、さまざまなサイトでも取り上げられていますね。自動化率をあげるには設計段階でツールを想定しておくのがポイントかも。著者の町田氏は「現場で使えるソフトウェアテスト Java編」やソフトウェア・テストPRESSなどでもおなじみ。
| 固定リンク | コメント (0) | トラックバック (0)
著者のお二人は日立製作所で実務を経験され、保田氏は現在つくば国際大学で教べんをとり、奈良氏はソフトウェア開発のコンサルタント業をされている。奈良氏は先日の「ソフトウェアテストミーティング2008」での基調講演を聞かせていただきました。
第1章ではソフトウェアの品質・品質保証について書かれており、ソフトウェア品質の考え方をモデル化した説明、ソフトウェアの4つ（あるいは5つ）の特質、欧米と日本の品質の考え方の違いなどが丁寧に解説されている。不良低減のための方針を表した図は、なるほど、と自明ではあるものの「作り込み不良低減」「不良の早期摘出」という2つのベクトルがとても印象的。
第2章では品質保証部門ではなく開発部門の視点に立ち、前述の「作り込み不良低減」の努力について解説している。DR（デザインレビュー）については問題点があげられており、限られた時間で、できるだけメンバーに多くの指摘をしてもらう、DR終了後の徹底的なフォローが必要、といった指摘があった。自身のレビューを振り返るいいネタになりそうだ。
第3章は出荷後の品質保証活動について、第4章ではいわゆる静的・動的テストに関するテスト戦略・技法などについて網羅的に解説されている。ここでは技法紹介に加えて、「評価」についても言及されている。「測る」ことの重要性を再認識させられる。
第5章、第6章では人材育成・求められる品質保証というテーマが、より広域的な視野で語られ、本書は締めくくられている。
機会があったら、今度は保田氏の講演をきいてみたいなあ。
| 固定リンク | コメント (0) | トラックバック (0)
バタバタしとります。
==
ずいぶん間が開いてしまいましたが、この春になってテスト関連書籍もどしどしでてますね。Java版ということなので、C言語版も今後期待してます～。TEFでも勉強会が企画されたりと話題の1冊。
こちらは半年に1回発行されているソフトウェアテストPRESSの増刊号的なものでしょうか。著者も「大西建児、丹羽隆、町田欣史、田呂丸直純、秋山浩一、珍田晋之介、鈴木三紀夫、池田暁、細川宣啓、佐々木方規」といった先輩方の名前が連なっています、新社会人・これから復習したい人・ソフトウェアテストPRESSに興味があるけど、まだ購入していない人、いろいろな人にとって有意義な記事に出会えるんじゃないでしょうか。「MADE IN JAPAN」というキャッチも興味深い。
| 固定リンク | コメント (0) | トラックバック (0)
amazonで予約してた本が届きました。
本書はまえがきにもあるとおり3部構成となっている。
技術的な勉強としては2部がメイン。テストPRESS#2での「直交表による組み合わせテスト入門」でわからなかったこと、理解が進まなかったことがあった方には、この書籍はかなりの助けになる。僕も気づきがあったし。テストPRESSとの比較を交えて何点か。
直交表はすべてのn因子組み合わせがまんべんなく現れる性質がある、というのは説明されているが、じゃあどうして出現しない組合せをしなくてもいいのか。実は単機能テストや総当り表を使えば、その理由がより理解される。ちなみに2因子組み合わせを100%網羅するという点ではall-pair法も同様に実現できるが、この方法では高次因子間で偏ることも説明されている。
テストPRESS#2では見開きで2ページ弱だった禁則の解説が、今回は1章分、21ページもある。僕はここが苦手だったので、もう少し深く勉強してみなくては。
線点図を使えば多水準化ができるももちろんだが、2列と交互作用列との3列で4水準列を作成する説明や、独立な因子同士は交互作用列を使いながらサイズ膨張を防ぐなど、より数学的な解説も多くなった。成分表示も追加されてました。（a、a+b、cみたいな）
サブシステムに局所化して、あとから結合する方法である程度の網羅性を犠牲にしつつも、サイズ膨張を防ぎ、効果を維持する手法などはテストPRESS#2にはなかったか。
そのほか、コラムが充実しているし、状態遷移の行列の積による考察もなかなか興味深い。しいて個人的な意見を言わせてもらうと、直交表が効果を持つのは、単機能テスト前提という場合が多いと思う。そのあたりの言及はされていたが、もっとしつこくあってもよかったなあと思った。単機能テストと組み合わせテストは野球で言えばスターターとクローザー、みたいな。どっちも点を取られないように抑えなくちゃいけないが、どちらも特性がある。なーんてね。
今後の期待としては「応用編」「実践編」などの続編（！）や原因結果グラフ・デシジョンテーブルなどの兄弟本も出るといいなあ～
==
今後、勉強会なども開催される予定なので、自分の勉強メモや気づきを書いていきたいです。
| 固定リンク | コメント (2) | トラックバック (0)
さてさて、でますよ。HAYST法＋直交表本。
きました。直交表についての書籍はいろいろ出版されているけど、ソフトウェアテストへの応用に特化したのは、あんまり見かけないかな。これは、必読でしょ。HAYST法ともなると、ウェブ上のJaSSTの資料とテストPRESS2巻くらいしかお目にかかったことがないや。ちょー楽しみ！！！
| 固定リンク | コメント (0) | トラックバック (0)
このところソフトウェアテスト関連の書籍や雑誌・特集が多いなあ。でも楽しみでもある。
==
エンジニアマインドでテストエンジニアについての特集があったので一読。豆蔵の大西さん、「マインドマップから～」の池田さんが寄稿。
単体テストや結合テストは開発担当、システムテストや受け入れテストはテスター。という分業が一般的ではあるが、どちらかというと後者についてはマイナスイメージが多い。だけれど、最近は少しずつ光が当たってきているんじゃないかと思ってます。じゃあ、テストに携わるエンジニアってどんな人たち？というのを特集しています。作る側のスキルアップはけっこう花形だし、社内にもけっこう学べる環境が整っていたりするけど、テストエンジニアはやはり外に出たり、いろいろ実験してみないとわからないことが多い。「テストエンジニアとしてさらにレベルアップ！！」にあるとおり、コミュニティの活用、シンポジウムやセミナーに参加、資格試験に挑戦、というのはモチベーションの維持にも、ノウハウの吸収にもグッドな道ですね。僕の場合はこのブログを通じて、（初心者なので恥も含めて）自分の経験や実践をメモしていくこと、セミナーや勉強会で社外の情報を得ること、書籍でいろいろな技術・トレンド・意見などを得ること、を実践しています。
資格について言えば、JSTQBのFundation Levelは本書で池田さんのおっしゃるとおり、「知識の確かめ」レベルですね。AdvanceやExpertはおそらく実践的であり、腕試ししてみたいですね。
| 固定リンク | コメント (0) | トラックバック (0)
いつの間にかにしさんのブログがはじまってた。
==
先月発売された「マインドマップから始めるソフトウェアテスト」でおなじみのマインドマップに関連した記事もあるとか。4号から間髪あけずにって印象だけど、実はきちんと半年ぶりなのか。エンジニアマインド最新号については読んでから記事載せようっと。
| 固定リンク | コメント (0) | トラックバック (0)
ソフトウェア・テストPRESSからのスピンオフ、「マインドマップから始める～」が技術評論社から出ました。
第1部では、ソフトウェアテストって？マインドマップって？といった基本的な紹介。品質と健康とを対比した説明はテストPRESSにも見られましたね。
第2部では、多くのページ数をさいて、実際のソフトウェア開発のケースを例にしてマインドマップを使ったソフトウェアテスト（仕様分析～テスト報告）の段取りがわかりやすく解説されています。テストPRESSでは、テスト設計からテストケース作成までの解説のみでしたが、書籍化されたことによってそれ以外の応用についても言及されています。本書は新人クン向けでもあるが、「テストカテゴリ」やIEEE829「テスト計画書テンプレート」などは、僕も勉強になるし、ナゼその項目が必要なのか、必要でないのか、などを再学習できた。負荷テストについての創発がメインで取り上げられていたが、負荷テストにマインドマップのようなブレーンストーミングを取り入れたことがなかったので、再度じっくり読んで、活用できないか検討してみようっと。
第3部はデジタルツールについての紹介。僕も最近はFreeMindを使ってみるようにしたけど、イマイチスピーディーに使いこなせていない気がする。やはり手書きが一番か？？
第4部は本書のまとめ。「気づき」を得ることが第一。フランクリンコビーの研修でもこのマインドマップをツールとして紹介していたし、「気づき」を大切にするという共通点があると思う。
==
まあ、当たり前のことだけど、テスト設計でマインドマップをすると、たいていブラックボックス的なブランチが多くなりがち。ホワイトボックステストの設計って直感的・経験的なブラックボックステストよりも難しいって話を聞いたことがあるけど、この方面でもマインドマップって活用できないかなあ。例えばモジュール設計で、カバレッジしやすい設計をするために、マインドマップでカバレッジしにくい箇所を特定して、対策を考えるとか。うーむ。
| 固定リンク | コメント (3) | トラックバック (0)
もうすぐでますね、マインドマップ＋ソフトウェアテスト本。発売日は6/22です。
ソフトウェアテスト専門誌「ソフトウェア・テストPRESS」の特集「マインドマップからはじめる～」が書籍化。マインドマップ（マインドマッピング）とはトニー・ブザンが提唱するブレーンストーミングの一種で、中央から枝を伸ばしていく形で発想を図式化していく記法。フィッシュボーンチャートに形は似ている。
「テストする」とは単に与えられたプロダクト・サービスを試しに使ってみて問題ないかどうかを検証するだけに思われがち。でも、このブログでいろいろ小難しいことを記録しているように、「いかに効果的に」「以下に効率的に」「いかにムラなく」テストするか、と考えるとなかなか奥が深い。（ムラというのはテスト網羅性と実施者のスキルによらない、という意味も含めて）
そこで巷では結構有名なマインドマップという手法をソフトウェアテストに適応させたのが、この本。どちらかというとソフトウェアテストの初心者向け・ABC的な切り口なので、これから勉強しようと考えている方々にも、これからテスト技術者を育てようとしている方々にも、また再勉強を考えている方々にもすすめられそうな気がします。（僕もまだまだ未熟なれどもマインドマップをテスト設計に適応してみたりしてる口です！）
んで、マインドマップとソフトウェアテストの親和性についての私見。トニー・ブザンのルールには含まれていないが、マインドマップではMECEであることが重要（特にメインブランチ）。このMECEさがソフトウェアテストの網羅性や効率性に大きく貢献できる要因ではないか、と。
この本のために有志によるマインドマップ＋ソフトウェアテスト勉強会があったのだが、都合がつかず不参加だったのが、ザンネン！！
発売したら早速買って読んでやる！
==
そういえばPRESS3巻とかにもあったにしさんのNGTもブレーンストーミングのロジックツリーに形が似てたなあ。
↑マインドマップを使ってテスト設計まで
↑続編。テスト設計からテストケース・テストプロシージャに落とし込むところ
↑同時期に発売のマインドマップ本。JUDE。
| 固定リンク | コメント (2) | トラックバック (0)
ソフトウェアテストというか、品質向上ということで、ヒューマンエラーについての本。
ここでは、ヒューマンエラーとは何か、とか、ヒューマンエラーは認知の間違い、判断の間違い、動作の間違い、といったカテゴライズをするのが目的ではない。正しい答えを見出したとしても、ヒューマンエラーによる事故、損害はなくならない。そういった科学的・学術的なことを覚えるよりもより具体的・身近な例をあげている。
当然ながら、ヒューマンエラーのより深い考察を元に対策をとる必要がある場合もある。ただ、昨今のヒューマンエラーというのは単純な要因だけで説明がつくものではない。チェルノブイリ原子力発電所の事故も、「原子炉運転員の教育が不十分であった」「特殊な運転を行ったために事態を予測できなかった」「低出力では不安定な炉で低出力運転を続けた」「実験が予定通りに行われなかったにも関わらず強行した」「実験の為に安全装置をバイパスした」といった複雑な要因が絡み合ったため発生したとも言われている。
途中、ヒューマンエラーの防止策の3つの方針が掲げられている。
これって、実はソフトウェアテストでも応用できそうで、
というように換言できるんじゃないかな。他にも「二人作業班策」って、これはペア・プログラミングそのもの。
リスク分析という観点では、「きっかけ演繹法（Event Tree Analysis, ETA）」「事故原因帰納法（Fault Tree Analysis, FTA）」というアプローチがごくごく自然にエンジニアは使っているような気もする。前者が「マウス操作を誤ったら、どんな事故が発生するか」というリスク分析で、後者は「交通事故はどういう原因で発生するのか」という逆方向の分析。
直接的にソフトウェアテストに活かせるわけでもないが、なかなか興味深い本ですね。
| 固定リンク | コメント (0) | トラックバック (0)
雨降って社内フットサルチームの活動は中止。ザンネン～
==
先日購入した開発の現場（ほぼソフトウェアテストPRESS）を読んでみた。
先日までの自分のプロジェクトでは結合テストでもーう少しうまくできたなあ、と思ってて、「結合テストを見据えたリーダーのためのテスト調整術」という記事が一番気になってました。
単体テストって意外に気合入れてやらないことが多いって話。テストじゃなくて、動作確認、ってレベルで終了しちゃうとか。単体テストでのテスト仕様書を実装前に作る、って書いてあるけど、それがモチベーション向上につながるかというと、そうじゃないケースもありそう。個人的には「面白い」「楽しい」「見てすぐわかる」を目指したい。コードカバレッジの可視化ってけっこう楽しいし、成果が眼に見えていいと思う。
テスト環境の準備やテストデータの準備ってほったらかしちゃうね。でも、これがないとテストはできないし、いざってときに準備されていないと、テストのリズムが悪い！
これはほとんどのプロジェクトでやっているでしょう。ごく小規模であったり、単体テストでは実施しないこともあるけど。
プロジェクトによっては単体テストと結合テストを一緒にする、といったことはあるけど、いつの間にかスケジュールがオーバーラップしてしまうのはけっこう当たり前。そう、テスト工程はみんなに食いつぶされます。
チームワークというか、他のチームとの連携ですな。うちのモジュールは大丈夫ですが何か？それはありえないので、こちらの問題ではないですが何か？原因の特定ができませんが何か？ひょえ～。これは結合テストだけじゃなくて、開発チーム・テストチームという関係でもありそう。
| 固定リンク | コメント (0) | トラックバック (0)
結婚式の招待状が出来上がってきた。けっこう重たいなあ。
==
本屋さんで目当ての本がなくて、ちょいとマンガチックな本を買ってきた。
SEという人たちはこんな生態ですよ～、みたいなエッセイ。SEと一口に言ってもいろいろな人や業種や会社があるので、当たらずとも遠からず、といった印象だったけれど、休日に読むにはちょうどいいかな。アットマークアイティの4コママンガもけっこう暇つぶしに読んでますが、それに似た感じ。
聞いたことあるかも。これって中学や高校の数学の問題を解くのとおんなじで、コードを書く人は例外もあるだろうけど、たいていはエレガントな解法を欲してしまう特性があるんだろうね。テストを専門にしている方々ももしかしたら同じようなことがいえるのかな。どれだけ少ない負荷・労力で、どれだけ高品質・網羅されたテストを設計・実施・管理するか。みたいな。
コーディングの癖は誰にでもあって、同じ人でも時期によってブームがある（と、僕は思っている。僕がそうだ）。たいていC言語で実装しているので、例えば変数名だとか、関数名だとか、ソースファイル名だとか、よくある癖だったり、設計に絡んだ癖もある。復帰値の型の癖。構造体の名前の癖。コメントの癖。バージョン管理システムへのcommitタイミングの癖。etc
今の自分のブームは、やっぱりテスト（動的テスト）がしやすいように実装すること。かな。本の中でも言及されているが、
その会社では、設計がアバウトで許されていたこともあったけれど、試験などはさらに輪を掛けたアバウトさであった。正直なところ、「試験」というよりも「動作確認」と言った方が実状に沿っていたのだ。（中略）
実際のところ、本当にめんどくさい試験というのは、ソースコードレベルまでを精査するホワイトボックス試験なのだ。
（中略）
そうすると、じゃあせめて楽になるようにと、ひとつひとつの関数をコンパクトにしたり、各分岐条件をシンプルで読みやすいものにしたりするようになった。いつしか、「試験することを前提としたコードの書き方」に変容していったわけである。
「ホワイトボックス試験」もそうだし、「試験することを前提とした～」もそうだし、知識としては本を読んだり、ネットを調べたり、先輩に聞いたりするとわかることだが、実際に自分が必要になったときに得られる知識であれば、なおさら血になり肉になりやすいのかな。はやりの「リファクタリング」ってのはこれとは少し違うものなのかな。
| 固定リンク | コメント (0) | トラックバック (0)
Operaの最新版がでました。僕はOpera使いです。スピードダイヤルいいね～
==
会社の人に教えてもらった。開発の現場Vol8はテストだらけだ！
総論編（1）テストの重要性と最新潮流／細川宣啓
（2）ソフトウェアテストの基礎知識／坂本直紀
本編［計画作り］ コストと品質のグッドバランスを実現するテスト計画作成法／小笠原記子
［進め方］ 結合テストを見据えたリーダーのためのテスト調整術／梅田明由＋菊地哲弥
［ドキュメント作成］ テストドキュメントの鉄則／川上文夫
［自動化］ テスト自動化ツールとの付き合い方とその活用術／木下史彦
［テスト前テスト］ CIで効率アップ＆品質向上を目指せ／江川崇
［コード品質アップ］ テストで高めるコード品質／竹田正和
［テストファースト］ テストドリブン開発を実現するための現実解／後藤章一リポート
JaSST’07「定番っ！ テスティングライブ2007」／編集部
リファレンス
ソフトウェアテスト“お役立ち”ツールガイド／編集部
（中略）
【特別記事】
もう悩まない！ 開発プロセスの作り方／正木威寛＋山内奈央子
「JSTQB認定テスト技術者試験」誌上セミナー
／大西建児＋勝亦匡秀＋町田欣史＋湯本 剛＋吉澤智美【連載】
目指せ！デキるプログラマ“ かんたん実践”テスト術／秋元香那
“これで納得！”ストーリーで考える「見積り」の勘所／中村秀剛
コーディングの掟／arton＋宇野るいも
全国の“開発の現場の声”よ、来たれ！／砂塚利彦
2ページでわかる隣の芝生／國方則和＋安達茂之
“ソフトウェア芸人”矢沢久雄の現場／矢沢久雄
個人的には、「結合テストを見据えた～」と「テストドキュメントの鉄則」に興味アリ。
| 固定リンク | コメント (0) | トラックバック (0)
この前の社外勉強会で紹介されていた古典であり、名著。
僕もさっそくamazonで購入。読めばパラダイムシフトするって。トム・デマルコって「熊とワルツを」の作者だ。
今日はこれだけ。
| 固定リンク | コメント (0) | トラックバック (0)
書籍の紹介だけじゃなく、勉強の成果も出さなくちゃ勉強室の名折れだ・・・
==
ソフトウェアテストPRESSの最新号が出るようです。1/30発売。この雑誌はだいたい半年に1回の割合で出版され、今までには単体テスト、直交表、テスト管理ツール、自動テストツールなどがテーマでした。また、年明けに出版される号はJaSSTとリンクしてることが多いみたい。
| 固定リンク | コメント (0) | トラックバック (0)
3月に第2回JSTQBの試験がありますね。それにあわせてか、教科書が出るようです。
発売日は2/8なのでもう少し先。試験を受けようと思う方には強い味方になるかも。僕も3月受験予定なので買ってみるかな。
==
演習問題であればこちらもコンパクトかつお手ごろ。実践的ではないけれど、これだけでも勉強になるね。
| 固定リンク | コメント (0) | トラックバック (0)
ソフトウェア関連の特集があったので。
==
ソフトウェアテストで「敗北」するときのポイントである「有効打の不足」 「時間切れ」についての記事が載っている。各工程でのすすめ方とか、各技法についての詳細な記事ではないが、どの工程でどんなテストをしたらいいか、どんなテストの記述方法があるのか、などの概論がまとめられている。
直交表についても少し載っていたが、「単体テストで実施済み」というのは「単機能テストで実施済み」と同義ってことかな。
| 固定リンク | コメント (0) | トラックバック (0)
テスト駆動型開発について知識不足なので買ってみた。JUnitではレッドとグリーンとリファクタリングという3つのキーワードがあるらしい。Cの単体テストにもその色をあててみようかな。
| 固定リンク | コメント (0) | トラックバック (0)
ココログフリーメンテナンスが終了しています。
==
うちの会社では特にC言語によるコーディングが多いが、作法やルールは特になかった。ので、この本を使って何か品質向上活動をしようかと。ななめ読みではあるが、基本的なこと（変数初期化や例外処理の記述など）から特殊なことまで、あるいは信頼性、移植性、保守性といったカテゴリーに分けられていて、必要そうなものだけピックアップして自分のプロジェクトに使うといいかな。
| 固定リンク | コメント (0) | トラックバック (0)
先ほどの本に続いて、ポケットブックではなくきちんとした書籍も購入。
こちらについてはまだamazonから届かないので、届き次第のレビューということに。
| 固定リンク | コメント (0) | トラックバック (0)
JSTQBという認定試験があり、基礎的な知識を確認するためにはよい試験かと思ったので、勉強して受験してみようかと。ということで少し軽めの問題集みたいな本を購入。
分厚くもなく、要点をおさえておけてなかなか使いやすい本ですね。演習問題は全くひねりはなく本当に自分の学習度を測るのが目的であれば使えます。カバンに入れておいて電車とかで読もうと思います。これを読んでみると今までの僕のブログでの用語の使い方は統一性もなく、お恥ずかしい限り。。。そこらへんも注意してこれから記事を書いてみようっと。
| 固定リンク | コメント (0) | トラックバック (1)
直交表についてもう少し深い理解をしようと思って、購入。お値段も手軽でグッドです。ソフトウェア・テストPRESSでも直交表・ダミー水準・多水準化といった手法を載せてたけど、こちらはもう少し理論の裏づけを交えながらの解説でした。ベクトルを持ち出すことで直交という概念がより数学的になっている気がします。ちなみに、タイトルからわかるようにメインとなるのは「実験計画」の手法なので、ソフトウェアテストのテストケース作成には必要ない情報も含まれます。
キーワード：実験計画法, ラテン方格, グレコ・ラテン方格, 超グレコ・ラテン方格, 直交表, 主効果, 交互作用,
線点図, 擬水準, 2乗化
| 固定リンク | コメント (0) | トラックバック (0)
7月に発売されたソフトウェア・テストPRESS Vol.3は、テストの自動化やWebアプリのセキュリティソフトについての特集。
自分のプロジェクト専用のテストツールが必要だ、っていうのが最初のきっかけで、ソフトウェアテストや品質工学に興味を持ち出したのだ。Vol.3では自動化のためのテストツールの紹介などがメインでされている。
その他にもマインドマップを使ってテストケースを作成する手法も紹介されていて、経験の浅いメンバーにはこういうアプローチでテスト設計を伝えればいいんだなあと勉強になりました。
# もちろん、マインドマップを使うにもまずはコツが必要ですが。
==
| 固定リンク | コメント (0) | トラックバック (0)
テスト専門誌。内容はというと、上流工程でのインスペクションや直交表による組み合せテストの手順など。HAYST法による水準数拡大の手順も詳しく掲載してあって、Goodですな。うちの開発チームでもこのHAYST法を改良して、活用していこうと動き中。
ちょうどこのVol.2が出てすぐに JaSST '06 Tokyo があって、内容がかなりかぶってた。
==
| 固定リンク | コメント (0) | トラックバック (0)
昨年創刊したテスト専門誌。
創刊号は主にテスト設計の意義やテスト手法についての解説が多く、ゼロからはじめる人向けか。
- ホワイトボックステスト
- ブラックボックステスト
- 同値分割
- 境界値分析
- エラー推測
これが創刊された当初はまだまだ僕もヒヨコちゃんだったので、2号3号がでるのがすごい楽しみだったな。
==
| 固定リンク | コメント (0) | トラックバック (0)
HAYST法 | JSTQB | pairwise・All-pair法 | TestLink | おすすめサイト | ウェブログ・ココログ関連 | グレーボックステスト | コーディング規約 | セミナー | ソフトウェアテスト | ソフトウェア品質 | タグチメソッド | チームビルド | テスト設計 | テスト関連ツール | テスト駆動型開発 | デシジョンテーブル | データフローテスト | ニュース | マインドマップ | レビュー・インスペクション | 例題 | 分析 | 勉強会 | 単体テスト | 原因結果グラフ | 品質工学 | 学問・資格 | 書籍・雑誌 | 状態遷移テスト | 直交表 | 結合テスト | 趣味 | 雑記
最近のコメント