« 2007年2月 | トップページ | 2007年4月 »

無理をしないのが一番だ

体調復活!仕事終わってから勉強するのは少し控えようっと。新しく購入した本はしばらく手付かずかな。

現在品切れ中。

| | コメント (0) | トラックバック (0)

JaSST資料にあるカバレッジ表に近づいている?

ブログのデザインを変更したらコメントできなくなってしまった。。。ので記事としてアップ。

==

前の記事でコメントがあったとおり、#2は不要となる。それを確認するためにチェックリストをくっつけてみた。

Photo_3

論理展開式をどのテストケースがカバーしているかをチェックしてみた。なんだか、JaSSTの原因結果グラフのところのカバレッジ表に似てきた気もするが、気にしなーい。^^

#2がカバーしている論理展開式は他のテストケースによってカバーされていることがわかる。が、同時に#1でも同じことが言えるように見える。ただし、違うところは、もし#1をテストケースに含めないとすると、(年俸1000万円以上、セ・リーグ所属)=(T、F)という論理展開式のカバー数が1になってしまう点だ。(#2をテストケースに含めない場合はそういったことはない)

どちらをテストケースに含めない、としてもいいが、#2のほうがベター、といったところか。かな。

| | コメント (2) | トラックバック (0)

デシジョンテーブルの結合をマトリックスにしてみる

とことん勉強してやる。

==

原因結果グラフの局所的なデシジョンテーブルを結合するときの手順はこんな感じで行っている。原因は僕が適当に考えたもの。

Dt_1

まずは下位にあるデシジョンテーブルを作成しておく。この図でいうと、中間ノード①についてはT=1通りF=3通り中間ノード②についてはT=2通りF=1通り。次にそれら中間ノード(①と②)を条件とするデシジョンテーブルを作成する。結果はT、F、Fの3通り。それぞれについて中間ノード①と中間ノード②の真理値で、多い方の組み合わせ数を採用する。これは論理展開式を網羅するため。例えば、①=T、②=Tの場合、2通りとなり、①=F、②=Tの場合、3通りとなるわけだ。そうすると自然と網羅しながら最終的なデシジョンテーブルを作成できる。

と、僕は認識している。

ここで、#3~#5の「年俸1000万円以上」「セ・リーグ所属」の真理値の組み合わせは、別の組み合わせもある。必要なのは中間ノード②のデシジョンテーブルを網羅しているかどうか。

JaSST'07のパネルセッションにあった原因結果グラフの資料(PDFファイル)を参考にマトリックスを作ってみた。

| | コメント (4) | トラックバック (0)

【改^2】原因結果グラフ デシジョンテーブル作成

原因結果グラフからデシジョンテーブルを作成する、の巻。その3。

==

(1) 原因と結果の洗い出し
(2) 原因結果グラフ作成
(3) 原因結果グラフ修正

では、まずは前回作成したグラフは以下のとおり。



煩雑さをなくすために原因にあたる6つの条件を①~⑥とする。

途中の手順は何度も書いているので省略しちゃう。受信に関するデシジョンテーブルと一時拒否に関するデシジョンテーブルはこれ。
Dt01_3

んで、何度も直している拒否に関するデシジョンテーブルは以下のとおり、中間ノードaを中継して作成。
Dt02_1

最後にそれらを結合し、
Dt03_2

