第2回JSTQB認定テスト技術者資格 試験結果

JSTQB認定テスト技術者資格の試験結果が出てます。僕も受験しててとりあえず合格しててよかったー。合格率は６０％超でした。

[書籍]結合テストを見据えたリーダーのためのテスト調整術

雨降って社内フットサルチームの活動は中止。ザンネン～

==

先日購入した開発の現場（ほぼソフトウェアテストPRESS）を読んでみた。

先日までの自分のプロジェクトでは結合テストでもーう少しうまくできたなあ、と思ってて、「結合テストを見据えたリーダーのためのテスト調整術」という記事が一番気になってました。

単体テスト、不足してませんか

単体テストって意外に気合入れてやらないことが多いって話。テストじゃなくて、動作確認、ってレベルで終了しちゃうとか。単体テストでのテスト仕様書を実装前に作る、って書いてあるけど、それがモチベーション向上につながるかというと、そうじゃないケースもありそう。個人的には「面白い」「楽しい」「見てすぐわかる」を目指したい。コードカバレッジの可視化ってけっこう楽しいし、成果が眼に見えていいと思う。

テスト準備、できてますか

テスト環境の準備やテストデータの準備ってほったらかしちゃうね。でも、これがないとテストはできないし、いざってときに準備されていないと、テストのリズムが悪い！

障害管理・インシデント管理、できてますか

これはほとんどのプロジェクトでやっているでしょう。ごく小規模であったり、単体テストでは実施しないこともあるけど。

スケジュール、オーバーラップしてませんか

プロジェクトによっては単体テストと結合テストを一緒にする、といったことはあるけど、いつの間にかスケジュールがオーバーラップしてしまうのはけっこう当たり前。そう、テスト工程はみんなに食いつぶされます。

チームワーク、とれてますか

チームワークというか、他のチームとの連携ですな。うちのモジュールは大丈夫ですが何か？それはありえないので、こちらの問題ではないですが何か？原因の特定ができませんが何か？ひょえ～。これは結合テストだけじゃなくて、開発チーム・テストチームという関係でもありそう。

[書籍]SEのホンネ話―会社じゃ言えない

結婚式の招待状が出来上がってきた。けっこう重たいなあ。

==

本屋さんで目当ての本がなくて、ちょいとマンガチックな本を買ってきた。

SEという人たちはこんな生態ですよ～、みたいなエッセイ。SEと一口に言ってもいろいろな人や業種や会社があるので、当たらずとも遠からず、といった印象だったけれど、休日に読むにはちょうどいいかな。アットマークアイティの4コママンガもけっこう暇つぶしに読んでますが、それに似た感じ。

p17　プログラマは芸術家？

聞いたことあるかも。これって中学や高校の数学の問題を解くのとおんなじで、コードを書く人は例外もあるだろうけど、たいていはエレガントな解法を欲してしまう特性があるんだろうね。テストを専門にしている方々ももしかしたら同じようなことがいえるのかな。どれだけ少ない負荷・労力で、どれだけ高品質・網羅されたテストを設計・実施・管理するか。みたいな。

p105　コーディングスタイルを決めるモノ

コーディングの癖は誰にでもあって、同じ人でも時期によってブームがある（と、僕は思っている。僕がそうだ）。たいていC言語で実装しているので、例えば変数名だとか、関数名だとか、ソースファイル名だとか、よくある癖だったり、設計に絡んだ癖もある。復帰値の型の癖。構造体の名前の癖。コメントの癖。バージョン管理システムへのcommitタイミングの癖。etc

今の自分のブームは、やっぱりテスト（動的テスト）がしやすいように実装すること。かな。本の中でも言及されているが、

その会社では、設計がアバウトで許されていたこともあったけれど、試験などはさらに輪を掛けたアバウトさであった。正直なところ、「試験」というよりも「動作確認」と言った方が実状に沿っていたのだ。

（中略）

実際のところ、本当にめんどくさい試験というのは、ソースコードレベルまでを精査するホワイトボックス試験なのだ。

（中略）

そうすると、じゃあせめて楽になるようにと、ひとつひとつの関数をコンパクトにしたり、各分岐条件をシンプルで読みやすいものにしたりするようになった。いつしか、「試験することを前提としたコードの書き方」に変容していったわけである。

「ホワイトボックス試験」もそうだし、「試験することを前提とした～」もそうだし、知識としては本を読んだり、ネットを調べたり、先輩に聞いたりするとわかることだが、実際に自分が必要になったときに得られる知識であれば、なおさら血になり肉になりやすいのかな。はやりの「リファクタリング」ってのはこれとは少し違うものなのかな。

[書籍]開発の現場 vol.008

Operaの最新版がでました。僕はOpera使いです。スピードダイヤルいいね～

==

会社の人に教えてもらった。開発の現場Vol8はテストだらけだ！

総論編

