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

GUIテストツールとサビタイジング

JaSST'07終了。第2日目も午後から参加。午前中のミニパネルも聴きたかったなあ。

==

第1日目のセッションでJameleonについての発表があった。その中でJameleonのデメリットとして「判定ポイント見極めが難しい」というのがあった。これはけっこう落とし穴であって、発表者である加藤さんも注意を促していた。(他の発表の場でもよく指摘してたな)

GUIテストツールを使わずに手動&目視で確認するときの人間の視覚認識はけっこうすごい。サビタイジングと呼ばれる能力らしく、見た瞬間に状態を把握することができるらしい。例えばお札を数える場合、素人でも一度に2枚あるいは3枚を束にして数えられるし、プロであれば5枚を束にして数えられる。これは一種のサビタイジングに似た能力なのかな、と個人的に思ってます。(間違ってたらご指摘ください)

おそらく、手動&目視でGUIテストを実施した場合も同じで、画面全体の印象などと一緒に瞬時にテスト実施結果の検証が行われるのだと思います。見逃しや勘違いなどヒューマンエラーについては決してツールにはかなわないけど、そういった包括的な判断はツールでは難しい。そのため、Jameleonなどのツールを利用する場合は複数の判定条件を指定することが重要となってくる。

加藤さんも指摘されていたが、例えば「表示メッセージの大きさ/色/場所」「本来あるべきでないもの」なんかをきちんとツールの判定条件に含めるのだ。

ちなみに、これはGUIテストツールだけじゃなくて僕は単体テストの判定条件にも活用している。関数/メソッドの復帰値だけじゃなく、それ以外の判定条件をなるべく記述する、といった具合に。

# テストツールのセッションを聴いていて、思い出したので記事にしてみました。

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