同一のテストケースや集約できるものは集約するとこんな感じ。

  • #2について
  •  #9に集約される。
  • #6について
  •  #5に集約される。
  • #7について
  •  #1と同一なので省略。
  • #10について
  •  #3と同一なので省略。
  • #11について
  •  #4と同一なので省略。
    Dt04_2

    3度目の正直。これであってる、、、はず。
    正直言うと、中間ノードaに関するデシジョンテーブルと拒否に関するデシジョンテーブルを合成するロジックがまだ納得度50%くらい。(⑥、a)=(F、T)の割り付け方が他にもあるんだけれど、なぜこれでいいのか。。。
    マイヤーズの本に沿ったやり方だと、やはりテストケースも違うものになるのだろうか。。。

    | | コメント (2) | トラックバック (1)

    【改】原因結果グラフ デシジョンテーブル作成

    原因結果グラフ デシジョンテーブル作成はコメントで指摘されたように間違ってるところがあって、また作り直してみました。
    #2007/03/17 コメントをいただいたので修正アゲイン!
    #2007/03/17 再チャレンジでも正解にたどりつけてないので、整理してからリベンジ予定~

    ==

    (1) 原因と結果の洗い出し
    (2) 原因結果グラフ作成
    (3) 原因結果グラフ修正

    では、まずは前回作成したグラフは以下のとおり。



    煩雑さをなくすために原因にあたる6つの条件を①~⑥とする。
    1つ目の結果「正常に受信される」について。


    Cegdt01


    これを成立させるためには、

     ①、かつ、not④、かつ、not⑤、かつ、not⑥

    となるので、ここの局所的なデシジョンテーブルは、

    Dt01_2

    という5つのテストケースになる。AND条件のデシジョンテーブル作成方法は後ほど記事にしたいな。

    2つ目の結果は「メールが一時拒否される」について。


    Cegdt02


    これは単純である。


    Dt02


    3つ目の結果は「メールが拒否される」についてだが、これは中間ノードaがある。

    Cegdt03


    ここでの局所的なデシジョンテーブルは

     ②、または、③、または、④、または、⑤
     中間ノードa、かつ、not⑥

    という満足条件なので、

    Dt03_1
    #2007/03/17 画像差し替えしました。

    この2つを結合してみる。

    Dt03a
    #2007/0/17 画像追加しました。

    最後にこれらすべてのデシジョンテーブルを結合するとこんな感じ。になると思う。

    Dt041_1

    ここでテストケースの集約をしてみる。まずは、5列目7列目はまったく同じなので、7列目を削除。3列目10列目4列目11列目も同様に削除できる。また、6列目5列目に吸収でき、2列目8列目と9列目と同等となる。(制約Oがあるため
    #2007/03/17 コメントを修正します。

  • 2列目
  • 8列目と9列目と同値(制約O)なので削除
  • 6列目
  • 5列目と同値なので削除
  • 7列目
  • 1列目と同値なので削除
  • 10列目と11列目
  • それぞれ3列目、4列目と同値なので削除

    Dt06_1


    さあ、見やすくしてみるとこんな感じのデシジョンテーブルが完成する。

    Dt07
    #2007/03/17 画像を差し替えました。中間ノードについても記載。

    なんか、チョーそれっぽいテーブル♪あってるかなあ。
    そういえば、中間ノード名つけるの忘れちゃった~

    | | コメント (6) | トラックバック (0)

    [記事]CUnitによるテスト駆動開発

    CodezineでCUnitの解説が。この前もCによるオブジェクト指向プログラミングが閲覧数ランキングで1位になったりと、C言語も著者が言うとおりまだまだ現役ですなー。

    CUnitによるテスト駆動開発

    テストコードを作成するところでもいろんなテスト技法を使ってみたいね。

    # 最近CUnitで検索されることが多かったんだが、この記事が出てからかも。

    | | コメント (0) | トラックバック (0)

    [書籍]ピープルウエア 第2版

    この前の社外勉強会で紹介されていた古典であり、名著。

    僕もさっそくamazonで購入。読めばパラダイムシフトするって。トム・デマルコって「熊とワルツを」の作者だ。

    今日はこれだけ。

    | | コメント (0) | トラックバック (0)

    テスト技法でテスト設計をしたとき

    イロイロ調べて今更ながらわかったのだが、ソフトウェアテストでのデシジョンテーブルっていうのは、効率的なテストケースを抽出するのに使うというイメージだったけれど、実は複雑な仕様なんかをわかりやすく表現するのが本来の機能なんだ。たぶん。

    ==

    下流工程のテスト(動的テスト)をするにあたっては、

  • より多くの欠陥を見つける

  • より少ないテストケースで実施

  • 網羅性を確保する
  • という目的でいろいろなテスト技法・ツールを扱う。開発者が単体テストなどで無意識的に実施している同値分割や境界値分析、エラー推測。あるいは体系的なテスト技法としては原因結果グラフ、デシジョンテーブル、CFD、直交表、、HAYST法、All-pair法、etc。で、毎回思うのだが、特に後半の体系的な技法を使った場合、どうやってレビューするのが最適なんだろうか。テスト技法に詳しい人がいればその人に見てもらうことは可能だが、たいていそんな人は少ない。「このテストケースがなぜ必要か?」についてはまだ何とかなるにしても「なんでこのテストケースだけで十分なの?」とか「このテストケースはやらないの?」とかってプレゼンテーションが難しいなあ、って思った。

    うまく説明できる技術はまだ僕にはあまりないかも。

    | | コメント (0) | トラックバック (0)

    原因結果グラフ デシジョンテーブル作成

    #2007/03/12 コメントにあるとおり一部デシジョンテーブルに誤りがありますのであとで修正しますー。
    #2007/03/16 【改】原因結果グラフ デシジョンテーブル作成で再度チャレンジしてみました!

    ==

    さて、自分で問題を作ってデシジョンテーブルまで作成する、という勉強も架橋に。

    (1) 原因と結果の洗い出し
    (2) 原因結果グラフ作成
    (3) 原因結果グラフ修正

    今回はこのグラフからデシジョンテーブルを作成してみる。ただし、2点だけカンニングポイント。

  • テストケースは6個

  • 一部なぜそうなるのかをまだ解決できていない

  • では、まずは前回作成したグラフは以下のとおり。



    煩雑さをなくすために原因にあたる6つの条件を①~⑥とする。
    1つ目の結果「正常に受信される」について。


    Cegdt01


    これを成立させるためには、

     ①、かつ、not④、かつ、not⑤、かつ、not⑥

    となるので、ここの局所的なデシジョンテーブルは、


    Dt01_1


    という5つのテストケースになる。ただし、条件の割り付け方はこちらを参照させてもらいましたが、なぜそうなるのかはいまいち理解不足。もう少し勉強を進めないと。

    2つ目の結果は「メールが一時拒否される」について。


    Cegdt02


    これは単純である。


    Dt02


    3つ目の結果は「メールが拒否される」についてだが、これは中間ノードaがあるので、まずはそちらに注目する。


    Cegdt031


    ここでの局所的なデシジョンテーブルは

     ②、または、③、または、④、または、⑤

    という満足条件なので、


    Dt031_1


    となる。ここでいくつか考慮する点がある。まずは、制約Oが①と②と③の間に存在すること。②と③が確定しているのなら①も確定する。


    Dt032_2


    また、残り2つのテストケースについては制約上ありえないケース(禁則)になる。したがってデシジョンテーブルは前半3つだけが残る。


    Dt033_1


    では今度は、中間ノードaと⑥について考えてみる。


    Cegdt032


    ここでは、

     中間ノードa、かつ、not⑥

    なので局所的なデシジョンテーブルはこんな感じ。


    Dt034


    このテーブルに先の中間ノードを結果に持つデシジョンテーブルを埋め込むとこうなる。


    Dt041


    こうなると、あとは不要なテストケースを削除していけばいい。下記の灰色のテストケースが不要。


    Dt042


    すっきりさせれば出来上がり。


    Dt043

    ==

    僕はこれであってると思っているんだが。。。検算の仕方ってあるのかな。


    | | コメント (8) | トラックバック (0)

    原因結果グラフ グラフを修正

    Ceg03

    原因結果グラフ を勉強してみる原因結果グラフ グラフ化あってるかな?と順々にすすめています。少しグラフの手直しをして次はデシジョンテーブル化。デシジョンテーブルについては原因結果グラフよりもGoogle先生がいっぱい教えてくれそうだ。

    ==

    2007/03/11追記。

    デシジョンテーブルをまずはきちんと勉強しまーす。カルノー-ベイチ図とか単語がでてきたぞ。

    | | コメント (0) | トラックバック (0)

    原因結果グラフ グラフ化あってるかな?

    Ceg01

    前回の例をグラフにしてみるとこんな感じだろうか。

  • 「正常に受信される」という結果
  • 正常にメールサーバに受信されるためには、あて先が存在し差出人がブラックリストに含まれずメールボックス容量に余裕がありメールサーバが稼動しているとき。(AND条件


  • 「メールが一時拒否される」という結果
  • 想定した原因の中ではメールサーバが一時停止しているときのみ。


  • 「メールが拒否される」という結果
  • メールがメールサーバに拒否されるのは、user unknownなあて先の場合(退会メールアドレスあるいは存在しないメールアドレス)、差出人がブラックリストに含まれる場合、あるいは受信サイズがメールボックス容量を超えた場合、のうちのどれかを満たすとき。(OR条件

    点線とEは、それぞれのうち高々1つだけがtrueである、という記述。ニョロっとした記号が否定を表す。○で囲まれたアルファベットのノードは中間ノード。

    ==

    それにしても原因のところを「ブラックリストに含まれない」とか「サーバが一時停止していない(稼動している)」とかで表現するとグラフも変わってくるのだが、それとこれとは同値なのだろうか。

    | | コメント (4) | トラックバック (0)

    原因結果グラフ を勉強してみる

    1月末のJaSST'07でもパネルセッションテーマのひとつになっていた、原因結果グラフというツール。さてと勉強してみるか。

    ==

    名前は結構耳にするんだが、なかなかネットには詳しい情報がなかったりする。JaSST'07の資料のほかだと、具体例は

  • 原因結果グラフの例(PDFファイル)
  • CFD 技法の評価と事例に基づくガイドの作成(PDF)の後半
  • ざっとこんなところか。まずは自分で課題を決めて本を見ながら実際に作ってみることからはじめるぞ。

    メールサーバの配送システムを例にしてみる

    結果は?
    ・メールが受信される
    ・メールが一時エラー(soft fail)する
    ・メールが恒久エラー(hard fail)する

    原因は?
    ・あて先がwell-knownなメールアドレス
    ・あて先がunknownなメールアドレス
    ・あて先が退会したメールアドレス
    ・あて先が存在しないメールアドレス
    ・差出人がブラックリストに含まれるメールアドレス
    ・メールがメールボックス容量を超える
    ・メールサーバが停止している

    こんなもんだろう。さあ、ここからグラフを書いてみる。先は長いな。

    | | コメント (2) | トラックバック (0)

    [セミナー]第4回 「テスト環境」を見直す! 開発生産性・品質向上実践セミナー

    単体テストに焦点を当てたセミナー。また目黒雅叙園だわ。

    ==

    第4回 「テスト環境」を見直す! 開発生産性・品質向上実践セミナー

     ソフトウェア開発技術の目覚しい進歩により、構文エラーは事実上現存しなくなり、典型的なメモリーリークも減少、デバッガのおかげで隠れた問題も追跡が容易になりました。しかしながら、ソフトウェアが複雑さを増すにつれ、より多くのテストが必要になり、テスト開発にかかる時間と必要とされるリソースが増え、さらにテストを手作業で記述するプロセスには多くのリスクを伴うので作業効率が下がる恐れもあります。
      第4回の本セミナーは、単体テストの「必要性そしてビジネスにおけるインパクト」のご説明、単体テストを効率化するためのソリューションやサービスをご紹介致します。

    開催日 2007年3月15日(木)
    時間 13:30~  (受付開始13:00~ )
    会場 目黒雅叙園  オリオン
    定員 100名
    参加費 無料
    主催 サイオステクノロジー株式会社(旧 株式会社テンアートニ)
    協賛 アジターソフトウェアジャパン株式会社
    サン・マイクロシステムズ株式会社
    企画・運営 アイティメディア株式会社
    @IT 情報マネジメント編集部

    | | コメント (0) | トラックバック (0)

    QA、QCとテストエンジニアの違い

    日本語訳が正しいかどうかは不安だが。

    The difference between QA, QC, and Test Engineering by Google Testing Blog

    We use the QC process to verify a product does what we think it does, and we use the QA process to give us confidence that the product will meet the needs of customers. To that end the QA process can be considered a meta process that includes aspects of the QC process.


    我々は"QC"プロセスを「プロダクトが我々の想定した動作をするかどうかを検証する」こと、"QA"プロセスを「プロダクトが顧客の要求を満足できるかどうかの確証を得る」こと、というように使っている。その意味では"QA"プロセスは"QC"プロセスのメタプロセスと捉えることができる。

    僕の会社では「テストエンジニア」はもとより「QC」といった言葉もあまり耳にしない。品質保証部門があるので、実質的には「QA」という言葉は暗に存在するのだが、上記のような定義づけはされていないと思う。なので、それら全部を「テスト」という1つの言葉で済ませちゃってる。ちなみにこのブログでは「QC=Verification」「QA=Validation」と位置づけている。

    以前、品質の社内コンテストで受賞していたあるプロダクトがあった。品質保証部門のスコアは確かに高得点であったし、ドキュメントもきちんとされていたのだろう。でも、そのサービスはイマイチ使われていない。会社全体が「テスト」→「QA」+「QC」と認識できるようになると、いいなあ。

    | | コメント (0) | トラックバック (0)

    JSTQBシラバスが求めているテスト技術者(2)

    JSTQBテスト技術者の試験も無事終了。シャーペンとか消しゴムとか解答用紙見直しとか久しぶりな1日でした。

    ==

    試験前にまとめ記事は書いておきたかったが、続きを。

  • テストのマネジメント
  • テストを誰がやるか。実装をした開発担当者なのか、プロジェクト内のチームメンバーなのか、社内のテスト専門部隊なのか、社外の品質マネジメントを専門とする部隊なのか。基本的には後者に行くにしたがってプロジェクトとの関係が薄くなり、独立性が高くなる。開発担当者の思い込みやステークホルダーのプレッシャーなどの要因がなくなり、欠陥検出の観点でいえば精度があがるといわれる。ただし、独立性が高くなるほど当のメンバーの品質意識が薄れてしまい、欠陥作りこみの観点でいえば品質が低下する可能性も秘めている。誰がやるか、という問いであれば「テストツール」という選択肢もあり、その場合も同じようなことが言えそうだ。思い込みは全くないが、テストツールに依存しすぎると逆に品質低下の坂を転げ落ちる可能性もある。

    プロジェクトに影響するリスク(=プロジェクトリスト)と、プロダクトに影響するリスク(=プロダクトリスト)という区分をした場合、前者はテストというプロセス自体に影響がでる。後者はテストというプロセスが影響を及ぼす。すなわち、テストというプロセスがプロダクトリスクの対策になりうる。

    それにしても終了基準ってけっこうあいまいなところが多そうだな。

  • テスト支援ツール
  • 最後の章はテストを支援するツール。静的解析ツールやキャプチャリプレイツール、不可試験ツールが有名。テスト実行ツールあたりは、ここらへんは日立)加藤さんの講演とかをきくとまとまっていて理解しやすいと思う。テストマネジメントの支援ツールなどは比較的どのプロジェクトでも効果が出そうな気がする。私見では。


    ==

    テスト工程ってけっこう感覚的に行っているケースが多いが、体系的なテストプロセスを学習してみると、まさにプロジェクトの中のサブプロジェクトだね。僕らが期待するような解の公式はない。複数の視点・観点で分析しないとなかなかひとつ高いステージの品質にはあがらない。仕様ベースと構造ベース。「バグを作らない」と「バグを見つける」。個人単位の品質意識の向上と個人の能力に左右されないプロセス。

    (続く)

    | | コメント (0) | トラックバック (0)

    JSTQBシラバスが求めているテスト技術者(1)

    テストオラクルという切り口で今は勉強中。エイゴニガテ。

    ==

    明日3/2にJSTQBテスト技術者資格認定の試験があります。僕も問題集や教科書やこことかで勉強してみました。


    一通りこなしてみて、復習・おさらい・新たな気づきのために自分なりにまとめてみようかと。

  • テストの基礎
  • テストがなぜ必要・重要なのか。上手なテストはどういうリスクを回避するのか。静的テストというテスト。テストプロセスってどんな風に行うの?

    実はシステム開発の半分以上のコストがテスト工程に費やされている、というデータもあるとおり、コスト面で効率化が必要。また昨今のシステムトラブルなどをみても品質面でも効果性を求められる。じゃあ、そのテストについてもっと研究してみようよ、という章かな。

    テスト=バグ(欠陥)を見つけること、という視点、レビューなどの静的テストという視点、システム開発のサブプロジェクトとしてテストを考える、心理的な観点からだれがテスト(設計)すべきかな、どなど。


  • ソフトウェアライフサイクルを通じてのテスト
  • システム開発の手法によってテストの関わり方がかわってくる。ウォーターフォール型開発の中のテスト、反復型・アジャイル型開発の中のテスト。それ以外にも、構成単位の粒の大きさでテストをカテゴライズすることもある。コンポーネントテスト(あるいは、ユニットテスト、単体テストとも)、統合テスト(あるいは、結合テストとも)、システムテスト、受け入れテスト。テスト工程といったらこの呼び名が一番馴染み深いかも。これはテストのレベルというカテゴライズで、V字開発モデルではそれぞれが詳細設計、システム設計、要件定義などと対として扱われる。

    その他にもテストのタイプというカテゴライズもある。これは機能テスト、非機能テスト、構造テスト、確認テスト、保守テストといった種類(タイプ)がある。それぞれにテスト評価基準があり、要件のカバレッジであったり、条件のカバレッジであったり。非機能テストにおいては品質特性(JIS X0129)と呼ばれるカテゴリを参考にする方法もある。システム開発をはじめたころは機能テストばっかりをやっていた気がするなあ。

    こういった複数の視点でテストを分析していくことでより多くのバグを検出できるテスト設計が可能になる。仕様書ベースだけでテストケースを作成していても、見つからないバグもある。ステートメントカバレッジに注目しているだけでは見つからないバグもある。とか。


  • 静的技法
  • ソースレビューとかテスト設計レビューとかペアプロとか。プロジェクトの早い段階でバグを作りこまない対策として最も一般的に知られているが、人によってはまちまちなのも事実か。開発担当者自身に気づかせるためのウォークスルー、技術的な指摘をメインにしたテクニカルレビュー、静的解析ツールを利用することで品質を均一にしするという試みもある。ここでの取り組みがあとあとの手戻りコストを小さくしてくれる。ただし、一長一短である。実際に動かしてみないとわからないバグも必ずある。


  • テスト設計技法
  • 静的テストは「バグを作りこまない」「バグの件数を小さくする」という視点。テスト設計をするときは「より多くのバグを見つける」「より少ない手数でバグを見つける」という視点。前者は手戻りコストを抑え、後者はテスト実行のコストを下げる。

    仕様ベースとかブラックボックスと呼ばれる技法は、入力(事前条件)と出力(期待される結果)に注目してテストケースを設計する技法。期待される結果を比較(テストオラクル)。要件・機能カバレッジをチェックすることが一般的。

    構造ベースとかホワイトボックスと呼ばれる技法は、経路に注目するテスト技法。ステートメントカバレッジ・ブランチカバレッジ・コンディションカバレッジをチェックする。

    どちらも長所短所をもっていて、例えばコンポーネントテストでは構造ベースが、より上位の結合テストでは仕様ベースで設計することがよさそう。ただし、設計においても複数視点での設計が必要になる場合が多く、システムテスト以降であれば仕様・構造両方で分析・設計するのが望ましいだろうな。


    (続く)

    | | コメント (0) | トラックバック (0)

    « 2007年2月 | トップページ | 2007年4月 »