　　（1）テストの重要性と最新潮流／細川宣啓
　　（2）ソフトウェアテストの基礎知識／坂本直紀
本編

　　［計画作り］ コストと品質のグッドバランスを実現するテスト計画作成法／小笠原記子
　　［進め方］ 結合テストを見据えたリーダーのためのテスト調整術／梅田明由＋菊地哲弥
　　［ドキュメント作成］ テストドキュメントの鉄則／川上文夫
　　［自動化］ テスト自動化ツールとの付き合い方とその活用術／木下史彦
　　［テスト前テスト］ CIで効率アップ＆品質向上を目指せ／江川崇
　　［コード品質アップ］ テストで高めるコード品質／竹田正和
　　［テストファースト］ テストドリブン開発を実現するための現実解／後藤章一

リポート

　　JaSST’07「定番っ！ テスティングライブ2007」／編集部

リファレンス

　　ソフトウェアテスト“お役立ち”ツールガイド／編集部

（中略）

【特別記事】

　　もう悩まない！ 開発プロセスの作り方／正木威寛＋山内奈央子
　　「JSTQB認定テスト技術者試験」誌上セミナー
　　　／大西建児＋勝亦匡秀＋町田欣史＋湯本 剛＋吉澤智美

【連載】

　　目指せ！デキるプログラマ“ かんたん実践”テスト術／秋元香那
　　“これで納得！”ストーリーで考える「見積り」の勘所／中村秀剛
　　コーディングの掟／arton＋宇野るいも
　　全国の“開発の現場の声”よ、来たれ！／砂塚利彦
　　2ページでわかる隣の芝生／國方則和＋安達茂之
　　“ソフトウェア芸人”矢沢久雄の現場／矢沢久雄

個人的には、「結合テストを見据えた～」と「テストドキュメントの鉄則」に興味アリ。

TIBCO General Interface Test Automation Kit 0.7（GITAK）

朝の投稿。

==

「超高速、完全自動、しかもフリー」 WebテストツールのGITAK公開
TIBCO Developer Network

※Codezineの画像を引用

見た目はSeleniumに似ているようだが、少し使ってみようかな。

==
#2007/04/06追記。

General Interface Test Automation Kit: User Guide（PDF）

TIBCO General Interface Test Automation Kit is developed using the Selenium test tool. Selenium, an open-source tool by Thoughtworks developers, is an embedded browser script framework that works in Internet Explorer, Mozilla, Firefox, and Safari.

なんだー、コアはSeleniumなのか。

[セミナー]第26回ソフトウェア品質シンポジウム

ココログがモバイル対応したようだ。

==

日科技連主催の品質シンポジウムだ。投稿できるくらいになりたいぜ。

第26回ソフトウェア品質シンポジウム　～テーマ「もう品質で悩まない！」
http://www.juse.or.jp/software/symposium_26spcs_cfp.html

近年、リコール・事故を耳にすることが増えるにつれ、さらに品質の重要性を感じることはないでしょうか。本年度は、今まで以上に“ソフトウェア品質に関する悩み”を解決するためのヒントやアイデアが得られる場になることを目指し、実践的な事例の投稿がしやすくなるように「経験論文」と「経験発表」の2つのパターンを用意しました。いずれもアブストラクトの段階で採録のための査読を行います。

●発表スケジュール（予定）
　2007年4月23日(月)：発表申込み（「経験論文」「経験発表」アブス トラクトの提出）
　2007年5月 7日(月)：採否通知
　2007年6月 7日(木)：「経験論文」原稿締切
　2007年7月11日(水)：「経験論文」査読結果通知
　2007年8月 8日(水)：カメラレディ原稿締切
　（「経験論文」「経験発表」資料）
●日　程：9月6日(木)～7日(金)
●会　場：東京・東洋大学
●参加費：5,250円（発表者のみ）（税込み）（一般参加費39,900円のところ）
●申込先／問合わせ先：
　財団法人日本科学技術連盟　事業部クオリティマネジメント一課
　ソフトウェア品質シンポジウム担当
　 TEL.03-5378-9813　FAX.03-5378-9842　E-mail:spc-sympo@juse.or.jp

▼詳細、セミナーお申込についてはこちらから

新年度だ 静的テストだ

ずいぶんと間を空けてしまった。現在は少しずつ本を読んでるところ。今年に入って動的テストばっかりだったので、心機一転静的テストとかに目を向けようかな。レビューとかインスペクションって有名な本がけっこうあるけど、読んだことないや。まずは何を読んでみたらいいんだろうか。

事前の自己レビュー

レジュメ

機能のポイント

実装のポイント

リスク（プロダクト）のポイント

テストのポイント

テスト方法

思いついた単語を並べてみただけ。

==
2007/04/05追記。
静的テストといっても、新規システム開発、バグ修正、エンハンスで手法もかわってくる。列挙したのはバグ修正やエンハンスをイメージして書いた。