WACATE-Magazineの第7号が発行されました。メインとして、6月に開催された「WACATE 2009 夏」の詳細なレポートが大ボリュームで掲載されていたり、30ページを超えた読み応えのあるマガジンです。
また、今回は「勉強会のモデレータをやってみよう！」という記事を書かせていただきました（全3回予定）。勉強会ブームなのでいろいろなところに勉強会のノウハウが公開されていますが、僕なりのノウハウを書いてみました。
| 固定リンク | コメント (0) | トラックバック (0)
今日はフェデラーだ！
==
システム開発ジャーナル Vol.10
システム開発ジャーナル、今回の特集は「エンジニアのためのソフトウェアテスト術」です。最近ディベロッパーズテスティングという言葉がよく見られるようになった気がします。
| 固定リンク | コメント (0) | トラックバック (0)
先週末、三浦海岸で開催された「WACATE 2009 夏」が無事終了。のちほど、実行委員会のレポートがでることでしょう。
参加者によるレポートもトラックバックで受け付けてます。
WACATE（ソフトウェアテストワークショップ）
http://wacate.jp/
WACATE 2009 夏
http://wacate.jp/2009/summer/
WACATE 2009 夏 参加者レポート集
http://wacate.jp/2009/summer/reports.html
| 固定リンク | コメント (0) | トラックバック (0)
WACATE 2009 夏 の参加申し込みが始まりました。今回から年齢制限なしで受付開始です（前回までは若手優先で受付）。
WACATE（ソフトウェアテストワークショップ）
http://wacate.jp/
WACATE 2009 夏 開催概要
http://wacate.jp/2009/summer/
WACATE 2009 夏 プログラム
http://wacate.jp/2009/summer/program.html
WACATE 2009 夏 参加申込
http://wacate.jp/entry/
| 固定リンク | コメント (0) | トラックバック (0)
WACATE-Magazineが発行されてます。6月に開催されるWACATE 2009 夏の情報や、ソフトウェアテスト関連資格の記事も充実してますね。
| 固定リンク | コメント (0) | トラックバック (0)
若手エンジニア向けワークショップWACATEの開催予告がでました。
WACATE（ソフトウェアテストワークショップ）
http://wacate.jp/
WACATE 2009 夏 ～はじめてみようテストレビュー（仮）～
http://wacate.jp/2009/summer/
今回のテーマは「レビュー」です。クロージングセッションは細川宣啓氏（日本IBM）だそうです。これは楽しみ。
以下、TEFメーリングリストに投稿されたものをご紹介。
----------------------------------------
WACATE(Workshop for Accelerating CApable Testing Engineers)
・・・若手テストエンジニアを中心に企画された、若手テストエンジニアのためのワークショップです。2007年年末に第一回を開催して以来、多くの方々に支えていただき、2008年年末で一周年を迎えることができました。これからも、より若手が主体的に活動できる場の創出を目指し、実行委員一同精進していく所存でおります。
さて、今回ご案内する2009年のWACATE夏ですが、今回は、
「夏だ！海だ！レビューだぁ！？」
ということで、ソフトウェアテストにおけるレビューをテーマに取り組みます。
皆さんの現場で、このような経験はありませんか？
・レビューミーティング当日にいきなりドキュメントを配布されて、読む
だけで終わってしまった
・レビューは1回きりで指摘事項を反映した後のチェックは行っていない
・レビューの種類がいくつかあるのは知っているけど違いがよくわからない
などなど・・・
これらの様々な悩みについて、二日間にわたるチーム演習と参加者間の交流を通して解決の糸口を掴んでみませんか？
夏の方針は「狭く深く」。
夏の日差しに負けない、熱い想い持った方々の参加をお待ちしております！
また、二日間の最後を締めくくるクロージングセッションは、レビューの分野でご活躍の細川 宣啓氏（日本IBM）をお迎えする予定です。
そして、毎回参加者の方が楽しみにしておられる会場ですが、今回は、夏らしく海に飛び出します！
海の幸を堪能しつつ、テスト話を酒の肴に盛り上がるもよし、温泉にゆったりつかりながらテストについて深く語り合うもよし、海に向かってテストへの熱い想いを叫ぶもよし！！まさに臨海学校のような、あの「わくわく感」を三浦で体験しましょう！
なお、本ワークショップは若手中心となっておりますので、前回同様若手の参加を優先させていただく予定ですが、ベテランが持つ知見の継承を行う場としてもご活用頂きたく、幅広い層の方々に参加いただけるとありが
たく思います。また、若手の気持ちを持ったベテランの方々の参加も歓迎しております。
＜＜開催概要＞＞
WACATE 2009 夏 ～はじめてみようテストレビュー（仮）～
主 催： WACATE実行委員会
日 時： 2009年6月13日（土） 9:45 受付開始（予定）
～ 2009年6月14日（日） 16:30 終了（予定）
（1泊2日 4食付）
会 場： マホロバ・マインズ三浦
（神奈川・京浜急行三浦海岸駅徒歩5分）
http://www.maholova-minds.com/
＜＜協賛＞＞
NPO法人 ソフトウェアテスト技術振興協会（ASTER）（予定）
＜＜合宿費＞＞
現在、\22,000前後を予定しています。
（宿泊費、宴会費、14日朝食、13日14日昼食、会場費などの運営費含む）
※前回からの増額分\2,000は13日14日の昼食代を含むため。
参加費は開催当日受付にて現金でお支払いいただき、引き換えに領収書を
発行いたします。
＜＜プログラム＞＞
13日9時45分受付開始（10時15分開会）、14日16時30分ごろ終了予定です。
プログラム内容の詳細につきましては、WEBにて随時更新いたします。
→ http://wacate.jp/
＜＜参加募集人数＞＞
先着合計42名を予定しております。
＜＜参加受付＞＞
一般参加受付は5月11日（月）を予定しております。
＃一般参加受付に先駆けて、2009/4/18開催のWACATE Short Short vol.1
にて、当日の参加者限定の先行受付を行います。どうぞご検討ください。
→ http://wacate-ss.coresv.com/
＜＜13日の宿泊について＞＞
13日の宿泊は相部屋となります。
＜＜参加にあたっての注意点＞＞
・WACATEはスポンサーを募らない、完全な有志によるイベントです
参加ドタキャンが発生すると実行委員会の自腹負担になってしまいます。
つきましては、当日確実にご参加いただける方のみ、参加受付をお願い
いたします。
・WACATEは若手エンジニアが主役です
ベテランは若手を尊重してください
・WACATEはセミナーの類ではありません
参加者全員が参加し、勉強し、楽しむことが重要です。自ら学ぶ態度で
ご参加ください。教えてもらうのが当たり前と考える方や、評論家を気
取る方は参加をご遠慮ください。
＜＜参加にあたってお持ちいただくもの＞＞
・参加費（受付時にお支払いいただきます）
・筆記用具一式（演習で使用します）
・PC（演習時あると大変便利です。また、成果物をお持ち帰りいただけます）
・名刺（受付時の本人確認と当日の名札として使用します）
＜＜問い合わせ先＞＞
WACATE 2009 夏 についてのお問い合わせは以下にお願いします。
query@wacate.jp
＜＜実行委員会＞＞
実行委員長
池田 暁 （日立情報通信エンジニアリング）
副実行委員長
山崎 崇 （WACATE実行委員会）
実行委員
安達 賢二 （WACATE実行委員会）
加瀬 正樹 （WACATE実行委員会）
加文字 諭 （電気通信大学大学院）
河野 哲也 （電気通信大学大学院）
小山 竜治 （WACATE実行委員会）
澤田 悠介 （WACATE実行委員会）
武市 喜博 （WACATE実行委員会）
西 康晴 （電気通信大学）
坂 静香 （WACATE実行委員会）
村上 くにお （WACATE実行委員会）
森 孝夫 （WACATE実行委員会）
アドバイザ
猪股 宏史 （WACATE実行委員会）
----------------------------------------
| 固定リンク | コメント (0) | トラックバック (0)
昨日、勉強会があって、原因結果グラフを作成する宿題が出ました。そのうちの1問はこちら。
JR乗車券類の誤購入の場合の取扱方
第293条
1 旅客が、誤つてその希望する乗車券、急行券又は特別車両券と異なる乗車券、急行券又は特別車両券を購入した場合で、その誤購入の事由が駅名の同一・類似その他やむを得ないと認められ、かつ、係員がその事由を認めたときは、正当な乗車券、急行券又は特別車両券に変更の取扱いをする。
ただし、指定急行券及び指定特別車両券については、この取扱いをしない。
2 前項の場合は、既に収受した旅客運賃、急行料金又は特別車両料金と正当な旅客運賃、急行料金又は特別車両料金とを比較し、不足額は収受し、過剰額は払いもどしをする。
今回の勉強会で学んだ、
「乗車券、急行券又は特別車両券」・・・これはA,B,orC＝AorBorCという意味のはず。なので、同じような表現である「旅客運賃、急行料金又は特別車両料金」も同じ。
僕が作ってみた解答はこちら。
で、今回の勉強会では登場しなかったのですが、制約条件を付けてデシジョンテーブルにしてみるとこちら。
でも、よく見ると「差額がゼロ円という」ケースがテストされていない。。。どこで間違えたかしら。
| 固定リンク | コメント (2) | トラックバック (1)
目黒雅叙園で開催中のJaSST'09Tokyoの初日レポートが早速でてました。基調講演のプレスマン氏の記事ですね。
| 固定リンク | コメント (0) | トラックバック (0)
昨年9月に行われた「ソフトウェアテストセミナー」は追加募集などもあり、大盛況でした。そして今年もやるようです！主催が技術評論社でもあり、ソフトウェア・テストPRESS（Vol.8）とのコラボレーションもありそうですね。また、辰巳さんの歴史のお話はアブストを読むだけでも興味がわいてきます。
名 称： 第2回ソフトウェアテストセミナー
日 程： 3月11日（水）
時 間： 11：00～18：10
場 所： 東京コンファレンスセンター（アクセス：品川駅より徒歩2分）
定 員： 150人
参加費： 無料
URL ： http://gihyo.jp/event/2009/test
主 催： 株式会社技術評論社
問い合わせ： ソフトウェアテストプレスセミナー2009事務局
〒162-0846
東京都新宿区市谷左内町21-13
TEL：03-3513-6165 FAX：03-3513-6167
Email：
協 賛： コベリティ，東陽テクニカ，日本オープンシステムズ，パソナテック
エントリーはこちら
http://gihyo.jp/event/2009/test/entry
| 固定リンク | コメント (0) | トラックバック (0)
デブサミが2月12日、13日に開催。場所はJaSSTと同じく目黒雅叙園。
つなぐ、つながる、そして未来へ
Developers Summit 2009
技術者コミュニティとの連携から生まれた総合ITコンファレンス
http://codezine.jp/devsumi/2009/
開催概要
名称 Developers Summit 2009（デブサミ2009）
名称 2009年2月12日（木）・13日（金）
会場 目黒雅叙園（東京・目黒）
主催 株式会社 翔泳社
お勧めする方 技術者、ソフトウェア開発者、システム開発者、ネットワーク管理・運用者、IT教育担当者、ITマーケティング・セールス担当者、IT関連部署マネージャ、プロジェクト関連マネージャ
2日目は1トラックがテスト関連ですね！
| 固定リンク | コメント (0) | トラックバック (0)
テストPRESSの最新号が1月末でますね。個人的な注目としては「WACATE」についての記事と「CFD法の極意 前編」の記事でしょうか。
ソフトウェア・テスト PRESS Vol.8
| 固定リンク | コメント (0) | トラックバック (0)
状態遷移図を工夫してみるの続き。
コメント欄にて教えていただいた「機能図式」を自分なりに少しまとめてみて、そのあとで例題に適用してみようと思います。
機能図式とは、ソフトウェア機能仕様を
では、メール一覧のアプリを例にとって実際に機能図式を作ってみる。
仕様を箇条書きでまとめると、以下のようなアプリケーションです。
このメール一覧のアプリを機能図式で表現すると、まずは状態遷移部がこのようなグラフとなる。
また、論理関係部はこのようなテーブル（決定表）となる。
決定表の各列にはパス名としてPxxを名付けてみました。
テスト経路作成基準は論文中では「全遷移を少なくとも1回、ループについては0回と1回の2通りを実現する」とある。論文には具体的なテスト経路作成アルゴリズムも紹介されているが、まだ消化不良なので、今日はここまで。
| 固定リンク | コメント (0) | トラックバック (0)
簡単な状態遷移図を作ってみるの続き。
メールソフトを起動するときに、メールがある場合とない場合で初期画面が異なります。この部分についての状態遷移図はどうやって作るか。僕の場合は観測できない状態を１つ用意して、内部イベントの違いによって遷移を分ける方法をとっている。
実際には「メールが5通以下」「メールが6通以上（すなわち、次リンクが表示される）」「メールがない」の3パターンが考えられるので、「S1→(S2)→S3」「S1→(S2)→S4」「S1→(S2)→S5」の3パスが表現できる状態遷移図を作成。ここでは観測できない状態S2を終了状態にはできないので、実際のテストケースを作成するときには、少し注意が必要。
ただし、分岐条件が複雑になった場合はこの手法だけでは難しくなってくる。たとえば、「インストール後最初の起動時にはお知らせ画面を表示する」とか、「未読メールがある場合はその旨を通知するダイアログを出す」とか、そういった仕様があったとすると、どうします？
そこで「機能図式」という考え方へ進んでいきます。続く～。
| 固定リンク | コメント (0) | トラックバック (0)
状態と遷移とイベントとアクションの続き。
具体的に状態遷移図を作ってみますかね。一つ目は比較的シンプルなもの。
状態は「電源OFF」「電源がONで、強さが弱」「電源がONで、強さが強」の3つ。イベントは「電源ボタンを押す」「強さボタンを押す」の2つ。
では、こちらはどうでしょうか。
上の図はメールソフトの起動時のみを表現したものです。が、状態遷移図は、状態とイベントが一つ決まれば遷移先の状態とアクションも決まる、はず。でも、この図を単純に状態遷移図にしたら、ちょっとへんですね。左の状態では「次>>」というイベントが可能ですが、左の状態では不可能のようです。みなさんは、どんな状態遷移図を考えますか？
| 固定リンク | コメント (0) | トラックバック (0)
状態遷移モデルを使ったソフトウェアテストを勉強するためのテキストとしてボーリス・バイザーの「ソフトウェアテスト技法」「実戦的プログラムテスト入門」などを読んでみた。手順の最初に出てくるのが、仕様書からの状態とイベントの洗い出し作業。そもそも状態遷移図や状態遷移表を作ることって設計工程のツールなので、上流工程でのこういった作業が作りこみを減らすことにつながる。
で、ソフトウェアテスト技法のほうで状態の数を探るところ（第11章 4.2）があるのだけれど、具体例としてエンジンを題材にして、
ギア （R、N、1速、2速、3速、4速） ＝ 6要素
進行方向 （全身、後退、停止） ＝ 3要素
エンジン （動作中、停止） ＝ 2要素
トランスミッション （正常、異常） ＝ 2要素
エンジン （正常、異常） ＝ 2要素
合計 ＝ 144要素
という記述がある。ここでいっている不可能な状態への考察って、禁則の考え方じゃないのかしら？だとすると、HAYST法を使って状態を絞り込むことができるのかな。ただ、本質的には同じことだけどHAYST法（＝直交表）の特徴である、「どの条件も同じ程度出現する」というのはいらないので、pairwise法のほうが状態数が少なくなるのかな。
ソフトウェアテスト技法―自動化、品質保証、そしてバグの未然防止のために
実践的プログラムテスト入門―ソフトウェアのブラックボックステスト| 固定リンク | コメント (2) | トラックバック (1)
状態遷移図や状態遷移表を使う場合（ここでは状態遷移モデルを扱う、と同義）に、まずは構成要素である「状態」「遷移」「イベント」「アクション」を確認しておこう。
状態とは、状態遷移モデルでも通常の言葉と同様の意味で使われ、「システムの当分の間の状況と特性」というとらえ方をする。基本的な考え方としては状態は同時にはただ一つしかありえない。排他型と並列型という状態のとらえ方もあるが、ここでは割愛する。たとえば、「電源がOFFである/ONである」「インターネットが切断状態である/接続状態である」「検索状態である/検索結果表示状態である」など。
遷移とは、ある状態からある状態へ状態が移り変わることを表す。たとえば、「電源が（電源ボタンを押したことで）OFF状態へ遷移する」「インターネットが（認証成功によって）接続状態へ遷移する」「（検索結果が確定して）検索結果を表示する」など。
イベントとは、遷移をもたらす外的刺激や内的変化などを表し、入力とも事象とも表現される。ひとつのイベントは一つの遷移を決定するが、それらはイベント発生時の状態によって変化する。場合によっては、イベントはシステムに関するものではなく、システムのユーザへの刺激で表現される。たとえば、「電源ボタンを押す」「接続の認証が成功する」「検索クエリーのレスポンスが確定する」「○○さんに連絡する用事が発生する」など。
アクションとは、遷移の結果生じる分析が可能な対象物を意味し、入力と対照的に出力とも表現される。混同されやすいが、アクションと遷移後の状態は区別される。ただし、出力も遷移後の状態も同じ名称で表現されることが多いのは確か。たとえば、「（電源がONに遷移して）ディスプレイが点灯する」「（接続の認証が成功して）アイコンが点滅する」「（検索結果が確定して）検索結果が表示される」などである。
さて、これらのうち「状態」「遷移」「イベント」を使って、状態遷移図と呼ばれるグラフを作成してみる。
一般的には、状態はマルで表現して、中に状態名を記述する。ただし、必要なのはモデルであるため便宜上はS1,S2などと記載される。遷移は矢印で表現され、始点は遷移前の状態と、終点は遷移後の状態と接している。イベントは状態同様にE1,E2などで省略され、対応する遷移（矢印）のそばに記述する。
あれ、アクションがでてきません。アクションは状態遷移表で記述しましょう。今日はここまで。
| 固定リンク | コメント (0) | トラックバック (0)
SEのためのソフトウェアテスト再入門 第1回「あなたのテスト、単なる動作確認になっていませんか？」
「どんなテストケースを書いたらよいか分からない」「自分のやっているテストに自信が持てない」そんな悩みをお持ちの方は多いのではないでしょうか。テストは、技術や経験を必要とするたいへん奥の深い世界です。この連載では、皆さんが今後開発を行っていく上での、ヒントや指針となる「テストのマインド」を紹介していきます。
こんなサイトができていました。テストの意図は明確に。僕の中では「動作確認」と「テスト」は包含関係かなあ。
| 固定リンク | コメント (0) | トラックバック (0)
WACATE 2008 冬も無事終了したので、ここらへんで状態遷移テストについてちょこちょこ書いていこうっと。
ということで状態遷移テストで登場するカバレッジ基準をまとめてみる。具体例や図はのちほど。
| 固定リンク | コメント (0) | トラックバック (0)
若手テストエンジニア向けのワークショップWACATEの12月に開催されるワークショップの受付開始です。
WACATE 2008 冬 参加申込み
http://wacate.jp/entry/
ただし、現在は30歳以下限定で、11月10日に35歳以下、11月17日に36歳以上を含めた全員、という段階的な申込みです。僕は今年で31歳！ついに30歳以下でなくなってしまった。。。。。
今回のプログラム内容も随時更新されていますね。各セッション、演習には参考書籍が何冊か掲載されています。僕も読んでない本があったりするので、参考にせねば。
==
WACATE 2008 冬 ～自分が変われば、世界が変わる～
主 催： ソフトウェアテストワークショップ実行委員会（WACATE実行委員会）
日 時： 2008年12月20日（土） 9:00 受付開始（予定）
～ 2008年12月21日（日） 16:30 終了（予定） （1泊2日 2食付）
会 場： 水月ホテル鴎外荘（東京・JR上野駅徒歩10分）
http://www.ohgai.co.jp/
＜＜協賛＞＞
NPO法人 ソフトウェアテスト技術振興協会（ASTER）
＜＜参加費＞＞
￥20,000を予定しています。（宿泊費、宴会費、21日朝食、会場費などの運営費含む）
参加費は開催当日受付にて、現金でお支払いください。引き換えに領収書を発行いたします。
＜＜プログラム＞＞
20日9時受付開始（9時30分開会）、21日16時30分ごろ終了予定です。
プログラム内容の詳細につきましては、こちらをご覧ください（随時更新）。
＜＜参加募集人数＞＞
先着合計35名を予定しています。
＜＜参加受付＞＞
http://wacate.jp/entry/
＜＜20日の宿泊について＞＞
20日の宿泊は相部屋となります。
＜＜参加にあたっての注意点＞＞
・WACATEはスポンサーを募らない、完全な有志によるイベントです
参加ドタキャンが発生すると実行委員会の自腹負担になってしまいます。つきましては、当日確実にご参加いただける方のみ、参加受付をお願いいたします。
・WACATEは若手エンジニアが主役です、ベテランは若手を尊重してください
・WACATEはセミナーの類ではありません
参加者全員が参加し、勉強し、楽しむことが重要です。自ら学ぶ態度でご参加ください。
＜＜参加にあたってお持ちいただくもの＞＞
・参加費（受付時にお支払いいただきます）
・筆記用具一式（演習などで使用します）
・名刺（受付時の本人確認と当日の名札として使用します）
・夜の部の飲み物・おつまみ
・20日、21日の昼食代
＜＜問い合わせ先＞＞
WACATE 2008 冬 についてのお問い合わせは以下にお願いいたします。
query@wacate.jp
＜＜実行委員会＞＞
実行委員長
池田 暁 （日立情報通信エンジニアリング）
副実行委員長
山崎 崇 （WACATE実行委員会）
実行委員
加瀬 正樹（WACATE実行委員会）
加文字 諭 （電気通信大学大学院）
河野 哲也（電気通信大学大学院）
小山 竜治（WACATE実行委員会）
澤田 悠介（WACATE実行委員会）
武市 喜博（WACATE実行委員会）
西 康晴（電気通信大学）
坂 静香（WACATE実行委員会）
村上 くにお（WACATE実行委員会）
森 孝夫（WACATE実行委員会）
アドバイザ
猪股 宏史（WACATE実行委員会）
| 固定リンク | コメント (0) | トラックバック (0)
制御フローテスト、データフローテスト、トランザクションフローテスト、業務フローテスト。○○フローテストっていろいろあるけど、あんまりきちんと勉強したことがない。まずはデータフローテストを勉強してみようかと。同値分割や境界値分析はテストエンジニアが本能的に使ってたりするといいますが、このデータフローテストはレビュアーが本能的に使ってたりするのかなと思います。
（「本能的に使っている」ということが、どれほど危ういスキルなのはか、最近しみじみ思います＾＾；）
まずはGoogleで検索してみたが、1ページ目ではほとんど解説ページは検索できないです。ソフトウェアテスト関連書籍の目次なんかが多いですね。
ということなので、手元にはバイザー本があるのでそこからまず読みましょうかね。
| 固定リンク | コメント (0) | トラックバック (0)
テスト技法ポジショニングマップの目的本ポジショニングマップは、様々なテスト技法がみな有効でカバーしあっていることを示すことを目的としています。
自分自身のスキルたな卸し、プロジェクトへのテスト適用の目安など、いろいろ活用法がありそうですね。
| 固定リンク | コメント (0) | トラックバック (0)
かわいいサイト発見☆
第1回 "テスト"ってどんなイメージ? 2008-06-03
第2回 テストの目的と種類 2008-06-17
第3回 結合テストをする理由 2008-07-01
第4回 Seleniumの実行環境を作ってみよう 2008-07-15
第5回 Seleniumでのテストの記述方法 2008-07-29
第6回 UnitTestをする理由 2008-08-12
専門用語はわかりやすい言葉に置き換えたり、ストーリー仕立てだったり、キュートな画像があったり。Webアプリケーション開発者向けに、能動的にテストをすすめよう、目的を意識したテストをしよう、自動化してみよう、といった内容。具体例としてはPHP/Seleniumを主体とした解説だが、話の幹はシステム開発におけるテスト工程全般を意識している。テストの効率をあげるための技法（同値分割、境界値分析など）については言及されていないが、今後も続くみたいなのでそこに期待。
| 固定リンク | コメント (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)
ちょっと宣伝。若手テストエンジニアによる若手テストエンジニアのためのワークショップ（WACATE）のサイトが更新されました。
参加者はテストを専門とするエンジニアだけではなく、プログラマやマネージャクラスの方々も。こういった演習形式のイベントではいかに積極的に参加できるか、いかに多くの気づきを得られるか、そのあたりが重要。
12月20日～21日、興味のある方は予定を空けておきましょう！ガチンコ合宿の夏とは対象的に、冬は忘年会＆温泉だ！
| 固定リンク | コメント (0) | トラックバック (0)
思いがけずにこんなサイトを発見。
【レポート】エキスパートが薦める、夏期休暇に読んでおきたい書籍 - テスト/品質保証編
間もなく夏期休暇。まとまった休みを目前に控え、余った時間を知識に変えるための良書をお探しのエンジニアも少なくないだろう。本誌では、そうしたエンジニアの要望に応えるべく、数回にわたり、各分野のエキスパートが薦める書籍を紹介していく。今回、推薦を依頼したのは豆蔵 シニアコンサルタントの大西建児氏。10年以上にわたって品質保証活動に携わり、NPO法人 ソフトウェアテスト技術振興協会や財団法人 日本科学技術連盟のSQiP(ソフトウェア品質委員会)で活躍する同氏から、ソフトウェアテスト/品質保証の分野でお薦めの書籍をピックアップしてもらった。
豆蔵の大西氏による、品質保証・ソフトウェアテスト分野の「夏に読もう」的な書籍紹介。
ソフトウェアテスト293の鉄則ひゃ～まだ読んでない。どこかしこでもオススメ本として紹介されてますね。
ソフトウェア品質保証入門―高品質を実現する考え方とマネジメントの要点品質保証とは何たるかをABC的に教えてくれる良本です。僕自身も帰りの電車を待ってる間と電車の中で読みました。コンパクトさでいうと「293の鉄則」よりも持ち運びやすいと思います。感想については詳しくは、こちらを。
ゆとりの法則 \x{ff0d} 誰も書かなかったプロジェクト管理の誤解トム・デマルコの「ゆとりの法則」。見た目もそうだし、内容もそうだし、これが一番夏休み図書っぽい。ゆるゆるとまではいかないが、読み終えて少し時間を置いて頭の中で発酵させてから実践する、という意味で。
ステップアップのためのソフトウエアテスト実践ガイド (日経システム構築)個人的にはデスクにおいておきたい一冊ですが、実践的・泥臭い内容、著者の経験が読み取れる本ですね。
| 固定リンク | コメント (0) | トラックバック (0)
TEFの過去ログを1から見直そう、という活動が若手テストエンジニアの何名かで行われてます。僕のその「探検家」の一人ですが、今日は「レビュー設計」という言葉を見つけました。（設計レビューではないです）
テスト（あるいは動的テスト）という大きなアクティビティでは「分析」「計画」「戦略」「設計」「実装」「評価」というステップがありますが、レビューについてはそういったステップわけというをあまり聞いたことがありませんでした（ググってもあまり見かけないのでこの感覚は一般的かも）。過去ログを読みつつ、もんもんと考えていて、いくつか記事の中にもあったキーワード・ポイントを自分なりに整理してみました。
テスト設計というのは分析した結果を元に、たとえば、ここでは論理が複雑なのでデシジョンテーブルを使おう、そこでは状態遷移が複雑なのでk-スイッチテストを使おう、といった戦略をより詳細にブレークダウンしたもの。レビューというアクティビティも同型だと考えると、たとえば、このコードについてはメンバー内ピアレビューで、このドキュメントはインスペクションで、このコード群はコミット後コードレビューもやろう、といった作業かなと。レビュー指摘項目は、より細かい勘所という意識で「変数参照に着目せよ」とか「入出力周りに着目せよ」など。ガイドラインはどちらかというと「心構え」なのかなあと考えました。
検査は問題を指摘することで、レビューは知恵を出し合う場・議論、という考え方があった。これについては自分の中の定義と少しギャップがあった。もしかしたら、広義のレビュー＝検査（問題を指摘し、議論・解はのちほど）＋狭義レビュー（プレゼンテーションとディスカッション）、みたいなイメージのがしっくりくるかな。
「限られた時間で問題をどんどん指摘してもらう」という考え方と、せっかく知恵袋が集まってるんだから、レビュー対象（やレビュー対象作成者）を練って練って練りまくるという考え方。目的には違いがあるが、レビュアーの限りある時間を頂戴する＝効率よく目的を達成させる、という前提は一緒か。前者は短期的な視点（このプロダクト・プロジェクトでの品質向上）で、後者は中期的な視点（このプロダクト・プロジェクトも品質向上させつつ、ディスカッションによる参加者の品質？向上）だろうか。
ブラックボックスレビューとかホワイトボックスレビューとか、いろんな用語をs/テスト/レビュー/gにしてみたらどうなるかな。
# ちなみに過去ログ連番だと「4098」あたりの話題。
# 全部見終わってないので、この続きがまだあるのかもしれない。
| 固定リンク | コメント (0) | トラックバック (0)
「ソフトウェアテスト」って「山登り」に似てるなあ。
お客様第一、お客様が品質を決める、そこはどんな分野でもどんなプロダクトでもどんなプロジェクトでも同じ。いかに上手に（効率的に、効果的に）頂上にたどり着くか。
頂上はひとつだが、登り方にはいろいろある。登る道筋はリーダーが指し示し、登るペース配分はマネージャーが管理する。なるべくリスクを小さく保ちつつ、近くて緩やかな坂道を登りたい。山登りについて何も知らなければぐるぐる回ってるだけで頂上に近づかないかもしれない。
高い山に登るときはそれなりの装備（ツールや知識）、パーティー（チーム）、時間などが必要になる。でも、低い山なら重装備はいらない。けれど、準備のために買い物に行くといろいろな装備（ツール）がほしくなる。意外に高い。
道路が舗装されていると5合目くらいまでは車やケーブルカー（自動ツール）でいける。でも頂上まではいけると思っちゃいけない。
山の天気は変わりやすい。なかなか頂上にたどり着けずに夜になっちゃった（デスマ）。救援してもらわないといけないけど、ヘリコプターとか救助隊は高くつくなあ。。。
適切な方向性と妥当なスケジュールと最適のツールを装備して、山に登りたいものだ。
| 固定リンク | コメント (0) | トラックバック (0)
ウェブと書籍で「Webアプリケーション」のテストに関するウェブサイトと書籍が登場。書籍についてはまだ未読だが、
本書は、Webアプリケーション開発におけるテスト手法をはじめて本格的にまとめた、開発者待望の1冊です!
本書が注目しているのは、テストの自動化、つまりテストコードと呼ばれるコードを書き、自動的にテストの処理を行う手法についてです。 本書は、「テストを書く」という手法について知らなかった方や、聞いたことはあっても実践したことはなかった方、多少はテストを書いたことがある方をターゲットとして、テストの基礎的な考え方や、Webアプリケーションでよく利用される各種言語での具体的なテストの手法、さらには運用の際に重要となるスケーラビリティや使い勝手など、Webアプリケーションにおいて必要となる様々なテクニックを解説しています。
Webアプリケーションのテストは、不快なデバッグ作業を軽減し、問題やミスを少しでも早く簡単に発見するために発展してきたものです。デバッグを行うよりも、はるかに楽で(ある意味おもしろみもある)作業を行うことで、デバッグのコストを軽減し、早く、バグのないプログラムを書くことができることを目指しましょう。
どちらかというと自動化、効率化などに特化した内容でしょうか。言語ごとにスペシャリストが登場するので、多様な言語の多様な手法が垣間見れるかも。
ソフトウェアテスト基本テクニック：第6回 Webアプリケーションのテスト｜gihyo.jp … 技術評論社
ソフトウェアテスト基本テクニック：第7回 キャプチャ／リプレイツールによる機能テストの自動化｜gihyo.jp … 技術評論社
Webアプリケーション特有のテスト観点、テスト結果評価などについても言及されています。またSeleniumやJameleonといったフリー系自動ツールの使い方などは第７回以外でも、さまざまなサイトでも取り上げられていますね。自動化率をあげるには設計段階でツールを想定しておくのがポイントかも。著者の町田氏は「現場で使えるソフトウェアテスト Java編」やソフトウェア・テストPRESSなどでもおなじみ。
| 固定リンク | コメント (0) | トラックバック (0)
第5回を迎えるJSTQBのFoundation Level試験。試験はソフトウェアテストの基礎的な力を知るのにはよいかも。ただし、これが合格できたからといって品質向上にすぐつながるというわけではないですね、スタートラインに立つ感じ。アドバンスはいつかしら。
JSTQB認定テスト技術者資格 第5回Foundation Level試験
日時：
平成20年 8月 30日（土曜日）
試験会場：
東京、北海道、宮城、大阪、愛知、福岡を予定しています。（実施パートナーの案内をご確認下さい。）
受験申込み期間：
[締切日]平成20年 8月 7日正午
結果発表予定：
3ヶ月以内
試験開催の詳細：
実施パートナーの案内をご確認下さい。
主催
JSTQB（Japan Software Testing Qualifications Board）
実施パートナー
財団法人日本科学技術連盟
JSTQB認定テスト技術者資格認定試験につきましては、財団法人日本科学技術連盟を実施パートナーとして実施しています。
上記2冊の定番テキスト・問題集に加えて、ISTQBシラバス準拠の訳本がでたみたい。
| 固定リンク | コメント (0) | トラックバック (0)
毒味させるって、一種のモデルベーステスト？
==
ホワイトボックステストで単体試験を設計するにはどうしたらいいのか、というコメントがあったので、いろいろ考えてみた。脈絡もなく。
まとまりがないなあ。
| 固定リンク | コメント (0) | トラックバック (0)
トラブルをきっかけに、”メンテ”イップスに。なりたくないねえ。
==
仕事の中であまりperlは扱わないのですが、
特集 Happy Testing Perl by 技術評論社
この特集では，TAPをはじめとしたPerlプログラミングにおけるテスト手法を解説します。ここで紹介するモジュールはどれも実践的なものばかりです。ぜひ皆さまのプログラミングの際に活用してください。Happy testing!!
テスト系の連載が増えてきた気がします。
| 固定リンク | コメント (0) | トラックバック (0)
ずいぶん亀レスですが、技術評論社サイトにソフトウェアテストエンジニア向けのこんなサイトができています。今日見てみたら第3回の記事が載ってました。
gihyo.jp special：テストエンジニア ステーション｜gihyo.jp … 技術評論社
いま，ITに関わるあらゆる開発業務で注目されつつあるテスト系エンジニアをターゲットにしたコンテンツサイトを展開します。コンセプトは「技術」「人」「仕事」の3テーマ。この3つの柱とした情報を集め，日本国内のテストエンジニアたちが交流するきっかけの場となることを目指します。テスト技術者の転職
テスト技術者として転職し，テスト技術者を採用する両方の経験をもつ筆者が，テスト技術者が転職する際に知っておきたいことや，転職に成功する秘訣を教えます。テストエンジニアの視点で読み解く「発注者ビューガイドライン」
2008年3月に公開された「発注者ビューガイドライン」は，実践的な設計書の書き方やレビューのポイントをまとめたものです。ここではテスト視点でこのガイドラインを読み解きます。ソフトウェアテスト基本テクニック
これからソフトウェアテストに関わる人に向けて，ソフトウェアテストの基礎知識や，テスト技術者が知っておくべき技術トピックをコンパクトに解説します。
チェケラ。
| 固定リンク | コメント (0) | トラックバック (0)
少しお手伝いさせていただいている、若手テストエンジニアのためのワークショップ「WACATE 2008 夏」のベテラン受付が開始です。ということで、ちょっと僕自身も宣伝活動もしていまーす。もし興味を持った方がいらっしゃれば是非サイトにアクセスしてみてください。テストエンジニアと銘打っていますが、システム開発・品質保証部門・サービスサポートなど各分野からの参加者をお待ちしています。そういう僕もシステム開発の人ですし。
==
WACATE 2008 夏 テストに関する参考書籍 by WACATE
本ワークショップでは、テスト設計に関する演習を行いますが、当日は特別にチュートリアルや細かい説明は行いません。したがいまして、ソフトウェアテストの知識のなかでも、テスト設計を中心とした基本的な内容について予習をお願いいたします。
以下に、実行委員会がお勧めする書籍の一覧を載せております。
書籍のタイトルをクリックすることで、amazonの該当書籍のページへ飛ぶことが出来ます。
是非、参加の前にこれらの書籍をにお読み下さい。
また、特に重要と思われる書籍は、是非当日お持ち下さい。演習の参考資料となり、円滑にすすめられるかと思います。
専門的なものも包括的なものもおりまぜてありますが、これからテストエンジニアとしての勉強をする方も、システム開発に携わるものとしてテスト工程について見つめなおす際にも、とても参考になるリストです。より学術的・古典的・知識基盤的であれば、マイヤーズやバイザーなどもいいでしょうが。
今回のワークショップでは、参考書籍の著者などともお話しできる機会があるかもしれませんね。TEF主催の勉強会と同じく、著者と直接お話ができる機会ってなかなかないので、参加者はどんどん声をかけていくといいですね。
| 固定リンク | コメント (0) | トラックバック (0)
「WACATE 2008 夏」の参加受付開始にリンクして、前回参加者の声が掲載されています。
組み込みネットレポート 「自分はできる」と思っている人にこそ参加してほしい by 組み込みネット
――WACATEはどのような人に勧めたいですか？加文字氏：テストに興味のある学生には絶対お勧めです．実社会を知ることができるし，いろいろ面白い話が聞けます．
山田氏：入社2～3年目の，そこそこ開発をやり始めたエンジニアに勧めたいです．ひととおり仕事ができる気になったとき，もっと勉強できる場に参加すると，良い刺激になると思います．
会社のOJT（On the Job Training）ではソフトウェア開発については教えてくれても，テスト設計まではなかなか教えてもらう機会がありません．
国広氏：社内に閉じこもって外に出ていない人，自分は「開発ができる」と思っている人にお勧めしたいです．
そこそこ「仕事ができ」て、そこそこ「自分はできる」と思ってるときに、こういうワークショップという触媒ってすごくいいと思ってます。ここ数年、ソフトウェア品質とかソフトウェアテストとかって注目され始めたキーワードになったということもあって、ワークショップ参加者の分野が幅広く、他業界の人たちと議論しあう場、という意味でもすごくいい。
==
さて、「WACATE 2008 夏 プログラム内容」をちらりとのぞいてみるとクロージングセッションは、
14:00～15:00クロージングセッション＜60分＞
[タイトル]
「ソフトウェアテストがおもしろい理由」
[講演者]
秋山 浩一（富士ゼロックス システム品質評価部）
1997年からテスト技法、ツール開発に従事。
JaSST Tokyo実行委員、JSTQBステアリング委員。
著作に「ソフトウェアテストHAYST法入門」など。
[概要]
ソフトウェアテストで考慮すべき範囲は何か？また、10年間もこの職に
ついていまだにワクワクする仕事なのは、なぜかについてお話します。
「なぜ、ワクワクする仕事なのか」というテーマがすでにワクワクです。
| 固定リンク | コメント (0) | トラックバック (1)
若手テストエンジニアのためのワークショップ WACATE 2008 夏 が受付開始です。
==WACATE 2008 夏 ～どっぷりつかろうテスト設計～ 開催のご案内 by WACATE
そういえば、ソフトウェアテストのイベントって、シンポジウムはあるけどワークショップはないよね・・・
『ないならやってみよう！』
こうして、WACATE(Workshop for Accelerating CAdet Testing Engineers)・・・若手テストエンジニアを中心に企画された、若手テストエンジニアのためのワークショップが、2007年に誕生しました！！
記念すべき第一回は、2007年12月15日～16日に、上野(水月ホテル鴎外荘)にて開催され、盛況のうちに閉幕、参加者からは「是非次回開催を！！」という声を多くいただきました。
第一回はテスト設計技法の基礎、教育についてのグループディスカッション、ソフトウェアテストの基本についての講演など、盛りだくさんの内容を行いましたが、第二回となる今回は、テスト設計を中心としたチーム演習を二日間ぶっ通しで取り組むという、まさに夏の合宿というべき内容となっております。
演習を通して、同じような悩みを抱える同志たちと語り合い、気付きを与え合い、そしてお互いを高め合う。
考えすぎて疲れたときには、マイナスイオンたっぷりの渓流と大自然、それに14日夕方のバーベキュー大会がみなさんを癒してくれることでしょう♪
そんなステキな「2日間のプロジェクト」で、テストにどっぷりつかってみませんか？
また、2日間の最後を飾るクロージングセッションは、HAYST法で著名な秋山浩一氏に「ソフトウェアテストがおもしろい理由」と題して、氏のエピソードを交えて、お話いただきます。テストがワクワクする理由、そこには仕事をより楽しく誇りあるものにするヒントが見つけられるかも！？
なお、本ワークショップは若手中心となっておりますので、前回同様若手の参加を優先させていただきますが、若手だけでなく、ベテランが持つ知見の継承とご支援もいただきたく、幅広い層の方々に参加いただけるとありがたく思います。このように、若手中心となっておりますが、ベテランの皆様もお気軽にご参加ください。
今回は夏ということで川のせせらぎとバーベキューを求めて、東京・あきる野市の秋川渓谷で開催となっておりますので、皆様のご参加をお待ちしております。
初夏の秋川渓谷で梅雨もぶっ飛ぶ？！ハードなソフトウェアテストの合宿です。是非、皆で盛り上がりましょう！
開催概要
WACATE 2008 夏 ～どっぷりつかろうテスト設計～
主 催： ソフトウェアテストワークショップ実行委員会（WACATE実行委員会）
日 時： 2008年6月14日（土） 10:30 受付開始（予定） ～ 2008年6月15日（日） 15:30 終了（予定）
（一泊二日 四食付）
会 場： あきる野市自然休養村 山渓（東京都あきるの市・JR武蔵五日市よりバス10分）
http://www.sankeiweb.com/
参加費
￥20,000（14日昼食・夕食、宿泊費、15日朝食・昼食含む）
参加費はWACATE 2008 夏開催当日受付にて、現金でお支払いください。引き換えに領収書を発行いたします。
プログラム
14日10:30受付開始(11:00開会)、15日15:30頃に終了予定です。（14日夕方は大バーベキュー大会です！）
当日はテスト設計をテーマとしたチームごとの演習を行います。テストチームの編成から、仕様の分析、設計、実装、そして最終的にその内容を発表していただきます。お題は当日発表します！
プログラム内容の詳細につきましては、こちらをご覧ください（随時更新中）。
参加募集人数
先着合計36名（若手、ベテランそれぞれ先着）
若手（35歳以下の方） 24名
ベテラン（36歳以上の方） 12名
参加受付
WACATEは若手エンジニア向けということもあり、年齢別に段階受付いたします。（ベテランの方々の申し込みが殺到して、本来主役の若手が参加できないことを防ぐためです。ご了承願います。）
若手（30歳以下）： 2008年5月27日（火）13:00～
ベテラン（35歳以下）： 2008年5月29日（木）13:00～
ベテラン（36歳以上）： 2008年6月2日（月）13:00～
それぞれのお申し込み開始は別途、アナウンスさせていただきます。また、お申し込みにあたっては、以下の「参加にあたっての注意点」をご参照ください。
参加受付はこちらからお願いします。
14日の宿泊について
14日の宿泊は相部屋となります。
これは参加者間の交流をより深めていただくための施策です。なお，部屋割りにつきましては実行委員会で決定させていただきます。（女性については、女性部屋を作るなど配慮いたします。）
あらかじめご了承ください。
参加にあたっての注意点
参加ドタキャンが発生すると実行委員会の自腹負担になってしまいます。つきましては、当日確実にご参加いただける方のみ、参加受付をお願いいたします。
参加者全員が参加し、勉強し、楽しむことが重要です。自ら学ぶ態度でご参加ください。
参加にあたって準備いただくもの
演習中心となりますので、極力以下のものをお持ちください。
問い合わせ先
WACATE 2008 夏 についてのお問い合わせは以下にお願いいたします。
query@wacate.jp
実行委員会
実行委員長
池田 暁 （WACATE実行委員会）
副実行委員長
山崎 崇 （WACATE実行委員会）
実行委員
加瀬 正樹（WACATE実行委員会）
加文字 諭 （電気通信大学大学院）
河野 哲也（電気通信大学大学院）
澤田 悠介（WACATE実行委員会）
武市 喜博（WACATE実行委員会）
西 康晴（電気通信大学）
坂 静香（WACATE実行委員会）
村上 くにお（WACATE実行委員会）
森 孝夫（WACATE実行委員会）
アドバイザ
猪股 宏史（WACATE実行委員会）
| 固定リンク | コメント (0) | トラックバック (0)
TEFでもTDDや単体テストの話題で持ちきりですが、
極力ユニットテストを書かずに品質を確保する方法 by ひがやすを blog
やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。
後述にもありますが、「ユニットテストは工数がかかる」という意見に対する対案のようなもので、せっかく書いたテストコードをより効果的・効率的にするための工夫ですね。
事実、ここ数年、「ユニットテストは工数がかかる」と思っている人と「ユニットテストを書いたほうが最終的にはコストが下がる」と思っている人の会話は平行線のままです。このような状況を改善するために考えたのが、「Programming First Development」のなかで、バグったところ(とその周辺)のみユニットテストを書くという方法です。このやり方なら、ユニットテストを書く工数は、かなり減ります。そして、偏在しているバグを効率よくつぶすことができるのです。
著者の「ユニットテストの工数を少なくしつつ、品質を保つ」という試み・着眼点はすごく興味惹かれますね。ユーザにまずは動かしてもらうという方法以外にも、考えたらいろいろ思いつきそう。難易度・重要度マトリックスを作って、ユニットテストの強弱をつけるとか。ただ、個人的な意見ですが、「ユーザにまずは動かしてもら」ったとしても、開発者側が思ってるほど協力的ではない場合もありそう。その場合は、バグったところの他のバグは見つけられるかもしれないが、そもそもユーザがあまり操作してくれなかった箇所・機能なんかは少し不安が残るかもしれません。
| 固定リンク | コメント (3) | トラックバック (0)
バタバタしとります。
==
ずいぶん間が開いてしまいましたが、この春になってテスト関連書籍もどしどしでてますね。Java版ということなので、C言語版も今後期待してます～。TEFでも勉強会が企画されたりと話題の1冊。
こちらは半年に1回発行されているソフトウェアテストPRESSの増刊号的なものでしょうか。著者も「大西建児、丹羽隆、町田欣史、田呂丸直純、秋山浩一、珍田晋之介、鈴木三紀夫、池田暁、細川宣啓、佐々木方規」といった先輩方の名前が連なっています、新社会人・これから復習したい人・ソフトウェアテストPRESSに興味があるけど、まだ購入していない人、いろいろな人にとって有意義な記事に出会えるんじゃないでしょうか。「MADE IN JAPAN」というキャッチも興味深い。
| 固定リンク | コメント (0) | トラックバック (0)
午前と午後で公園を散歩。もう春ですなー。
==
ソフトウェアテストのいろはが「ノウハウ」編と「あるある」編になっていました。あるあるネタは、経験の違いや業界の違い、担当の違いなどによって感じ方が違うかもしれませんが、思わず「あるある」といいたくなるようなものが多いですね。「またか」はもうききたくなーい！
| 固定リンク | コメント (2) | トラックバック (0)
確定申告すませた。けっこう人が多かったなあ。
==
4月に入社する新テストエンジニアや、これからバリバリ勉強する初心者にむけたソフトウェアテストの「いろは」が、まとめられています。
キーワードがわからなかったら、それについて調べていく、なんて勉強の進め方もできそうだ。僕がソフトウェアテストを勉強し始めたころだと、半分もキーワードがわからなかったな。8時間の集中力、自分にはあるのだろうか。。。
| 固定リンク | コメント (2) | トラックバック (0)
単体テストレベルでは、「コードカバレッジ」を意識しながら（基準にしながら）テスト設計やテストケース作成を行う機会が多い。でも、この「コードカバレッジ」って用語がばらばらであったり、どのカバレッジ基準がどういうことを確認するものなのか、どういう不具合を見つけられるのか、見つけられないのか、といったことが自分の中でしっかりまとまっていなかったので、いろいろ調べてまとめようと思います。
2008/03/12更新
サンプルプログラムで解説を追加
サンプルプログラムは、以前例題として作成したテニスのスコアボードについて
[例題]テニスのスコアボード
P1： 第1セット～第4セットである（＝最終セットではない）
P2： 第1ゲーム～第12ゲームである
P3： 今回のポイントが4ポイント目以上である
P4： 今回のポイントが7ポイント目以上である
P5： 今回のポイントで2ポイント差
P6： 今回のゲーム勝利で6ゲーム目以上である
P7： 今回のゲーム勝利で2ゲーム差
P8： 今回のセット勝利で3セット目分岐Bが真 ⇔ P1 && (P2 && P3 && P5 || !P2 && P4 && P5) || !P1 && P3 && P5 が真
分岐Cが真 ⇔ P1 && (P2 && P6 || !P2) || !P1 && P6 && P7
分岐Dが真 ⇔ P8
参考：
Code Coverage Anaysis
Testing and Code Coverage
Part2 ホワイトボックス技法：ITpro
ソフトウェアテストの分類
A Practical Tutorial on Modified Condition/Decision Coverage(PDF)
| 固定リンク | コメント (0) | トラックバック (1)
TotT: Understanding Your Coverage Data by Google Testing Blog
「僕のソースはコードカバレッジが高いから、十分テストしてるのさ」というのはマチガイ。という話。ここではステートメントカバレッジを例に挙げて、たとえテストが100%カバレッジをしていても、見つけられない欠陥があるということを示している。
で、コードカバレッジ解析の正しい手順はこんな感じ。
ある技法によってテストケースを作成し、もれてしまったパターンや重要なパターンなどは追記していく。これ常套手段ですな。HAYST法でもやるやる。
| 固定リンク | コメント (0) | トラックバック (0)
今日は深夜メンテナンス。少し休憩。
==
原因結果グラフをデシジョンテーブルにするツールを勉強のために作成しているが、6割くらいできた。未実装なのは、
何とかなりそうな気がしているが、コードがまったくエレガントではないし、長い。。。。
この例だと、なんかあってそうな感じ。でもよくみると、偏ってる。#5は「埼玉に在住でない」「学生証を提示していない」のほうがベターか。
これは、マス目の埋まっていないところの決め方が偏っているため、テストケース数が多い。最適化の課題か。
一見うまくいってそうだが、「16歳以上」「18歳以上」の組み合わせが矛盾。制約条件が中途半端だから。
| 固定リンク | コメント (0) | トラックバック (0)
今日はお風呂を掃除して、近所のスタバのドライブスルーでラテ買ってきて、和室でお勉強。amazonから本も届いたし読むかな。
==
原因結果グラフを元にしてデシジョンテーブルを作成していく手順を自動化して、理解を深めようとしてるのだが、以下の例でいろいろ考え中。
たぶん、こういうようにTrue/Falseを決定しつつ、カバレッジ率をあげて、未確定のマス目も埋めていく感じですすめていくかな。
| 固定リンク | コメント (0) | トラックバック (0)
JacaScriptが初心者向けなのかどうかは別として、手ごろだったので原因結果グラフからデシジョンテーブルを作成するツールをJavaScriptでためしに作り中。エクセルVBAとかのが使えるんだろうな。
原因結果グラフ→デシジョンテーブル（v0.2）
# Opera9.26で確認中。まだブラウザによっては動作しないかも。。。
以下、TODOとして。
| 固定リンク | コメント (0) | トラックバック (0)
昨日は社内では改正される特電法のお勉強会。社外ではWeb自動テストツールのお勉強会。
==
TotT: Too Many Tests by Google Testing Blog
単純な処理を例に挙げて、「テストケースが非常に多いこと」の考察をしている。int型の単純なべき数（＝2^32のパラメータ数分のべき）では、多すぎる。条件分岐がTrueの場合とFalseの場合の2通り（100%ステートメントカバレッジ）は、少なすぎる。境界値と同値クラスを考慮した場合も、少し多そう。最後は、条件分岐（OR条件）がTrueになる場合（＝3通り）とFalseになる場合（＝1通り）を考え、そのサブ処理で各2通りを考えた10通り。
| 固定リンク | コメント (0) | トラックバック (0)
方針転換。JaSSTの「三賢人、テストを語る」のPDF資料にある、カバレッジ表を読み解く。
また例題。
IDとパスワードを入力して、ログインする画面についての原因結果グラフとします。ここでまず、網羅すべき論理展開式（論理接点、論理点？）がいくつあるかを調べる。これは、それぞれのエッジの交叉点に注目するとわかる。ANDであれば、Tになる1通りとFになるn通りがあるので、(n+1)通り。ORであれば、Fになる1通りとTになるn通りがあるので、(n+1)通り。ということはこのグラフで言えば、3＋3＋3＋3＋2＝14通りとなる。14通りの論理展開式がどのように出現するかをマトリックスにするため、行には論理展開式を、列にはノードを並べた14×10行列を用意する。
ちなみに、薄緑色は原因ノード、イタリックは中間ノード、薄オレンジ色は結果ノード。ここにどんどんT/Fの組合せを記入していく。
ここからは、すべての論理展開式が出現するようにテストケースを組み立てていくのだが、この場合だと4組ですべて網羅した。
出現した論理展開式をチェックするとこんな形のマトリックスが完成する。「x」は1回だけ出現し、「#」は2回以上出現したことを表している。「#」は1回だけ出現し、「x」は2回以上出現したことを表している。
この流れでツールを作ってみるといいかな。ただ、PDF資料だと、最後のテストケースの選び方は割愛されている模様。
| 固定リンク | コメント (4) | トラックバック (0)
BlackBerryのメールは本文をBase64にするみたい。
==
原因結果グラフをデシジョンテーブルに変換する際、まずは小さなテーブル（サブテーブル）を作成してから、全体のテーブルを作っていく手順で僕は行っていたが、サブテーブルはどちらから結合したほうが簡単なのだろうか。ごくごくシンプルな原因結果グラフであれば、中間ノードと結果ノードから大枠をサブテーブル化して、細部を組み立てるほうがわかりやすそうだけれども、制約条件が関係してくると、原因ノードと中間ノードからサブテーブルを作成して、制約条件を先に考慮したほうがよさそうにも思える。
などと考えてみる。
今のところの結論としては、原因側から右側へ結合させていくほうがよさそうに思える。原因ノードと中間ノードについてのサブテーブルを作成する際に、原因ノードと制約条件をもつ原因ノードも一緒にしてしまうといいのではないか。
| 固定リンク | コメント (4) | トラックバック (0)
携帯の充電池が膨らんじゃって、ドコモショップに持っていったら、無料交換してくれた！やった！
==
初心にもどって、同値分割、同値クラスを調べてみる。
事象をグループ分けして代表元のみテストを実施する。なのでグループ分けは結果が同じになるような入力集合になる。電源ボタン、リセットボタンについては、すでに単機能テストで結果について網羅できそうなので、ここではポイント（上）ボタンについて考えてみる。ポイント（上）ボタンを押すことでスコアボードはどんな結果を生じるか。
これら6つの同値クラスが考えられるため、各同値クラスの代表元を選択して、テストケースとする。
ポイント（下）ボタンについては上下を逆にしたテストケースを考えればよい。番号B-01-03がテストしにくいな。
| 固定リンク | コメント (0) | トラックバック (0)
1. [例題]テニスのスコアボード
2. [例題]分析する - 3色ボールペン版
3. [例題]分析する - マインドマップ版
仕様分析からテスト設計へ。まずは、単機能テストの設計をしてみる。
・・・
・・・
ふと、単機能テストを検索してみると、けっこう「単機能テスト＝単体テスト、コンポーネントテスト」という記述があったりする。単なる用語の使い方の違い、という考え方もあるけれど、僕の認識では、単機能テストと単体テストは違うテストと思う。単体テストの目的は、「関数・メソッドといった”システムの一部”が正しく実装されているか」であり、やり方によっては組み合わせテストも含まれるし、主にホワイトボックステスト（あるいはグレーボックステスト）で設計されることが多い。一方、単機能テストの目的は「機能が単独で正しい動作をするかどうか」であり、組み合わせテストを含まず、実行結果が注目されるテスト。ブラックボックス的。
# 当然、後者の意味で「単体テスト」と表現する場合もありました。
などと思いをめぐらしながら、例題の単機能テストへ。
仕様をみてみると、
電源の切り替えができるかどうかが単機能テストであろう。
仕様より、
電源ONの状態で、画面がリセットされるかどうかが単機能テスト。
ポイントボタンは仕様がやや複雑であるが、ここではもっとも基本的な動作である、電源ONの状態で、上のプレイヤーのPOINTSが追加されるかどうかを単機能テストとする。GAMESおよびSETSへの反映パターンはここでは考慮しない。という方針。
ポイント（上）ボタンと同様。
こんな感じ。このスコアボードはボタンが4つしかなく、減点機能がないため、これらのテストケースの実施順序は最終的に変更する予定。
| 固定リンク | コメント (0) | トラックバック (0)
例題を作って、テスト設計をしてみる。
==
マインドマップから始めるソフトウェアテストでは、仕様分析～テスト計画～テスト設計～といった流れで、マインドマップをツールとして利用している。ここでは仕様分析＋アプローチといったニュアンスでマインドマップを使ってみた。各メインブランチにふれてみると、
ここでは、ボタンを押すと仕様どおり（電源が切り替わったり、ポイントが増えたり）動作することを確認すること。スモークテスト的なテストでもいいかも。
ポイント数、ゲーム数、セット数。ゲームが終わるとき、セットが終わるとき、試合が終わるとき。表示の桁数などなど。
業務シナリオテストに近いイメージ。実際の試合を想定した利用。効果的、効率的なテストを目指す。
この状況でこのボタンを押したら、こうなる。
ソフトウェアテストの例題なので、外部環境はできないですね。あと、数字がちゃんと表示されるか。とか。
スコアのつけかたって、意外に複雑なのだよ。15ずつ増えたり、増えなかったり。タイブレークがあったり、なかったり。
こういうのって数をこなしていくことも重要なのかな。ここ何日かは通勤バスの中でテキストを読んで復習してます。
| 固定リンク | コメント (2) | トラックバック (0)
引き続き、制約条件を表すグラフをチェック。制約とはありえない組合せを表現するための表記で、ソフトウェアテストではとても重要。
排他的EXCは、原因ノードのうち「T」になれるのはひとつだけ。「NHKを見るか、フジテレビを見るか、それともテレビを見ないか」。
包含INCは、原因ノードのうち、少なくともどれかが「T」でなければならない。「自動販売機の、コーヒーを押そうか、お茶を押そうか、それとも両方押しちゃおうか」。
ONE制約は、原因ノードのうち、どれかひとつだけが「T」でなければならない。「じゃんけんの結果は、勝ちか、負けか、あるいはあいこ」。
REQ制約は、原因ノードが「T」ならば、かならず結果も「T」にならなければならない。「充電がなくなれば、携帯電話はつながらない」。ちょっと違うか。
この他にも、隠蔽（M）があるらしいのだが、お目にかかったことがない。どういうときに使う制約なんだろう。
| 固定リンク | コメント (6) | トラックバック (0)
NHKクローズアップ現代でソフトウェア品質のプログラムがこの前やってた。見逃した。
ブログで少し検索したので、リストアップ。
==
原因結果グラフのテーブル作成をツール化する前に、基礎的なことを復習・まとめてみる。小さなテーブル作成をしているうちに何かいいことが気づけるかなあと。手持ち資料で原因結果グラフを勉強するとなると、マイヤーズ本くらいしかないが、わかりにくい表現が多い。自分なりの言葉でまとめてみる。
原因が「T」なら、結果も「T」。原因が「F」なら、結果も「F」。原因と結果が同値な状態をさしていて、デシジョンテーブルも非常にシンプル。
これは中間ノードが入ってもデシジョンテーブルは同じ。
原因が「T」なら、結果は「F」。原因が「F」なら、結果は「T」。原因と結果の関係が逆になるケース。
原因が2ノード以上関係して、さらにその論理積で結果を決定するケース。「身長が高くて、学歴が高くて、高収入なら結婚する」みたいな。下図にあるように原因ノードが3つある場合は、デシジョンテーブルは4列（結果が「T」＝１、「F」＝３）となる。
単純に考えてみると、原因（真／偽）が3つあるので、全数では2^3＝8列になるはずである。しかし、原因の複数項目が「F」だと、どの原因が結果を決定しているかが判断できない。つまりは、#2、#3、#4の3列は、それぞれノード11、ノード12、ノード13が結果を「F」にする原因となっていることを確認することが目的であるため、下図#5のようなテストケースは適当ではないのだ。これは経路感光（path sensitizing）というそうです。
原因が2ノード以上関係して、さらにその論理和で結果を決定するケース。「医者か、弁護士か、あるいはIT長者なら結婚する」みたいな。下図にあるように原因ノードが3つある場合は、デシジョンテーブルは4列（結果が「F」＝１、「T」＝３）となる。
ORとANDは表裏の関係なのがポイント。高校のときに習った、ド・モルガンを思い出せ。
さーて、続きはまた今度。次は制約記号だな＞EXC、ONE、INCなどなど
| 固定リンク | コメント (0) | トラックバック (0)
[例題]テニスのスコアボードのテストをしてみるのだが、まずテスト対象の分析をしてみる。分析をしてどんなテスト設計をするのか、テスト技法を使うのか、などなどを検討する。今回は、ソフトウェアテストPRESS Vol.2 「3色ボールペンで読む仕様書」にならってやってみようかな。
次回はマインドマップを分析ツールとして使ってみる。予定。
| 固定リンク | コメント (0) | トラックバック (0)
原因結果グラフをデシジョンテーブルにするツールを作ったら、理解が進むかなあ。
==
テスト設計の例題。自分で出して、自分で考える。
テニスのスコアボードのテスト
まずは、3色ボールペンとかで仕様チェーック、かな。
| 固定リンク | コメント (0) | トラックバック (0)
2007年に引き続き、2008年もソフトウェアテストの重要な年になるかも？
==
ブログ更新を怠っていましたが、その間にソフトウェアテストのサイトが立ち上がっているようです。
zohoで作られたソフトウェアテストのまとめ的サイト。主として動的テストに関する記述。体系的でもあり、用語の解説、参考文献なども付記されており、「興味を持ったから参考文献を調べてみよう」といった流れで勉強もできそう。文献以外にもインターえんっ途上に公開されている記事などもリンクされていて、非常にためになります。制御パステスト、テストツールのサイトもある模様。
著者がHAYST法について、職場向けの資料を作成して、それを公開しているサイト。職場向けの資料ということで、非常に細かい説明が掲載されており、図表や演習問題まで揃っている。
HAYST本とともに、自学用にはとても重要・貴重なサイトであろう。交互作用についての解説も少し載っているのは、HAYST本にはないポイントか。
2008/02/04追記:
ソフトウェアテストの社内勉強会資料を公開しているサイト。ブラックボックステストの「同値分割」「境界値分析」「デシジョンテーブル」「原因結果グラフ」についてのPDFが閲覧できます。pukiwikiの更新画面の原因結果グラフ、僕もためしにやってみました。僕はぱぱっとできないから、4テストケース7テストケースに落ち着くのに少し時間がかかりました。。。汗。続きが楽しみ～。
2008/02/05追記:
ちなみに、実際にやってみた感じの画像を貼る予定。（お昼過ぎに作成して一旦アップしたのですが、検算で間違い見つけたので、またやり直し～）
| 固定リンク | コメント (4) | トラックバック (0)
SQuBOKガイド読み中。お風呂で。
==
昨年、TEF有志による日本語化プロジェクトが発足し、今ではばりばり日本語で利用できるようになったのが、このテスト管理ツール「TestLink」（2008年2月2日現在で、1.7.3版が安定版）。少し休みの日を使って、自分のPCに載せてみたりした。
引用：TEF有志によるTestLink日本語化プロジェクトより
特徴としては、
などがあげられ、リーダもマネジャーもプログラマもQAも一度は手にとって試してみたいツール。ソースからインポートファイルへの変換ツールが作成されたり、活動的なプロジェクトなのもよいですね。今後はSeleniumとの連携なども予定されているようですし、コードレビューやテストケースレビューなどへの応用など、興味深いプロジェクトです。
| 固定リンク | コメント (2) | トラックバック (0)
ある意味、餃子ブームだ。
==
メールサーバってCだから、C向けのテスト手法はいろいろと調べたりすることが多いし、自分でツールを作ったりします。せっかく調べたので、C言語をターゲットとした単体テスト/ユニットテストツールを枚挙してみる。
http://sourceforge.net/projects/cunit/によるユニットテストフレームワーク。出力に「__FILE__」「__LINE__」を記載して、分析しやすく結果を表現する。XML出力モード（Automatedモード）で実行し、DTDとXSLスタイルシートによって、統計情報が見やすくなる。
安藤利和さんによる「言語技術者のC言語技術者によるC言語技術者のための C言語テスティングフレームワーク」。ソースはhttp://sourceforge.jp/projects/cunitforando/から入手。関数のスタブ生成でテストを実行していく。ドキュメントには使い方のほかに、単体テストの原理などの記事も。
Cのユニットテストツールはネーミングが特徴的なものが多い。CCUnitは「繰り返し可能なテストを書くため」のフレームワーク。CCUnit クックブックが、適用への近道か。ソースは、こちらから入手。
ネーミングは、「C Unit Testing Framework」。このキュートなテストプログラムは、make-tests.shによって生成される。ソースはこちら。
マニュアルが充実している。テスト実行の進捗状況を「.」「F」を並べて見やすくしている。その他、テスト結果詳細として、テストケース数、テストパス数、テスト失敗数、テスト異常終了数、テスト保留数などがわかる。ソースはこちらから。
3行だけのユニットテスト。「a minimal unit testing framework for C」は、個人的にはライトで小気味よく、重宝してます。
--
リファレンスやチュートリアルが充実しているのですが、より実践的な例があるといいなーなんて思ってたりして。こういったツールの活用と効果的なテスト設計によって、結合テスト・システムテスト、あるいは静的テストの負荷軽減を図っていこう。
| 固定リンク | コメント (0) | トラックバック (0)
来月12月に若手エンジニアによるソフトウェアテストのワークショップが開催されます。微力ながら開催に向けての準備・お手伝いをさせていただきましたので、少しでも多くのエンジニアの方々に興味を持ってもらえるとうれしいですね～。
特に「若手によって運営され」、「若手が参加する」というのが実行委員会の想いでもあり、20歳代、テストエンジニア初心者などが参加してくれると、もっとうれしいですね～～。
----------------------------------------------------------------
WACATE 2007 ～僕たちは加速していく～ 開催のご案内
----------------------------------------------------------------
そういえば，ソフトウェアテストのイベントって，シンポジウムはあるけどワークショップはないよね.
『ないならやってみよう！』
そういった単純な動機から，WACATE(Workshop for Accelerating CAdet Testing Engineers)は，その名の通り，若手テストエンジニアを中心に企画されました．
現在ソフトウェアやそのシステムにおける品質問題は，ソフトウェアに起因する事故が新聞で大きく取り上げられるなど、世間で注目されていることからも，社会的な問題といえます．ソフトウェアテスト分野では，その問題を解決するために，さまざまな手法や技術の提案や，その実践がすすんでおり，効果をあげています．
そんな現場で日々テストを実践している若手ですが，テストに関して十分な教育が与えられていなかったり，そもそも教育システムが存在しなかったりして，テスト技術の習得と普及がすすんでいない現状があります．また，一念発起した若手が「じゃぁ勉強しよう!!」と思っても，身の回りにテストの熟練者が不在であったり，同様の悩みを持って一緒に取り組める仲間もいないという悩みがあります．
そこで本ワークショップでは，そういった現状から一歩踏み出したいけれどきっかけがないという若手に対して，その一助となる場を提供することを目的としております．若手が自主的に，さらに全員参加型でとりくむことで，悩みをみんなで共有しその悩みを解決する糸口をつかむことができます．さらに，解決策を検討することにより，テスト技術の習得，および普及につながると考えております．また，参加者は若手を想定し，ワークショップの企画と運営も若手が主体となって取り組んでおります．
一方，本ワークショップは若手中心となっておりますが，ベテランが持つ知見の継承を行う場としてもご活用頂ければと思います．さらに，今回は年末開催ということもあり，ソフトウェアテスト業界の大忘年会という性格も持たせています．国内のソフトウェアテスト関係者が一堂に会して，酒を酌み交わしながら交流する場は案外ありません．単純にテストを肴に盛り上がってみたいという方にも，お楽しみ頂けるようなワークショップを企画しております．
是非，若手の皆様、気軽にご参加ください．
また，若手中心となっておりますが，ベテランの皆様も気軽にご参加ください．遠方の方でも，交通のアクセスの良い東京・上野での開催となっておりますので，ご参加をお待ちしております．
今年最後のソフトウェアテスト業界のお祭りです．是非，皆で盛り上がりましょう！
[開催概要］
名 称：WACATE 2007
(Workshop for Accelerating CAdet Testing Engineers)
http://wacate.cocolog-nifty.com/blog/
日 時： 2007年12月15日（土） 13:00 受付開始（予定）
～2007年12月16日（日） 16:30 終了（予定） （一泊二日）
会 場： 水月ホテル鴎外荘（東京・JR上野駅徒歩10分）
http://www.ohgai.co.jp/
[参加費]
\20,000（宿泊費，宴会費，16日朝食，会場費などの運営費含む）
参加費はWACATE2007開催当日受付にて、現金でお支払いください．その
際に領収書を発行いたします．
＃参加費収入から必要経費を差し引いたのち，もし収益が出た場合は，
歳末助け合い運動に募金させていただく予定です．
[プログラム]
一日目の昼スタート，二日目16:30頃に終了予定です．
（一日目夕方は大宴会です！）
詳しくは次のURIをご参照ください．
http://wacate.cocolog-nifty.com/blog/2007/11/wacate_2007_e81c.html
[参加人数]
先着35人
[参加受付]
WACATEは若手エンジニア向けということもあり，年齢別に段階受付いた
します．（ベテランの方々の申し込みが殺到して，本来主役の若手が参
加できないことを防ぐためです．ご了承願います．）
30歳以下： 2007年11月23日（金）～ 参加申し込み
35歳以下： 2007年11月27日（火）～ 参加申し込み
＃30歳以下も申し込み可
36歳以上： 2007年12月 1日（土）～
＃30歳以下、35歳以下も申し込み可
それぞれのお申し込み開始は別途、WACATEのBlogおよびTEF(Testing
Engineer's Forum)メーリングリストにてアナウンスさせていただきま
す．また，お申し込みにあたっては，「参加にあたっての注意点」をご
参照ください．
参加受付はBlogのリンクからお願いします．
http://wacate.cocolog-nifty.com/blog/
[参加のあたっての注意点]
・WACATEはスポンサーを募らない，完全に有志によるイベントです．
参加ドタキャンが発生すると実行委員会の自腹負担になってしまいま
す．つきましては，当日確実にご参加いただける方のみ，参加受付を
お願いいたします．
・15日の宿泊は5～6人の相部屋となります．組み合わせは，実行委員会
の方で決定させていただきます．
・WACATEは若手エンジニアが主役です，ベテランは若手を尊重してくだ
さい．
・セミナーの類ではありません．
参加者全員が参加し，勉強し，楽しむことが重要です．自ら学ぶ態度
でご参加ください．
[問い合わせ先]
WACATE 2007 についてのお問い合わせは以下にお願いいたします．
wacate-query@nifmail.jp
[実行委員会]
実行委員長
池田 暁 （WACATE実行委員会）
実行委員
片山 徹郎（宮崎大学）
加瀬 正樹（WACATE実行委員会）
河野 哲也（電気通信大学大学院）
澤田 悠介（WACATE実行委員会）
武市 喜博（WACATE実行委員会）
西 康晴（電気通信大学）
森 孝夫（WACATE実行委員会）
山崎 崇 （WACATE実行委員会）
アドバイザ
猪股 宏史（WACATE実行委員会）
| 固定リンク | コメント (0) | トラックバック (0)
目がショボショボする。年末年始で落ち込んだモチベーションはやや回復の方向で。気分転換に記事書こうっと。
==
僕は入社以来ずぅ〜っとシステムを作る側であったが、品質向上という目標をもつというきっかけによって、ソフトウェアテストについて勉強をしている。勉強期間もたかだか1年とか2年。もう少し年数を経験した方のブログはすごく興味を持ってみてますー。
ソフトウェアテスト(1) by 品質って何だろう？
私は、これらは、ソフトウェアの品質保証に限った話ではないと思っており、人に会うたびに、この方法を薦めています。もちろん、自分の部下たちにもです。1.まずは知識を得よ
感覚的に優れた人はいます。よって、テストを行うにはこうした方が良いと言える人たちもいます。
しかし、自分自身が持っている知識はちっぽけなものであり、まだまだ他にもあります。知識を増やすことで
引き出しの数を増やすことは可能です。まずは、知識を得て、頭でっかちになる方が良いと考えています。
ただ、ここだけで終わっては意味がありません。
知識だけを追い求めることが正しいことではないが、知識を持っていないとそれだけ守備範囲が狭くなる。例えば「デシジョンテーブル」とか「設計カバレッジ」とか、単語を取ってみても知らないと議論に参加できない場合がある。(議論というのは、このプロジェクトにとってその手法が有効なのか、有効でないのか、といった議論です)さらには、引き出しを増やすことは長期的に見れば、情報も自分の元に集まってくる可能性も高くなるだろうし。あなたのその知識の助けを借りる、相談しに来る、そういったことも(苦労もするけど)メリットになる。
2.実践せよ
知識を得て、その知識だけをひけらかすのは人からの賛同は得にくいものです。実践し、その経験を
元に、自分の知識の幅を広げて下さい。その中から本当に良いものだけを出すようにしていけば良い
のです。自分に経験がなければ、本の内容をそのまま真似て下さい。私自身、真似ることは、とても
大事なものだと思っています。ただ、実務上で実践出来るかどうかは、上司の質に関わってくる可能
性があります。もしかすると、コストがかかるので、実践させてくれないかもしれない。そんなとき
は、1.で得た知識の出番です。この本に、こんなことが書かれているし、自分自身も有効だと思って
いるなど、説得させることが最も大きな難関かも知れません。
引用したブログにも書いてありますが、「学ぶ」は「真似る」から由来したといわれています。真似ることがすなわち学ぶことに通じます。まずはやってみて、それから良し悪しを判断するほうが、より説得力もあり、納得性の高い知識となると思います。会社にも寄るかと思いますが、うちの会社ではこういった自己研鑽や
長期的な人財育成は認めてくれるので、助かってますね。逆にそこには自らコミットメントを持っていないといけませんが。
3.そしてアレンジせよ
実践し、得た経験を元にアレンジしてください。有効なもの、有効ではないものは必ずあります。
それは、本の上だけで語られているものではなく、実践した経験を元に感じ取る必要があります。
そして、それらの情報は、必ず書き残しておいて下さい。それが、財産のひとつになります。
アレンジ・改良はすごく重要だし、エキサイティング。もちろん、ごく一般的なシステムに関するテストは書籍にゆるぎない回答が載っているかもしれない。が、自分の扱っているプロジェクトやプロセスはどこか特徴があるはず。そこは試行錯誤をしてアレンジしなくっちゃ。
もしかしたら、あなたがアレンジしたものが他のどこかにいるかもしれない誰かの琴線に触れるかもしれない。
そう思うとほんとエキサイティング。
| 固定リンク | コメント (0) | トラックバック (0)
忙しくてブログネタが見つからないのと、モチベーションが下がり気味なので更新が停滞中。。。まあ、波の激しい僕にしては3ヶ月以上モチベーションを上げ続けられたので、進歩かな。
==
今やってる作業は回帰テストツールのメンテナンス。個人的には回帰テストの自動化はアリだと思っているのだが、「知識ゼロから学ぶ ソフトウェアテスト」（翔泳社）のブログでは、基本的に自動化に向かないとの評価。
回帰テスト２ by 知識ゼロから学ぶ ソフトウェアテスト
基本的に回帰テストは自動化に向かない - 回帰テスト設計というエリアがない。テスト設計なしに自動化するというのは、混乱を招く。パフォーマンステストと機能テストとユーザビリティテストをなんら戦略もなくただバグだからといって回帰テストとして自動化するととんでもないことになる。（中略）
- 多くの直し壊しバグは、以前出た部分ではなく、そのちょっと横とか、似たファンクションで起こりがちである。なので回帰テストの自動化に大きなコストをかけたとしてもコストメリットは出ない。だいたい重要バグなんて数百件
なんてケースがほとんどなんだから（そのうちほとんどがsmoke testでわかるもの）、それを手で回帰テストやっても一日でおわっちゃうでしょ。それなのに、高いツール買ってきて、その高いツールの使い方覚えて、テストケースを書くの時間の無駄である。Cem Kanerだって、意味ないって言ってるし〜。修論に回帰テストの自動化について書いたら怒られたし〜。
この文章を読んでみて思ったのは、自分が使っているツールでは回帰テストというよりもスモークテストのほうがしっくりくるのかな。ちなみにこのツールはメールをSMTPで送信してPOPやIMAP4でチェックするという基本的な機能テストに特化したツール。手動で実施していたのだが、Received行のチェックであったり、タイミングによっては若干の遅延が発生したりするので、何度かテストを実施する日羽陽があるため、ツール化した経緯がある。
「デグレードを防止する」という目的のテストって「回帰テスト」なんだろうか？「スモークテスト」なんだろうか？基本的なことかもしれないが、自分の頭の中ではイマイチ明確化されてないかも。
| 固定リンク | コメント (11) | トラックバック (0)
今日は自分のプロジェクトでのトラブル対応に終始。「何故」を5回以上繰り返して、根本原因を突き止めろ。
==
このトラブルを見つけたときの第一声は、「あ、その場合か！」でした。つまり、考慮にすらされてなかった条件で欠陥が見つかったというケースになるかと思います。ただ、「考慮漏れ」というくくりではまだ浅い。以下、
思ったことをつらつらと・・・。落ちがない状態で終わる可能性大。
仕様考慮漏れ、システム/モジュール設計考慮漏れ、設計カバレッジ考慮漏れ、リスク分析考慮漏れ、あたりか。要求仕様にない機能は設計、実装、テスト設計ではほとんど見つけ出すことができない致命的な考慮漏れ。でも、設計考慮漏れであれば、テスト設計において仕様書をベースにすることで漏れに気づくことが可能かもしれない。リスク分析で考慮されなかったリスクについても、それ以降の工程で見つけるのは難しくなりそうだ。
中途半端だけど、今日はこのくらいで。
| 固定リンク | コメント (2) | トラックバック (0)
最近、テスト駆動型開発（TDDあるいはBDD）についての雑誌を買ったり、他のブログに感化されたりしたので軽い考察を。
==
実装とテストを繰り返しながら設計をすすめる、といった形でコーディングするとき、みなさんはどんな手順ですすめますか？僕はこんな感じでやってます。（僕はC言語をベースに開発することが多いので、C言語をサンプルに）
/**
* func1(); ○△×をする関数
* 引数
* 復帰値
* 0 正常
* -1 エラー
*/
int
func1(
const char* str1,
char* ptr2,
int num3 )
{
return(-1);
}
モジュール設計に基づいた関数の骨組みだけを記述する。ただし、復帰値がvoid以外ならばエラー復帰をまず記述しておく。
- 引数チェック
- 正常系ケース
- 限界値ケース
- エラーケース
- 異常系ケース
テストスイートは複数のテストケースの集まりをあらわし、「引数チェック」「正常系ケース」「限界値ケース」「エラーケース」「異常系ケース」といったテストケースを作成する。引数チェックは、関数の引数にNULL、0、負の数、ヌル文字のポインタ（””）などを指定した場合に正しく引数エラーを返すかどうかを確認する。正常系ケースでは、尤もらしい動作をするであろう条件を指定する。最低でもひとつ、そしてコーディング後に追加するのもあり。限界値ケースは、条件の境界値（最大値、最小値）において正常な動作をすることを確認する。これは正常系ケースと兼ねてもいい。エラーケースは、尤もらしいエラーが発生する条件を指定し、エラーが発生することを確認するテストケース。異常系ケースは、今までの4群以外で、例えば非常に大きなデータや、言語上の限界値などを指定する。
これらのテストケースをまとめる際、仕様書の欠陥などを同時にレビューするのもよい。
骨組みだけの関数をコンパイルし、テストスイートにある条件＆評価でテストする。僕の場合はMinUnitというマクロをベースにテストコードを自動生成して、「-fprofile-arcs -ftest-coverage」をオプションにしてコンパイル＆実行する。
ちなみに、ほとんどテストケースは失敗に終わり、いわゆる「レッド」の状態。
/* file: minunit.h */
#define mu_assert(message, test) do { if (!(test)) return message; } while (0)
#define mu_run_test(test) do { char *message = test(); tests_run++; \
if (message) return message; } while (0)
extern int tests_run;
「-fprofile-arcs -ftest-coverage」をオプションにするのはあとでgcovでカバレッジ測定をするため。
対象となる関数を実装していき、テストケースが「グリーン」にしていく。このとき、実装とともに必要と思われるテストケースを追加していくのもあり。
テストケースをすべてクリアすることと同時に、ステートメントカバレッジにも着目すること。僕の場合は、目安は８０％～９５％を目標にする。
本当は「リファクタリング」も必要なのだが、とりあえずこんな感じで試しているところ。
==
さて、こういったテストファーストで実装していくこと得られるメリットは、というと、、、
境界値や異常系を考慮するので、グレーボックス的なアプローチができる。
引数チェックは境界値やエラー推測といったブラックボックス的なアプローチができる。
テストケースを作成するプロセスは、仕様を浮き彫りにする作業となる。
ただし、いいことずくめではないと思っていて、引数が多くなったり、複雑な処理になるにしたがって、テストケースは膨れ上がる。テストをグリーンにするために実施カバレッジは少なくとも１００％にする必要もある。だから、どこかで手を打たなくちゃならない。その基準は、まだよくわからない。
| 固定リンク | コメント (0) | トラックバック (0)
久しぶりに直交表/HAYST法関連のブログ記事～。
==
以前ご紹介したブログで直交表やHAYST法についての考察が出された。
マイリストに「ソフトウェアテストにおける直交表(HAYST法、All-pair法)の利用」をアップ by つれづれなる技術屋日記
・ソフトウェアテスト開発技術者やソフトウェアテスト技術者にとって未知の世界
・タグチメソッド自体が賛否両論
・直交表自体の学習の難しさ
・実験計画法の記述のほとんどが、数式と表
・ベースとなる統計や代数・幾何
直交表とかタグチメソッドとかいう名前を会社の上司に話したとしても、知ってる程度で実際に直交表の書かれた紙や画面を見せると、苦笑い、といったことが多い。これは指摘の通り、未知の世界だということが大きいかも。今や大学在籍時の専攻が理学系だったとしても、なかなか数学って敬遠されがちな分野。行列とかベクトル空間とかあんまり記憶にないのが現実。だから、「直交(orthogonalかな？)」という概念もすぅ～っと頭に入りにくい。
僕はちなみに数学を主専攻にしていたので、大学時代ぶりの数式を見るとけっこう楽しい。ツボだね。それは同僚からすると意外に稀有な存在に映るらしい。
・タグチメソッド（品質工学）との間隙（中略）
・SN比など重要な概念が、電気・機械・化学等の計測した数値の場合が多い
・体系が、電気・機械・化学等の事例をベースに確立されている
タグチメソッドについて浅学すぎて議論についていっていないかもしれないが、ここで僕の考えは少し違う。そもそもタグチメソッドを利用したソフトウェアテストという体系と、直交表を使ったソフトウェアテストという体系は別物だと考えてます。どういう理屈からかというと、、、
# 以下、浅学なため見当違いの意見を含むかもしれませんので、ご指摘を。。
タグチメソッドを説明するサイトで多く見られるのが、平均値が正確な技術と分散が小さい技術、どちらを優秀と評価するか、といった例が挙げられている。このメソッドによって、例えばどういった環境とどういったデータでソフトウェアは想定した動作をするかを評価はできる。あるいは、サーバのCPU性能、メモリ搭載量、ディスク性能といったパラメータがどのように処理性能に影響するかを評価するときに利用できる。
直交表は任意の2列が直交という性質を持っていて、それをテスト条件の因子に当てはめると、効率的なテストケースのパターン作成に役立つ。例えば、ON/OFFの2種類の条件が7つあった場合、組み合せ数は2の7乗＝128通りが想定できるが、任意の2条件についてすべて網羅できるという制約をつければたった8通りのテストケースで網羅できる。また、ソフトウェアによっては3条件以上の網羅を必要とする場合があるが、それも田口博士の工夫によって網羅率を高める方法が存在する。
以上のように、ソフトウェアテストへの応用について言えば、タグチメソッドと直交表とは区別したほうがいいのではないか。と、私見ではあるが考える。
少ない利用事例・タグチメソッド自体、ソフトウェアでの利用事例発表が少ない
・HAYST法利用での発表も同様
・All-pair法利用での発表は皆無（特に日本。参考文献5は貴重）
ほんっとに、少ない。ソフトウェアテスト全般に活用できるとは思っていないが、局所的にはすごく便利なツールなのでもっと文献や資料、事例がないと、なあ。タグチメソッド(というかSN比)の活用については、負荷分析に利用できる、といった示唆はあったが、それくらい。
・ソフトウェアテストのイメージ（困難な直交表経験者の流用）（中略）
・従来のタグチメソッド用ツールが使えない（HAYST法のツールはソフトウェア専用。たぶんAll-pairも）
・逆にソフトウェア直交表ツールを、ハードウェアのタグチメソッドに使えない
お互いのツールがお互いを意識していないから、だろうか。
・ホワイトボックステストへの利用（中略）
function funcA(a1, a2:integer)
：
：
function funcA(b1, b2, b3:integer)
：
：
function funcA(c1, c2:integer)
：
：funcA～funcCを因子へ
a1～c2を水準へ
なるほど。この考え方は僕にとっては新鮮でした。単体テストケースで直交表を利用するというのはやってみたいな。ただし、関数I/Fが変更された場合はおそらくゼロから単体テストケースを作り直す必要はありそうだ。
==
いや～、ＰＤＦ７６ページの大作。読みごたえあり。すべてについて感想や意見を書く時間はなかったけれど、何かアクションしたかったので記事にしてみました。直交表って魔法に見えたり、難解なパズルに見えたり、いろんな顔を持ってるので、感じ方も千差万別かな。
| 固定リンク | コメント (2) | トラックバック (0)
昨日のグレーボックステストについての続き。というか思いつき。
==
ブラックボックステストといっても、全くソース構造を知らないままで行う真っ黒なブラックボックステストと、ソース構造を把握した上で(例えば実装担当者がテストケースを作成する場合など)行うブラックボックステストでは、手法・効率・精度などで違いが出てくる。一般的に前者は「ブラックボックステスト」と呼ばれ、後者は「グレーボックステスト」と呼ばれる。
そこで。
高校のときに見た(確か旺文社の問題集)名前付けを思い出したのだが、「缶詰テスト」と「ビン詰テスト」という表現はどうか。「缶詰」は中身が全くわからない。「ビン詰」は中身が一応見える。でも両者ともに機能は一緒。
名前なんてどうでもいい、か。。
| 固定リンク | コメント (4) | トラックバック (0)
実家に電話したら、地デジが映るようになったらしい。おめでとう。
==
凄いプログラマはバグを多数見つけられる by Geekなぺーじ
凄いプログラマな方がテストを行うと、大量にバグを発見してくれる凄いテスターになってくれます。（中略）
凄いプログラマな人がホワイトボックステストをしてくれて、バグが潜んでいる行まで示して「バグってない？」と言われてしまうと「ごめんなさい。ありがとうございます。」以外に何も言えなくなります。 そのような方法でバグ指摘をしてくれると、何が原因でバグっているかを調べる時間が軽減されてコード書きが非常に迅速になります。
凄いプログラマーは経験的に・無意識的に効率的な欠陥発見スキルを持っていて、どんどんバグを釣り上げる。それは体系的な品質工学やテスト技法を学んでいるわけではない。しかし、そういったプログラマーはほんの一握りであって、プロジェクトメンバー内には凄くないプログラマーは僕を含めて数多くいる。そういった僕らは人の真似をしたり、勉強をしたりして、意識的に効率的な欠陥発見スキルを磨かなければならない。
個人的には、超凄いプログラマ数人と、きっちり網羅的にテストを出来る性格のテスターさんの組み合わせが最強な気がします。 ただ、超凄いプログラマをテストに投入するよりはコード書きに投入するという場合が多いとも思います。
著者のご指摘のとおり、凄いプログラマ＋地道な網羅的手法が得意なテスターのコンビネーションが最強とは思うし、凄い人はコーディングに投入してしまう。ということは、現実的にはわれらのような凡人的プログラマでもブレ・ムラのない品質を保てるようなツールやスキル習得方法、文化が求められると思う。まさにベストではなくグッドプラクティス。
| 固定リンク | コメント (2) | トラックバック (0)
今日は休暇。久しぶりにまともな更新。
==
ふと、グレーボックステストってどういうものだろう？と思って調べてみた。
ある程度、作りが分った上で実施するテストをグレーボックステストといいます。（中略）
グレーボックステストはアーキテクチャが分っていることに意味のあるに時に用いるやり方で、ユーザビリティテストの様に仕組みを知ることがかえってマイナスとなるテストでは適用すべきではありません。「こう作っているのだから、そう動くべきだ」という見方と、「こう使いたいのだから、（作りがどうであろうと）そう使えるべきだ」とでは検証で目指すところが違うからです。
この定義だと、ホワイトボックステストでもなく、ブラックボックステストでもない検証項目、といったイメージ。ホワイトボックステストケースとブラックボックステストケースを優先順位で並び替えた総合テストケース群、ということではない。
しかしだ。
例としてABS（アンチ・ロック･ブレーキ・システム）の動作確認をするケースで考えてみましょう。構成を何も知らず、要件として「ABSスイッチがONの時は、急ブレーキをかけてもタイヤがロックしないこと」ということだけを知っていて、検証するケースがあるとします。この場合と「ABSスイッチがONで、時速XXｋｍ以上にて走行時、踏力XX㎏以上でブレーキングされ、タイヤのロックがセンサにより検出された場合にはABSを作動させる．．．」という仕様をテストで確認するケースとでは、検証の詳細度がかなり異なります。
グレーボックスは後者に当たり、
ここでは「ABSスイッチがONで、時速XXｋｍ以上にて走行時、踏力XX㎏以上でブレーキングされ、タイヤのロックがセンサにより検出された場合にはABSを作動させる．．．」をグレーボックス的なテストケースと位置づけている。
でも、これはABSスイッチの状態、走行速度、ブレーキの踏力、センサーの感知といった条件での動作確認であって、仕様書に載っている条件と思われる。それってブラックボックステストケースになるんじゃ？
「黒と白の中間」と表現されることが多いグレーボックステストだが、意外にわかりにくい定義な気がする。
==
今、自分なりのTDDっぽい開発をしているが、そこでのテストケースはグレーボックスだなあと思っている。が、それってもしかしたら黒と白をあわせただけのテストケースなのかも。これってどうなのだろうか。
====================================================================
2006年11月29日 追記。
JUnitと単体テスト技法―JUnit4対応 by それはBooks
このブログではコンピュータ書籍, デザイン書籍, ビジネス書籍, その他の書評を行っているようで、
このJUnit の使い方と単体テストについての書籍中では以下のように解説している。
ブラックボックステストブラックボックステストは、プログラムの仕様を元にテストを行うものです。プログラムの内部構造は考慮せず、入出力の仕様に注力します。
ブラックボックステストとして、次の4つのテストがあげられています。・同値クラステスト
・境界値テスト
・デシジョンテーブルテスト
・強制エラーテスト
・グレーボックステスト
ここではグレーボックステストは、ブラックボックステスト技法のうちのひとつになっている模様。
| 固定リンク | コメント (2) | トラックバック (0)
3因子間組み合せ表を視覚的に表現する前に、まずは3因子間組み合わせを洗い出す方法が必要だ。
上図のように因子A、B、C、Dがあり、それぞれ3水準、3水準、2水準、2水準だった場合は、2次元マトリックスを作成して、クリーム色のマス目をカウントすればよい。この図では合計37通りとなる。
では、3因子間組み合わせ数はどうなるか。まずは3因子の選び方。これは4因子の中から3因子を順序なしで選択するので4通り。高校で習った順列組み合せと同じだ。実際には下図の（0、1、1、1）、（1、0、1、1）、（1、1、0、1）、（1、1、1、0）の組み合せが3因子の取り方になる。4パターンそれぞれで組み合せ数を計算し、合計した60通りが3因子間組み合せ数となる。
余談だが、因子数が3のときは3因子間組み合わせは2因子間組み合せよりも少なくなる。2007/11/07訂正
あきやまさんからのご指摘。 因子数が3の場合は、2因子間組み合せ数 ＝ 3×k×k
3因子間組み合せ数 ＝ k×k×kとなるので、k＝2、3のときは3因子間組み合わせが2因子間組み合せ以下、k≧4のときは必ず3因子間組み合わせは2因子間組み合せ数よりも大きくなる。
# これはまだ視覚的には複雑すぎる。どうにかしてわかりやすい表ができないものか。
# もう少し考えてみる。
| 固定リンク | コメント (2) | トラックバック (0)
自動テストツール導入時の注意点 by ただいま修行中...
テストを自動化することで、生産性は向上するのか？自動化に向くテストは、同じテストを繰り返し行うテストである。
自動化に向かないテストは、1回しか実施されないテストである。（中略）
自動化することで、逆に効率が低下することもあるので、慎重に検討し、実施する必要がある。
テストを自動化することで得られる最も大きなテストは「回帰テスト」だと思っている。日々テストケースを積み上げていき、それを回帰テストという形で何度も繰り返すことで、一定の品質を低コストで保証できること。例えば製品として世の中に送り出してしまったら、はいそれまで、といったプロダクトに関しては、テストの自動化はあまり適さない。
先日の勉強会に参加していた方も「思ったよりも自動化によるコスト削減は望めないのが実情」といっていた。逆にテストの記録(テストスクリプトの作成)が第1回目のテストでは必要になるためコストがかさむ、という。世の中にはうまい話はないのだ、テストツールの宣伝文句を鵜呑みにしないように気をつけたほうがいいかも。
| 固定リンク | コメント (0) | トラックバック (0)
HAYST法について、今一度確認のためいろいろな資料を読んでいたら、自分が大きな勘違いをしていたことに気づいた。当初水準値を決定するときに、「同値分割」「境界値分析」「エラー推測」をすべて駆使するものだと考えていたが、そうすると水準数がけっこう大きくなることが多い。単純にメールアドレスを入力するtextフィールドでも、
となって、多すぎ。グルーピングしたら2因子間網羅率もかなり下がりそう。うーん。(大文字小文字区別は別因子)で、いろいろ資料を読み返してみたら、組み合わせテストで設定される水準値は正常系についてが一般的なのだった。組み合わせテストでは、正常系同値分析と正常系境界値分析で水準値を設定し、エラー推測や異常系は単因子テストで確認することがベターらしい。(正常系と異常系のカテゴリミステイクについてはまた書くので、ここではご容赦)
自分としてはすっきりとした気分だ。でも、これも解釈が間違っていたら、どうしよう。
| 固定リンク | コメント (0) | トラックバック (0)
前回よりも直交表の割り付け方を工夫したので、サイズも小さいし、多因子間網羅率も高いはず。。。
次の課題は、2因子間網羅率の計算と、3因子間網羅率の計算、かな。とりあえず今日はここまで。
| 固定リンク | コメント (2) | トラックバック (0)
社内の技術系勉強会でテストプロセスについてプレゼンするので、その資料作りをした。話したいことは山ほどあるけど、時間も限られているし、まずはデスクに帰ってすぐ実践できること、を話そうかと。例えば、テストケースの精度を向上させるために「エラー推測」「境界値分析」という手法を使いませんか？みたいな。
おそらくは経験豊富な方々は無意識的にやっていることでも、勉強会という場でそのことを「気づき」として得られればいいと思ってます。経験の浅い方々には、この基本的な手法だけでもぐーんとバグ検出の割合がアップする、はず。
目標としては、この勉強会を含めて同志を集めて社内的にワーキンググループを結成して、どんどん推し進めていけるのが理想。社外の、かなり有名人とのコネクションもあるらしいので、期待大！
でも、実際はやってみて反応をみてみないとな。。。
| 固定リンク | コメント (0) | トラックバック (0)
今週は上司との上期成果の評価面談。特に目立った成果がないのだが大丈夫かな。。。製品検査で99点もらったのと、社外ワーキンググループのパネラーになったのとかを全面に出してみるかな。
==
直交表を左から低次な順に並べることで、右側の列に3因子間網羅率100%な列が集中することは、前に書いた。もうひとつ左側に並ぶ低次列に着目すると、0と1が比較的バラバラに出現することはなく、ある程度まとまって出現している。これは観点の違いによってメリットであったり、デメリットでもあったりする。
以上のように、低次な順に並べることでメリットとデメリットがあるが、Webサービスの組み合せテストという観点でいえばメリットを享受できることが多いと思われる。
※本記事はあきやまさんのコメントを参考にしながら書きました。
| 固定リンク | コメント (0) | トラックバック (0)
直交表をソフトウェアテストの条件組み合せ抽出に利用する最大の目的は、多因子間網羅率を100%にすることである。ソフトウェアの特性にもよるが、まずは2因子間の組み合せ網羅率を100%にすることが考えられる。この100%とはどういうことか。
上記のような単純な2次元マトリクスを利用することですべての組み合わせは交叉のマス目に出現する。同じ因子同士の組み合せは対角線上に出現し、2因子の順序を入れ替えた組み合わせは対角線を対称軸として上下に出現するので、必要なマス目は限られてくる。そして、このマス目数が2因子間全組み合せ数(53通り)となる。図では水準のグルーピングなどの手法を使ったため、直交法に出現しない組み合わせが4通り存在する(白色のマス目)。2因子間網羅率とは図でいう直交表に出現した黄色いマス目(49通り)の出現割合となるので、この場合は92.45%ととなる。
この網羅率を100%にするほうほうはいたって単純で、白色のマス目で表される組み合わせのテストケースを追加するだけである。
3因子間の全組み合わせを視覚的に上手に表現した表はまた今度紹介します。
| 固定リンク | コメント (6) | トラックバック (0)
今更ながらユースケースの勉強をきちんとしたほうがソフトウェアテストももっと深く勉強できそうな気がしてきた。
==
状態遷移表という表記方法があって、2次元のマトリックスを縦軸(あるいは横軸)に現在の状態を、横軸(あるいは縦軸)に遷移後の状態をとり、その交叉するマス目に該当するイベントを記述するものである。表現の形式によってはイベントを横軸や縦軸にとったり、矢印などを用いた有向グラフの形で表現される場合(状態遷移図)もある。（下図はウィキペディアより引用）
Webサービスにおける多くの組み合せテストはある画面Ａからある画面Ｂへ遷移する際の条件をベースにして作成されるのであれば、この状態遷移表をうまく使って組み合わせテストケースの組み合せを考える手法があってもいいんじゃないかと。（すでにあるのかも）
また、上図でいえば行単位で眺めると、S1にはD1とD2の遷移が考えられ、S2にはD3,D4,D5の遷移が考えられる。これはS1の遷移に関する因子が「D1」「D2」という水準値をもつ、とも捕らえられるので、その組み合わせを効率的に作成することもできるだろう。実施カバレッジは100%とする必要はないが、設計カバレッジを向上させる手法にはならないだろうか。
| 固定リンク | コメント (0) | トラックバック (0)
先ほどの本に続いて、ポケットブックではなくきちんとした書籍も購入。
こちらについてはまだamazonから届かないので、届き次第のレビューということに。
| 固定リンク | コメント (0) | トラックバック (0)
JSTQBという認定試験があり、基礎的な知識を確認するためにはよい試験かと思ったので、勉強して受験してみようかと。ということで少し軽めの問題集みたいな本を購入。
分厚くもなく、要点をおさえておけてなかなか使いやすい本ですね。演習問題は全くひねりはなく本当に自分の学習度を測るのが目的であれば使えます。カバンに入れておいて電車とかで読もうと思います。これを読んでみると今までの僕のブログでの用語の使い方は統一性もなく、お恥ずかしい限り。。。そこらへんも注意してこれから記事を書いてみようっと。
| 固定リンク | コメント (0) | トラックバック (1)
ひとまず、サンプル2号を作成。でも、やってみると直交が崩れてる。。。ショック。。。
今日はもうおしまい。
==
自分で試してみた。因子数は14個、いくつかは多水準化が必要な場合でやってみたらサイズが128に膨れてしまった。この大きさは妥当なのだろうか。それに、テストケースは出来上がってるけど、本当に網羅してるのかってのが一目じゃわかりにくいな。何か検算機能をつけてみるかな。
| 固定リンク | コメント (2) | トラックバック (0)
各方面でソフトウェアテストについてのブログ記事が登場してて、それを読むだけでも勉強になりますね。
==
テスティング -テスティングの勘所- by 今日思うこと
ソフトウェアも人間がくみ上げるものであるから、バグの出方にも当然個性が出てくる。あるプログラマーは偉ー処理を軽視する。別なプログラマーはルーチン処理でよく無限ループにはまってしまう。などなど。（中略）
話を戻そう。バグのくせを見つけるためには、まずプログラマーの性格を知ることが重要となる。そのために私はよくプログラマーに話を聞きにいった。仕様をどう理解しているのか、その理解をどういうアルゴリズムで実装しようとしているのか、自分でも自信がないところ、などなど。雑談を織り交ぜながら、しょっちゅう話を聞きにいった。
ソフトウェアテストの原則「欠陥の偏在」にも似たところがあるが、不具合は特定の箇所に集中しやすい。それは一般論として不具合を生みやすい要因があるのかもしれないが、実装を行ったプログラマーの癖や特性というのも大きく関わっていると思う。例えば、グローバル変数を使いやすい人もいれば、極力使わずに実装しようとする人もいる。構造体を多用したり、低水準のシステムコールを使用したり、様々である。
そういった癖や特性については主に静的レビューである程度把握することができると思うが、それはたいてい同じプロジェクトメンバーであり、開発する側の人間がレビュアーとなるのではないかと思う。マストさんの手法は、テスト担当者がその担い手となるというアプローチであり、より進んだ手法ではないかと思う。直接ヒアリングする、というところまではいかなくても、まずは癖や特性をデータベース化（見える化？）するなどのひと工夫によって、少しは効果が得られるのではないかな。
そうやって、担当プログラマの性格＝実装パターンが見えてくればしめたものである。某超有名アニメの腐海
に遊びにいく主人公が風が見えるように、目の前のソフトウェアにバグが見えるようになってくる。
この境地に達したテスト技術者はかなりすごいね。まさに救世主。青き衣のもの。
| 固定リンク | コメント (2) | トラックバック (0)
ソフトウェアテストには7つの原則(*)があって、そのひとつに「テストは欠陥があることしか示せない」という原則がある。これはどういうことかというと、テストというプロセスでは「不具合がない」ことは示せない、示せるのは「不具合がある」ことだけだ、ということを意味している。つまり、テストの目的＝不具合を見つけ出すことなので、より多くの不具合を見つけられるテストケースが優秀といえる。
テスト仕様書に「正常系/異常系」のカテゴライズは必要？ by クライングドーベルマン
第三者テスト、とかソフトウェアテスト専門部隊、に属する僕個人の意見としては、「正常系/異常系」のカテゴリーはテスト仕様書には特に必要ないように感じる。多分、「正常系/異常系」というカテゴリーはテスト実行の優先度として使用する目的で設定していると思うが、「とりあえず正常系から先にテストする」という戦略は時として重大なテスト漏れを発生させる危険があると思う。（中略）
非常に極端な例ですが
5万ページを端から端まで印刷する正常系
パスワード欄に「' OR 1=1--」と入力する異常系
システム運用上、一般的に言って後者の優先度のほうが高いと思う。
極端な例ではあるが、まさにその通りだと思う。僕も一昔前は「正常系/異常系」というカテゴリーを使ってテストケースを分類していたし、今でももしかしたらそういったカテゴライズを念頭に考えているときも、あるかもしれない。もちろん、このカテゴリ分けが正しい場面もあるだろうが、テスト実施の優先度をきちんと分析する、という癖をつけないと、上で挙げられているような本末転倒的なテストをしてしまうかもしれません。
いうまでもないが「正常系には不具合がないからサボっちゃえ」という意味ではないです。5万ページの印刷は
極端な例ですが、10000件登録可能なアドレス帳についてはきちんと10000件登録でき、利用できることを試す
必要はあります。（CSV形式ファイルのインポート機能がついてたりするので）
このブログはあとでもっとみておこうっと。
| 固定リンク | コメント (0) | トラックバック (0)
先日みつけた今日思うことより。
テスティング -テスターの条件- by 今日思うこと
次に大切なこと、それは 『ものの見方が柔軟である』 こと。「マウスはマックのように１ボタンでなければならない」 といったように 「ＯＯＯ は ＸＸＸ でなければならない」 的な発想では質の高いテスティングは望めない。ユーザーは時に、開発者がまったく想定していない使い方をするものである。想定をしていない ＝ 作りこみをしていない ＝ テストもしていない ＝ バグが発生する、という構図になる。
会社に入った当初、僕のトレーナー役だった先輩からよく「テストをするときは天邪鬼になってやろう」とアドバイスしてくれたことを思い出す。普通に使っていては不具合は見つからず、単に消化したテスト項目数を増やすだけ。当時は感覚的にはわかった気がしたけれど、ソフトウェアテストの勉強をして、エラー推測・境界値分析というキーワードを目にするまで具体的に自分の手法としては確立していなかったと思う。
マストさんがおっしゃっているテスターに必要なこの能力は、エラー推測や境界値分析の観点に近い考え方かも、と僕は捉えています。何年もシステム開発に携わっている方からすれば、そんな手法勉強しなくても経験上やってたよ、という意見が出てくる気がする。でも、こうやって誰かの口から、どこかのサイトでひとつの手法として目にすることで、より一層自分の中の確固たる技術として根付くんじゃないかと僕は考えています。ソフトウェアテストについての勉強にはそういった意義があると信じています。
僕がもうひとつテスター（＝テスト技術者）に必要な能力を挙げるとしたら、それは妥当性検証力、かな。世の中にはいろいろな統計情報やメトリクスがあります。網羅率○○％、ステップ数あたりの不具合数、工数あたりのテストケース数、などなど。その中で、今自分が扱っているプロジェクトにはどの指標が適切なのかを見極める能力です。自分にその能力がなくても、誰と検証をすれば見極められるかがわかれば、それもＯＫ。そこらへんの能力は一言で「バランス感覚」という言葉にも帰着するのかも。
みなさんはどんな能力が必要だと思いますか？
| 固定リンク | コメント (2) | トラックバック (0)
昨日の夜から風邪のためだるくかったので、薬を飲んで、雑炊とかを食べてだいぶ楽になってきた。
==
テストケース作成ツールの一部がだいたい形になった。2因子組み合わせテスト作成部分。直交表をベースにしてHAYST法に沿った多水準化（＝2乗化法）で実装。サンプルとしてGmailのメール作成画面でのメール送信パターンを使ってみた。因子や水準の抽出はかなり適当。。。
何か気づいたことをコメントしてくださると助かります。＞見てくださった方々へ
※追記
- ボタンを押すとテストケース表が表示されます（10/08）
- javascriptも初心者なので気づいたことがあれば（10/08）
| 固定リンク | コメント (0) | トラックバック (0)
東京地方は大雨な一日になりそうです。
==
直交表という組み合せテストの手法を勉強していて、以下のようなブログ記事に遭遇。
直交表の功罪 by つれづれなる技術屋日記
その人は、ソフトウェアでの組み合わせテストを直交表で作る事になっているんだが、成果としてもう○ヶ月近くモノが出ない。たった一つの直交表すら出来てこない。そもそもどんな組み合わせテストをするかで、細かい部分とおおざっぱな部分とで粒度がいい加減。因子と水準はそれなりに抽出しているが、機能のための因子が相当足りない。(中略)
直交表の功罪かもと思った１日。ソフトウェアテストでの直交表の利用自体は、喜ばしい事だが、人によってはそれによって万事解決と思う人もいるみたい。
ソフトウェアにおける統合テスト・機能テストは、さまざまな条件を変えてシステム動作が仕様どおりに動作するかを確認する必要がある。単純に「条件の個数×条件の振り幅」で組み合わせを考えると非現実的な組み合わせをテストケースとして考慮しなくてはならない。でも、一般的には1条件、2条件〜3条件の組み合わせが網羅されているだけで、ソフトウェア内の不具合のほとんどが検出できると言われている。（何条件まで検証が必要かはそのプロジェクトの特製、コストや要求される品質によって変わる）
ソフトウェアテストで直交表を利用するというのは、2条件、あるいは3条件の組み合せ表をなるべく少ないテストケースで網羅しよう、というアプローチのことで、このブログの著者がいっているように「万能」な道具というわけではない。適切な因子と水準の抽出ができなければ不具合の検出が少なくなるだろうし、直交表を適用できない場合もなくはない。
今作成しているツールでも直交表を利用した組み合せテストケースが登場するが、やはりツール利用者の経験量・知識量などが因子と水準の抽出に影響するので、アウトプットに品質のブレが発生する可能性がある。「テストケース作成における生産性」は向上しても品質が追いつかないとまずいな。この問題の解決手段としては、今のところ「サジェスト機能」くらいか。もう少し工夫が必要かも。
また、直交表の話になってしまったが、とりあえず今朝邂逅したブログ記事についてでした。
| 固定リンク | コメント (0) | トラックバック (0)
インスペクションとは、「不具合を作らない手法」で、テストは「不具合は見つけ出す手法」だと僕は思って
いて、【松尾谷徹が語る】現場力を高めるテスト(1)でも同様の考え方が掲載されている。
テスティング -ソフトウェア・テスティングとは？- by 今日思うこと
私がソフトウェア製作を説明する上でよく使う例えが “三権分立” である。“仕様の策定（スペック）”＝立法、“仕様の実装（プログラミング）”＝行政、“仕様の検証（テスト）”＝司法となる。つまりテスティングとは、裁判所の仕事に当たる。
この三権分立の例えは、なるほど、と思った。仕様というテストにおける「法律」が存在し、裁判、すなわちテストはその「法律」を基準にして実施され、裁かれる。この例えを使えば、インスペクションというアプローチは法律を制定するところで実施される手法、ということになりそうだ。品質という数値化しづらいことを扱うのでテスト完了の見極めが難しいと言われるが、このブログでいう上流工程でのテスティング（≒インスペクション）の評価も意外に難しいんじゃないかな、と最近思ってます。
次回以降もこちらのブログは期待してます。
最近はこういったソフトウェア品質向上関連のブログがけっこう目立つようになってきて、勉強しやすくなってきたな。
| 固定リンク | コメント (2) | トラックバック (0)
今回は3つのプロセスの中で「テスト」に焦点をあててみたいと思う。
==
テストの手順として思いつくものとして、
といったステップが考えられる。まずはテスト対象を抽象化したり、ドキュメントからテスト対象を明確化したり、ドキュメントに載っていない性質を洗い出すことからはじまる（分析）。その分析を元にしてテスト対象の品質を向上させるという目的で、どういった検証をどういった期間でどういったアプローチで行うかを検討する（テスト設計）。設計されたテスト計画は、掘り起こし作業によってより具体的な項目となり（テストケース作成・実装）、その検証作業が実行される（テスト実施）。検証結果が当初の目的＝テスト対象の品質向上が達成されたかを確認し（評価）、テストプロセスは完結する。
このプロセスの中で明確化されてはいないが、重要な作業として私は「テストケースの順位付け」を挙げたい。テストケースの並べ替え、でもよい。順位付けはテスト設計者によって多少変わるだろうし、プロジェクトによっても変わることが予想されるが、私の考えではより影響度の大きい、より重要度の大きいものをテストケースの処理順序で前のほうに配置し、比較的軽微なテストケース（文言チェック・静的リンク切れチェックなど）は中間くらいに、終盤には組み合せテストケースの網羅漏れケースを配置すべきではないかと考えている。まずは修正コストの大きいと思われるテストケースの検証を行い、最後はフリーテストと似た位置づけで網羅漏れテストケースを実施する。
さて、皆さんはテストケースの順番はどうやって決定していますか？
（続く）
| 固定リンク | コメント (0) | トラックバック (0)
やっぱり、やみくもにコードを書くのはよろしくないな。
==
今作成中のテストケース作成ツールでは
あたりを自動的に作成しようかと。
各画面チェックケースというのは、静的情報の確認がメイン。レイアウトチェックとか、画像表示チェックとか、リンク切れチェックとか。そこらへんは別に自動的に作成しなくてもいいんだが、まーせっかくなので。
各画面フローに対する組み合わせテストケースというのは、「○○条件で△△を実行した結果は□□となるはず」といったテスト内容になるはずなので、
となる予定。ここではなるべく3因子間網羅率を100%にしながら、水準組み合わせを行う必要があるが、それについては今までここで書いてきた情報が役に立つ。グルーピングなどによってn因子間網羅率が100%を下回るケースもでてくると思われるので、そこも自動的に計算して表示させたいな。
# ところで、2因子テストケースを作成すると、実は1因子テストケースって含まれちゃってる気がするが、どうなんだろう？？？
シナリオテストは、一般的には視点を変えて（不正利用を試みるユーザ、初心者ユーザ、といった視点で）実施することを指すのだが、うまく表現できるかなあ。
あと考慮すべきこととしては、各テストケースの優先順位か。それと、因子・水準などのサジェスト機能。境界値分析やエラー推測をさくっと設定できたり、を目指して。
| 固定リンク | コメント (0) | トラックバック (0)
直交表を用いることで2水準間網羅率を100%にすることは可能。3水準間網羅率を100%にするにはどうしたらよいか。そこで登場するのが交互作用という概念である。
L8の場合、8＝2の3乗なので基底となる列が3つ存在し、それを左からa、b、cと名前をつける。そのとき交互作用のあらわれる列がこの直交表でいうと4列目、これはすなわちa＋bの列である。この3列（オレンジ色）を見比べてみるとパターンは4パターンしかない。2水準の因子が3つなので実際は8パターン出現しなくては網羅率は100%にはならない。したがって、この場合は4列目（＝a＋bの列）を除外することで網羅率を上げることができる。（ある資料にある言葉を借りれば「強度が増す」と表現されるかな）
L16の場合、L32の場合も同様である。
| 固定リンク | コメント (4) | トラックバック (0)
先週、「プロジェクト成功のためのソフトウェアテストの勘所」というセミナーが開催された。興味もあっていってみたかったが、都合がつかず。ということで、ネットで参加者のレポートを検索。。
「プロジェクト成功のためのソフトウェアテストの勘所」参加レポート を書きました(アークウェブ ビジネスブログ)
「プロジェクト成功のためのソフトウェアテストの勘所」参加レポート(wiki)
主にソニー高橋寿一さんの基調講演のポイントがメモされている。テーマはテストの自動化と理想と現実についてであり、安易なテスト自動化への傾倒には罠がある、といった感じだ。僕も今テストケース作成をツール化しているのだが、あまりにも網羅率への意識が強いとテストケースの肥大化と無駄化が進んでしまい「バグをみつける」という目的から逸脱しそうになる。サービス/機能を全て網羅することは重要ではあるが、それはテストのもうひとつの目的、「品質保証」の切り口でなければ意味がなくなってしまう。
「テスト網羅率100%です」などといった頭の悪いこと言わないようにしよう
まずテストケースを設計するときは網羅率100%を目指して作り、そのあとから有効なものや優先順位の高い項目をリストアップしていく、といった作業がいいんじゃないかと今の僕は考えている。著者のいうとおり、ただ安直に「網羅率100%」というだけではコストに見合った品質は得られない。
# 網羅率100%(に近い)テストケースを作るのってすごく大変なので、そこをツール化しようとチャレンジ中
# 万能ではないにしろ、GUIをメインにしたサービス限定とかで実現してみたいな
(自動化に)向かないテスト
- 回帰テスト（賛否両論あり）
僕はどちらかという賛否の「賛成」のほう。扱っているプロダクトの特質からかもしれないが、ここをどう自動化・効率化するかが大きいと思ってます。インターネットのサービスでは総じて同じことが言えそうな気がします。あくまで私見ですが。
状態遷移テスト
- 状態遷移は状態遷移図を書いた後、自動化する価値がある
ポイントだけなので詳細は推測になってしまうが、状態遷移図をインプットとしてテストケースやテスト実行を自動化する、という意味であれば、なるほど、それは価値は意外と大きい。各画面とその遷移グラフから何をチェックすべきか、といったノウハウがあればテストケース作成はある意味シンプルかも？
回帰テスト（リグレッションテスト）
- 上手く自動化する手法はない。自動化には最深の注意が必要
講演者である高橋さんが回帰テストの自動化に否定的だからなのか。もう少し詳細情報がないかググってみるか。
==
その他、かなり有益な情報が載っているので、上記以外はあとで読む。
| 固定リンク | コメント (2) | トラックバック (0)
最初の目的はテストケース作成ツールを作ることだったが、不具合管理機能もつけようっと。
==
機能テストを自動化ツールでチェックすると、テストを実施するコストは大幅に小さくなる。でも、不具合管理はコツコツとやらないといけないな。テスト結果のコンソールとエクセルシートのにらめっこ。社内で導入された影舞はみんな使ってるのかな。
| 固定リンク | コメント (0) | トラックバック (0)
天気予報では午後から晴れるっていってたから、今日は傘なし。やっと晴れてきた〜。
==
直交表の性質も少しずつ理解が深まってきた。ふと、ツールを使って簡単にテストケースって作れないかと思い、昨日からいろいろ勉強中。といって、JavaScriptとスタイルシートですが。力技で作ってしまえ的な勢いです。機能的にはこんな感じのツールをイメージ。
仕事の合間にコツコツと。
| 固定リンク | コメント (0) | トラックバック (0)
最近ネタが直交表ばかりです。僕が今週はちょうどシステムテスト週間だからちょうどいいか。。。
==
先日紹介したよくわかる実験計画法を元に2水準系の直交表をエクセルで作成してみた。L32の直交表に対応する交互作用の一覧表までは作って、あとはL64のサイズだけ〜・・・と思った。が、よく考えてみると今までソフトウェアテストとしては直交表ってL32までしか使ってないな。冷静になってみれば因子数が64ってありえないし、多水準化したとしてもL32であれば十分な因子数が確保できる。ググってみても64なんてサイズはあんまり見ないしな。
懸念としては、交互作用が発生しないように列を選択して3因子間網羅率をあげる工夫をすると、サイズが足りなくなるのかもしれない。
次のプロジェクトで試してみるか。
| 固定リンク | コメント (0) | トラックバック (0)
直交表についてもう少し深い理解をしようと思って、購入。お値段も手軽でグッドです。ソフトウェア・テストPRESSでも直交表・ダミー水準・多水準化といった手法を載せてたけど、こちらはもう少し理論の裏づけを交えながらの解説でした。ベクトルを持ち出すことで直交という概念がより数学的になっている気がします。ちなみに、タイトルからわかるようにメインとなるのは「実験計画」の手法なので、ソフトウェアテストのテストケース作成には必要ない情報も含まれます。
キーワード：実験計画法, ラテン方格, グレコ・ラテン方格, 超グレコ・ラテン方格, 直交表, 主効果, 交互作用,
線点図, 擬水準, 2乗化
| 固定リンク | コメント (0) | トラックバック (0)
今までこのブログで雑記程度にソフトウェアテストについて書いてきましたが、ひとつきちんとした読み物としてまとめてみようと思います。いろいろなセミナー・雑誌・書籍・ウェブサイト・ブログなどを元に学んだこと・発見したことなどを、自身の考察を交えてまとめていけたら、と考えてます。
==
ソフトウェア開発の中でレビュー・インスペクション・テストというプロセスがあります。３つとも目的は一緒で「ソフトウェアの品質を向上させる」のが大前提です。それでは何が違うかというと、それぞれアプローチの仕方が違ってきます。
レビュー・インスペクション - 未然の「欠陥防止」
では、インスペクションとはどういったプロセスでしょうか。
[ITプロフェッショナルのスキル] ソフトウェアプロセス用語集 -インスペクション-
インスペクションの訓練を受けた専門家が、数名の関係者を招集して行うレビュー。参加者には事前に資料を配布しておき、各参加者がレビュー前に問題点を把握しておき、レビュー実施時に指摘するという方法をとることが多い。開発会議より、客観性が高い。
主な手法として2点紹介します。(ソフトウェア・テストPRESS Vol.2 からの引用)
パースペクティブ・ベース・インスペクションは、参加者が各人違う観点を意識しながら対象物を検査する手法です。観点は例えば、エンドユーザー観点・データーベース担当者観点・テスト担当者観点・運用担当者観点など、プロジェクトによって様々な観点があります。多様な切り口からの「気づき」が得られるといった効果があります。
パスアラウンド法は、検査対象物を事前に提出しておき、検査担当者での回覧ベースでバグを指摘してもらうという手法です。検査担当者および関係者を参集する必要がなく、効率的に「気づき」を得られます。しかし、指摘が重複したり、検査担当者によっては回答が遅れたりするなどの問題も認識しておく必要があります。
(続く)
| 固定リンク | コメント (0) | トラックバック (0)
2007/08/07下部に追記。
==
ブログを検索していたら、僕と同じように直交表について書いているブログを発見。
効果的なテストケース生成
直交表 - ソフトウェア・テスト手法 (あるＳＥのつぶやき)
ソフトウェアテストへの直交表の応用
同じことを勉強しようとして、Google先生に教えてもらうとやっぱり似たようなサイトを参考に勉強するんだなあ、と再認識。僕も買いましたよ、ソフトウェア・テストPRESSを。
直交表というのは任意の2つの列に関して直交している表のこと。この場合の直交とは0/1の値を持つ条件について、2条件組み合せが平均して出現するような性質のことをいいます。テストケース作成において重要なポイントは3つあって、
を満たすテスト設計が優秀とされています。直交表を利用することで、より少ないテストケースで網羅率をアップすることができるのです。ただし、直交表にも欠点があり、
大きな水準数(条件の取りうる値の数)の因子を割り付けることが難しい(多水準割り付け)
2因子間網羅率は100%であるが、3因子以上の網羅率は100%を保証しない(多因子網羅率)
という課題がありました。ここで登場するのがHAYST法と呼ばれるテスト手法です。この手法は富士ゼロックスの秋山氏が開発した組み合せ手法のひとつで、多水準割り付けも課題を解決しています。具体的な多水準割り付け方法については以下の資料が参考になるかと思います。
直交法を活用したソフトウェアテストの効率化-HAYST法の活用-(PDF)
あるいは、ソフトウェア・テストPRESS Vol.2でも同じ解説が載っています。
直交表というなかなか取っ付きにくいツールに加えて、線点図など新たな語句が登場して、さらに敷居は高くなった気がしますが、実際に試してみれば理解と実践方法が馴染んでくると思います。おそらくうちの社内勉強会のときもケーススタディを用意して実際に体験してもらうのが一番じゃないと思ってますし。
残るは多因子間網羅率の課題です。プロジェクトの性質によっては2因子間組み合わせの網羅だけで十分な品質が得られる場合もありますし、3因子間網羅率を100%にする列を使うといった手法も秋山氏は取り上げられいますが、この課題については、僕らへの宿題かな、なんて思っていろいろ作戦を考えてる最中だったりします。
アイデアとしては、因子を2種類くらいに分類して単純に組み合わせる手法で今は多因子間網羅を実現しようとしてます。当然、テストケースはかなり膨張しちゃうんですが。。。
==
2007/08/07
ソフトウェアテストに直交表を用いたテスト手法「HAYST法」についてのバイブル！日科技連出版「ソフトウェアテスト HAYST法入門」が出版されました。
僕も購入して読んでみましたので、こちらをご参考にしてもらって興味があれば、さあ入手だ！
| 固定リンク | コメント (2) | トラックバック (0)
今日の午後は珍しく外出。議事録用にノートＰＣ持ってくるの忘れちった。
社内の別のチームでテスト設計やソフトウェアテスト手法について勉強したいというリクエストがあったので、簡単な資料を作ってミニ勉強会を開催。そのチームは基本的にはWebサービスのテスト工程の短縮を模索していて、どうにかテスト実施の工数を減らせないか？という課題を持っていた。僕のプレゼンでは主にテストケース作成のコツをメインに説明したので、少し軸がずれていたのかも。
テスト実施期間の効率化は素直に考えて、やっぱり自動化/テストツール導入が一番効果的。少しそのあたりを地道に調査してみようかな。
直交表を利用して3因子間網羅を高める手法って、どこかに詳しく出てないかなあ。
| 固定リンク | コメント (0) | トラックバック (0)
雨が多いなあ。
今日は今まで調べたり実践したりしたテスト設計(テスト手法)について他のチームにプレゼンする。仕事の合間を使ってパワポにまとめていた資料を使うのだが、はたして上手に伝えることはできるだろうか。
これがうまくいったら、社内勉強会としてもう少し大きく広めていこうかな。そのときはケーススタディも準備してみようっと。
==
テスト技法というわけじゃないけど、テストって昔からいわゆるKKD（経験・勘・度胸）だけでやってきたという現場が多いんじゃないですか。KKDでやっている限り、MMK（もうかってもうかって困る）という次元にはまず達しないから基本的なテスト技法くらいは押さえておかないとね。（中略）
Mustというか、テスト担当者は境界値テストを本能でやっていますよ。
境界値分析とかエラー推測なんかは普通に業務を何年か続けていればまさに本能でチェックしてるテストケースなんだろうけど、手順というかフレームワークとしてまとめておいたほうが、考慮し忘れなんかを防げて安心かな、って思う。
| 固定リンク | コメント (0) | トラックバック (0)
有料のシンポジウム。
いくつか参加してみたいセッションがある。資料公開しないかなあ。
SQeBOKってはじめて聞いた。
==
http://www.juse.or.jp/software/symposium_25spcs.html
| 固定リンク | コメント (0) | トラックバック (0)
日本コンピュウェアからのセミナー情報より。
４つのプログラムのうち３つは製品紹介で、１つは事例紹介。
個人的には事例紹介は見てみたい。有償・無償・自作ツールによる
品質積み上げの具体的な紹介は参考になるかも。
==
プロジェクト成功のためのソフトウェアテストの勘所
〜ユーザーが語る実践アプローチと品質を確保するコンピュウェア製品の紹介〜
ITとビジネスが密接に関係する現在、品質の高いソフトウェアを構築することは、
企業にとって重要な課題となっています。ソフトウェア品質保証時代に向け、
テスト手法や方法論などテスト市場は盛り上がりを見せていますが、実際の開発
現場では、どのようにしてソフトウェアの品質を向上させるべきかといった具体
的な情報、および解決策は不足しているといわれています。
このセミナーでは、理想論ではなく実際にソフトウェアの品質向上という課題に
取り組み、そして“品質を強み”に企業活動を行っている企業の具体例を紹介し、
問題解決へのアプローチとそれらを支援するコンピュウェアツール製品をご紹介
いたします。
■ 2006年 9月26日（火） 13:30〜17:00 (受付開始13:00)
■ 青山ダイヤモンドホール （サファイア）
■ 主催： 日本コンピュウェア株式会社
■ 入場無料（事前登録制）
イベントの詳細・申し込みは
http://www.atmarkit.co.jp/event/campaign/compuware/sem060926/cont060926.html
| 固定リンク | コメント (0) | トラックバック (0)
HAYST法 | JSTQB | pairwise・All-pair法 | TestLink | おすすめサイト | ウェブログ・ココログ関連 | グレーボックステスト | コーディング規約 | セミナー | ソフトウェアテスト | ソフトウェア品質 | タグチメソッド | チームビルド | テスト設計 | テスト関連ツール | テスト駆動型開発 | デシジョンテーブル | データフローテスト | ニュース | マインドマップ | レビュー・インスペクション | 例題 | 分析 | 勉強会 | 単体テスト | 原因結果グラフ | 品質工学 | 学問・資格 | 書籍・雑誌 | 状態遷移テスト | 直交表 | 結合テスト | 趣味 | 雑記
最近のコメント