[JaSST '07]第1日目 大盛況な賑わい

午前中は会社で作業をしていたので、午前中の基調講演(Ed Yourdon氏)は聴けませんでした。

==

今年は去年以上ににぎわっていた気がします。回を重ねるごとに名前も知られるようになったこと、近年になってソフトウェアテストの重要性が認められたこと、JSTQBテスト技術者資格の第2回試験があること、ヨードン氏の講演があること、東証システムトラブル、etc。いろいろなファクターが考えられそうですね。

僕が参加したのは3つのセッションでした。


  • テストツールはじめの一歩

  • C2-1Apache JMeterで負荷試験をしよう!

    オープンソースであるJMeterでの負荷試験のノウハウ、陥りやすい落とし穴、手順などが紹介されてました。自分の会社でも負荷試験製品を導入しているが、なかなか負荷によるトラブルはあとを絶たない。今回紹介されたJMeterを、担当レベルで安直に導入するのもいいが、負荷試験の手法・評価なんかをもう少し勉強したほうがいいと思った。自分を含めて。


    Jameleonによる機能テスト/回帰テストの自動化について

    これもオープンソースであるJameleonを使ったキャプチャリプレイテストのデモ。前半部分はテストの自動化に関する見解・エンジニアは何を困っていて、自動化は何を実現してくれるのか、といった内容。発表者は日立の加藤氏。最近はテストツール・自動化についてでよくお見かけします。

    Jameleonは最近になってアップデートが活発で、Seleniumのプラグインもベータ版で実装中とのこと。現在のところJameleonにはテスト実施記録機能がないため、作業コストがやや大きいが、今後に期待大か。

  • テクノロジーセッション - 富士通 -

  • 単体テスト 作業プロセスの改善

    ウォーターフローなシステム開発プロセスの改善を最終目標とし、まずは単体テストに焦点をあてた富士通の取り組みについて。パイロットプロジェクトに単体テストのフレームワークを導入したということでした。テストケース仕様書の形式見直し、eclipseによるテスト実施の自動化、行カバレッジ(命令カバレッジ)によるテスト結果の評価、の3つのポイントがあった。どこの会社も単体テストは属人的なのがわかったかも^^;今回のフレームワークはjava環境であったが、C言語であれば以前紹介したgcov/lcov/genhtmlあたりのツールで似たようなフレームワークができると思ってます。課題としては、その取り組みを誰がやるか、かも。

  • テスト設計ぶらり旅

  • ソフトウェア国際化テスト技法−擬似翻訳手法の改良−

    「国際化テスト」という耳慣れないワードがでてきたが、マルチ言語対応のテストのことを指すらしい。へぇ〜。「表」「竹」という2バイト文字が表示系のテスト文字として使っているというのが面白かった。テストとしてはなじみがないが、視点を変えたらもっと一般的なテストにも応用できる考え方がありそう、という印象。

    複数言語でのシステム開発におけるソース解析の効用

    ちゃんと聴いてなかった。メトリクスについての言及が多かった気がする。NCSSって実ははじめてきいたかも。。。

    パソコンによる直交表の自動構成とソフトウェアテストへの応用

    いろいろな意味で勉強にはなった。「奥野の線点図」って知らなかった。有限体、既約多項式、ベクトル空間など大学の数学の授業にでてきそうなワードがもりだくさん。どちらかというと最小な直交表を生成するアルゴリズム(極大な因子-水準を扱える直交表生成のアルゴリズムと言い換えられるか)についての深い考察だったな。

    個人的にはJaSSTのセッションでは理解するには難易度が高かった気もするけど、2水準系ではない切り口からの直交表というのは興味深かった。

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

    FTFI -どうして2因子間網羅なのか-

    しつこいようだが、ソフトウェアテストは、いかにして少ない手数で多くの欠陥を見つけるか、がキーである。

    どこに欠陥が入り込みやすいか、という問いにはいくつかの解答があるだろうが、直交表・HAYST法・All-pair法などを勉強する場合、勘所は組み合わされる条件の個数になることが一般的。なぜか。

    ソフトウェア・テストPRESSでもネットにも資料があるのだが、欠陥の多くは単因子の場合と2つの因子による場合とでほとんどが構成される。

    Ftfi

    (引用元: http://www.jasst.jp/jasst05w/pdf/S4-3.pdf)

    ちなみに、NetscapeやApacheなどは2因子まででは欠陥混在数が収束せず、3因子の関係も考慮する必要があるプロダクトといえる。これはプロジェクトが大規模でメンバーが数多い場合には、多数因子の組み合わせでも欠陥が少なくない、との見方がされる。

    2因子あるいは3因子までの組み合わせを考慮すれば、ほとんどの欠陥は検出できる、というのはこの経験則によるところが大きいと思われる。(田口博士による、バグの数は因子数で指数的に小さくなるという理論もあるかな)

    ==

    ここからは私見。

    All-pair法は2因子間網羅を特に意識しているが、テスト実施者=開発担当者であれば、2因子間網羅すら間引いてもいいんじゃないかって思う。抽象化・グルーピングによって2因子間網羅率は低下するだろうが、先の条件下であれば極端な品質低下にはつながらないし、効率もいいのかな、と。ホワイトボックス的なアプローチができるはずなので。


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

    [セミナー]ソフトウェア品質向上セミナー2007

    日経SYSTEMS他の主催によるセミナーがあります。

    講演内容には、「属人化の問題」「負荷テストの手法」「JUnitの新アプローチ」というテーマが並んでいます。属人的な業務なんてうちの会社には山ほどありそうだ。。。

    ==

    ソフトウェア品質向上セミナー2007

    日 時 2007年2月20日(火) 11:00〜17:40(予定) 開場10:30
    会 場 日経ホール (東京都千代田区大手町1-9-5 日本経済新聞社8F)
    主 催 日経ソフトウエア,日経SYSTEMS
    協 賛 アジター ソフトウェア ジャパン,エンピレックス 他
    定員 200名
    受講料 無料・事前登録制(先着順)

    セミナーお申し込み

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

    テストツールとテスト設計意識

    いまいち、All-pair法のメリットが自分の頭に入ってこない。ナゼダロウ

    ==

    テストを自動化、効率化するためのテストツールは、当然テストを実施するコストを軽減してくれる。でも、それは単なる作業の効率化であって、品質向上にはさほど影響しない場合がある。(もちろん、浮いた時間で重要箇所のテストを厚くするなどやり方はあるが)

    自分がソフトウェアテストに興味を持つきっかけになったのは、まさに「自動化」という手段を求めたことである。当然、手動でテストを実施する時間を短縮することができたが、目に見える品質向上というのはなかなか出てこなかった。なぜ?なぜ?と考えて、僕は「テスト設計」が重要じゃないか、というふうに考えた。どんなにいいツールを持っていても、使い方によっては宝の持ち腐れになる。テストケースに漏れがあれば、そのテストをどんなに厚く行ったって、欠陥は見つからないのだ。

    テスト設計が重要なことは、いろんな本に載っているし、誰に聞いたって、そのとおり、自明なこと。だけど、テストツールという手段をまず求めたことで、そういう大事なところに気づけた、ということもいえるのではないだろうか。

    教えられることよりも、自分で答えにたどり着くことのほうが、ずっとありがたみがわかる。と思います。

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

    [試験]JSTQBテスト技術者資格認定

    第2回JSTQB技術者認定の試験があって、その受付が始まりました。

    JSTQBテスト技術者認定
    受験受付について

    資格というよりもスコアといった意味合いが強いかと思いますが、テストという観点で、業界底上げするにはこの技術者認定試験がもっと有名になるといいな、と。

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

    [本]ソフトウェア・テスト PRESS Vol.4

    書籍の紹介だけじゃなく、勉強の成果も出さなくちゃ勉強室の名折れだ・・・

    ==

    ソフトウェアテストPRESSの最新号が出るようです。1/30発売。この雑誌はだいたい半年に1回の割合で出版され、今までには単体テスト直交表テスト管理ツール自動テストツールなどがテーマでした。また、年明けに出版される号はJaSSTとリンクしてることが多いみたい。

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

    [本]JSTQB教科書 JSTQB認定テスト技術者 Foundation Level試験

    3月に第2回JSTQBの試験がありますね。それにあわせてか、教科書が出るようです。

    発売日は2/8なのでもう少し先。試験を受けようと思う方には強い味方になるかも。僕も3月受験予定なので買ってみるかな。

    ==

    演習問題であればこちらもコンパクトかつお手ごろ。実践的ではないけれど、これだけでも勉強になるね。

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

    テストケース組み合わせの手法を勉強する - All-pair法 -

    ココログはメンテ中。ココログフリーなのでうちは大丈夫。

    ==

    参加しているメーリングリストでpairwiseについての話題が出ていた。直交表やHAYST法のように条件の組み合せを効率的に網羅するテスト技法のひとつで、特徴は「2因子組み合せでほとんどの欠陥を見つけ出せるという経験から、2因子間網羅率を100%にする」という特徴を持っている。ちなみに、直交表やHAYST法でも2因子間網羅率を品質の指標にはしているが、3因子、4因子以上についても網羅したい、という思いが強い。かな。

    Pairwise Testing


    Pairwise (a.k.a. all-pairs) testing is an effective test case generation technique that is based on the observation that most faults are caused by interactions of at most two factors. Pairwise-generated test suites cover all combinations of two therefore are much smaller than exhaustive ones yet still very effective in finding defects.

    Pairwise(別名all-pairs)テストとは、多くの欠陥(不具合)が高々2つの因子の作用によって発生しているという経験に基づいた、効果的なテストケース作成技法です。Pairwaseテストスイートは全ての2因子間組み合わせを網羅しており、徹底的な手法よりもより少ない労力での検知が可能な、とても効果的な手法です。

    参考資料。
    直交表 VS All-pair法(PDF)

    直交表・HAYST法を使うべきか、All-pair法を使うべきか、そういった見極めはどうしたらいいのかを、もう少し調べてみようっと。


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

    覚えた知識は、真似て、そして味付ける

    目がショボショボする。年末年始で落ち込んだモチベーションはやや回復の方向で。気分転換に記事書こうっと。

    ==

    僕は入社以来ずぅ〜っとシステムを作る側であったが、品質向上という目標をもつというきっかけによって、ソフトウェアテストについて勉強をしている。勉強期間もたかだか1年とか2年。もう少し年数を経験した方のブログはすごく興味を持ってみてますー。

    ソフトウェアテスト(1) by 品質って何だろう?

    私は、これらは、ソフトウェアの品質保証に限った話ではないと思っており、人に会うたびに、この方法を薦めています。もちろん、自分の部下たちにもです。

    1.まずは知識を得よ
     感覚的に優れた人はいます。よって、テストを行うにはこうした方が良いと言える人たちもいます。
     しかし、自分自身が持っている知識はちっぽけなものであり、まだまだ他にもあります。知識を増やすことで
     引き出しの数を増やすことは可能です。まずは、知識を得て、頭でっかちになる方が良いと考えています。
     ただ、ここだけで終わっては意味がありません。

    知識だけを追い求めることが正しいことではないが、知識を持っていないとそれだけ守備範囲が狭くなる。例えば「デシジョンテーブル」とか「設計カバレッジ」とか、単語を取ってみても知らないと議論に参加できない場合がある。(議論というのは、このプロジェクトにとってその手法が有効なのか、有効でないのか、といった議論です)さらには、引き出しを増やすことは長期的に見れば、情報も自分の元に集まってくる可能性も高くなるだろうし。あなたのその知識の助けを借りる、相談しに来る、そういったことも(苦労もするけど)メリットになる。



    2.実践せよ
     知識を得て、その知識だけをひけらかすのは人からの賛同は得にくいものです。実践し、その経験を
     元に、自分の知識の幅を広げて下さい。その中から本当に良いものだけを出すようにしていけば良い
     のです。自分に経験がなければ、本の内容をそのまま真似て下さい。私自身、真似ることは、とても
     大事なものだと思っています。ただ、実務上で実践出来るかどうかは、上司の質に関わってくる可能
     性があります。もしかすると、コストがかかるので、実践させてくれないかもしれない。そんなとき
     は、1.で得た知識の出番です。この本に、こんなことが書かれているし、自分自身も有効だと思って
     いるなど、説得させることが最も大きな難関かも知れません。

    引用したブログにも書いてありますが、「学ぶ」は「真似る」から由来したといわれています。真似ることがすなわち学ぶことに通じます。まずはやってみて、それから良し悪しを判断するほうが、より説得力もあり、納得性の高い知識となると思います。会社にも寄るかと思いますが、うちの会社ではこういった自己研鑽や
    長期的な人財育成は認めてくれるので、助かってますね。逆にそこには自らコミットメントを持っていないといけませんが。



    3.そしてアレンジせよ
     実践し、得た経験を元にアレンジしてください。有効なもの、有効ではないものは必ずあります。
     それは、本の上だけで語られているものではなく、実践した経験を元に感じ取る必要があります。
     そして、それらの情報は、必ず書き残しておいて下さい。それが、財産のひとつになります。

    アレンジ・改良はすごく重要だし、エキサイティング。もちろん、ごく一般的なシステムに関するテストは書籍にゆるぎない回答が載っているかもしれない。が、自分の扱っているプロジェクトやプロセスはどこか特徴があるはず。そこは試行錯誤をしてアレンジしなくっちゃ。

    もしかしたら、あなたがアレンジしたものが他のどこかにいるかもしれない誰かの琴線に触れるかもしれない。

    そう思うとほんとエキサイティング。

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

    単体テストの効用

    年末年始の休み中に読み返そうと思って、ボーリス バイザーの本体系的ソフトウェアテスト入門を家に持って帰ったが、読まずじまい。。。

    ==

    「テスト環境」を見直し、開発生産性・品質向上を実現!【第1回】 by TechTargetジャパン

    単体テストには大きい利点があるにも関わらず、開発チームが首尾よく単体テストを実行していくためには多くの努力と挑戦が必要となる。最も大きい挑戦の一つは、実質的にすべての開発グループに存在するスケジュールに対するプレッシャーである。開発者が一つのプログラムを書いた後で、開発者には選択肢がある。それは、テストコードを書くべきか。それとも、次の機能のプログラムを作成すべきか。

    ほとんどの開発者が、スケジュールに対するプレッシャーを感じ、テストコードを書かないことを選択し、それを正当化するのは簡単である。しかも、単体テストに最適なプログラムコードを書くことは単体テストよりも多くの時間が必要となり、プレッシャーのかかった開発者にとっては「テストのため」のプログラミング手法へと変更することは間違っていると感じてしまうのは最も現実的な話なのである。

    単体テストがプログラムを開発することと異なる作業と感じている限り、この抵抗感は存在してしまう。それではどうすればよいのだろうか。

    スケジュールに対するプレッシャーも、単体テスト実施の抵抗のひとつだが、もっと大きい壁が存在する場合があると思う。単純にいえば「単体テストの軽視」。もちろん、ある程度の教育を受けたエンジニアであれば、「工程が進むにつれてバグ修正コストが大きくなる」ということは知っている。でも知っているだけで、それを回避するところまでたどり着いていないエンジニアやチームも多いんじゃないかと思う。

    テスト駆動開発を含めて、単体テストに注目した開発をすることで、品質の高い設計・品質の高いモジュール・品質の高い開発手法を手に入れられる。チームメンバーに単体テストのエクササイズをさせて、単体テストの効果を実感させ、単体テスト重視の第一歩を踏み出させるのもテストマネージャーの仕事かな、と思います。

    あとは、各テスト工程で重複したテストをすることによるムダを嫌う、というのもあるか。

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

    仕事始め - テストツールのチューニング -

    明けましておめでとうございます。扁桃炎も治ってきて、モチベーションもアゲていこう。新年早々、まとまりのない文章をつらつらと。

    ==

    テストとは品質向上を主目的としたライフサイクルプロセス。なので、回帰テストケースやテストツールは適宜その有効性をメンテナンスしなくてはならない。でなければ、人は一度構築されたテストケースやテストツールを信頼しきってしまい、細かな修正の積み重ねや見落とし、油断などによってバグを検出できなくなる。それもいたって初歩的・単純なものだったりもする。

    そこで、どうやってそういった問題を回避していけばいいんだろう。


  • 更新するという癖をつける
  • 当然&基本的なことだけれども、なかなか癖がつかない。これが成功するかどうかは、会社の文化・チームの文化にも影響される。仕様書やヘルプがそのまま放置されがちな組織ではまずここから。


  • 複数のチェック体制をとる
  • 一人が油断しても他の人が見逃さない、の手法。でも、誰かが承認したんだから承認していいだろう、といった同調・迎合の空気に飲み込まれる可能性が高いか。


  • 定期的に気分を変える
  • 今まで電子データでのやりとりだったものを、紙ベースに変えたり。レビューの場所を変えたり。時間帯を変えてみたり。チェックシートを無駄に作り変えてみたり。効果あるかな。。。


  • 手順の中に手順の見直し作業を入れておく
  • テストケース中に「このテストケースだけで十分か?」といった自問を入れる。うまくいきそうだけれども、どうやって十分かどうかをテストするのか、が難しい。

    他にどんな手法があるだろうか。

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

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