機能テストの自動化と記録

最初の目的はテストケース作成ツールを作ることだったが、不具合管理機能もつけようっと。

予想結果

不具合の原因

対処

OK/NG/対象外

テスト消化状況

あたりの管理機能を実装だ。他にもまだあるかも。

==

機能テストを自動化ツールでチェックすると、テストを実施するコストは大幅に小さくなる。でも、不具合管理はコツコツとやらないといけないな。テスト結果のコンソールとエクセルシートのにらめっこ。社内で導入された影舞はみんな使ってるのかな。

見やすいテストケース表とは？

テストケース作成ツールを作るために、JavaScriptとスタイルシートの知識も増えていく。

==

今僕の扱っているサービスでは頻繁にフルデグレードテスト・回帰テストが必要なため、自動化ツールを使っている。実際のテストケース表は社内Webサーバで見られるようにXML形式で作ったのだが、これがどうにも見にくい。縦に並べると考慮漏れがあるかが一目ではわからないんだよな。普通にエクセルで作ったほうがレビューにはあってるんだが。

「縦型」のいいところはテスト内容・予想結果・実施日・実施者・OS/ブラウザなどが1行で表示できるところか。ただ、視覚的にテストケース漏れを発見しにくい。「マトリクス型」はその点行と列で条件を見れたりするので漏れがないことを認識しやすい。逆にテストケースが1セルになってしまうので、補足情報が表記しにくい。2次元表現ってのも限界があるなあ、シートの串刺しで3次元までは可能だけど、視覚効果は薄れる。

「縦型」と、「マトリクス型」以外で何かビジュアル的に見やすい書き方ってないかな。

テストケース作成ツールを作ろう

天気予報では午後から晴れるっていってたから、今日は傘なし。やっと晴れてきた〜。

==

直交表の性質も少しずつ理解が深まってきた。ふと、ツールを使って簡単にテストケースって作れないかと思い、昨日からいろいろ勉強中。といって、JavaScriptとスタイルシートですが。力技で作ってしまえ的な勢いです。機能的にはこんな感じのツールをイメージ。

因子と水準を入力して、テストケースマトリックスを表示

せっかくなので、水準値はサジェスト機能付き(境界値分析とかエラー推測)

グルーピングや多水準化も当然やる

n因子間網羅率の計算もしたい

仕事の合間にコツコツと。

現実的なサイズは L32 か

最近ネタが直交表ばかりです。僕が今週はちょうどシステムテスト週間だからちょうどいいか。。。

==

先日紹介したよくわかる実験計画法を元に2水準系の直交表をエクセルで作成してみた。L32の直交表に対応する交互作用の一覧表までは作って、あとはL64のサイズだけ〜・・・と思った。が、よく考えてみると今までソフトウェアテストとしては直交表ってL32までしか使ってないな。冷静になってみれば因子数が64ってありえないし、多水準化したとしてもL32であれば十分な因子数が確保できる。ググってみても64なんてサイズはあんまり見ないしな。

懸念としては、交互作用が発生しないように列を選択して3因子間網羅率をあげる工夫をすると、サイズが足りなくなるのかもしれない。

次のプロジェクトで試してみるか。

水準数が2の場合の3因子間網羅率

直交表を使うことで2因子間の網羅率を100%にすることができる。それは直交という性質の効果でもある。それでは3因子間網羅率はどうだろうか。これについては交互作用の現れる列を選択しないように上手に組み合わせを行うことで網羅率をアップさせることができる。各列に対する交互作用の現れる列を指し示した図は交互作用一覧表と呼ばれており、少し手間がかかるが直交表と同様に作成することができる。

左図は、L8直交表と交互作用一覧表の一例である。一例と但し書きしたのは、基底（図のa、b、cのこと）の取り方によって、あるいは合成列の順番によって交互作用一覧表の値も変わるからである。

列1(a)と列5(b+c)と列7(a+b+c)が交互作用の関係になるのは、列7が列1と列5の和で表されるためである。すなわち、直交という性質が崩れてしまうのである。

ただし、この手法は水準数が2の場合の話。多水準化した場合はどうしたらいいだろうか。それについてはまた
別の機会に書こうと思う。

[本]ソフトウェアテスト技法―自動化、品質保証、そしてバグの未然防止のために

会社で席替えがあったので、今日から新しい席。デスクの上の本棚を処分したので目の前すっきり〜。

==

「ソフトウェア・テストの技法」と名前が似ているがこちらはホワイトボックステストの解説がメイン。実はまだ読み終わってないです。。。グラフ理論をもう少しちゃんと勉強してみようかと思いました。

[本]よくわかる 実験計画法

直交表についてもう少し深い理解をしようと思って、購入。お値段も手軽でグッドです。ソフトウェア・テストPRESSでも直交表・ダミー水準・多水準化といった手法を載せてたけど、こちらはもう少し理論の裏づけを交えながらの解説でした。ベクトルを持ち出すことで直交という概念がより数学的になっている気がします。ちなみに、タイトルからわかるようにメインとなるのは「実験計画」の手法なので、ソフトウェアテストのテストケース作成には必要ない情報も含まれます。

直交表（L8～L64まで）

L8直交表＋交互作用一覧表

L16直交表＋交互作用一覧表

L32直交表＋交互作用一覧表

キーワード：実験計画法, ラテン方格, グレコ・ラテン方格, 超グレコ・ラテン方格, 直交表, 主効果, 交互作用,
　　　　　　線点図, 擬水準, 2乗化

[本]ソフトウェア・テストの技法

世に出回ってからけっこう年月がたったにもかかわらずベストセラーのひとつ。具体例などは時代を感じさせるものが多いが、考え方やアプローチ方法については、なるほどな、と思うことが多いです。この本を読む前は、機能テストとシステムテストの違いがイマイチ掴めてなかった気がします。全部読む必要はないけど、ゼッタイ読みたい参考書のひとつ。

ソフトウェア品質向上のための考察 -テストとレビューとインスペクション(1)-

今までこのブログで雑記程度にソフトウェアテストについて書いてきましたが、ひとつきちんとした読み物としてまとめてみようと思います。いろいろなセミナー・雑誌・書籍・ウェブサイト・ブログなどを元に学んだこと・発見したことなどを、自身の考察を交えてまとめていけたら、と考えてます。

==

ソフトウェア開発の中でレビュー・インスペクション・テストというプロセスがあります。３つとも目的は一緒で「ソフトウェアの品質を向上させる」のが大前提です。それでは何が違うかというと、それぞれアプローチの仕方が違ってきます。

レビュー・インスペクション - 未然の「欠陥防止」

---

一般的にレビューやインスペクションは直接成果物に触れてバグを取り除くのではなく、成果物に作り込こまれてしまうバグをより少なくするためのプロセスです。人は知らないうちにバグを作り込んでしまいます。それは、単なるヒューマンエラーであったり、仕様の勘違いであったり、仕様漏れや考慮漏れであったり、原因は無数にあります。僕はレビューやインスペクションというのは、作り込まれてしまったバグに「気づき」を与える、あるいは今後は作り込ませないための「気づき」を与えるアプローチだと考えています。多くのレビューやインスペクションは上流工程で行われるのは、そういった「気づき」を早いうちから出しておき、成果物に含まれるバグ数を小さくする効果を期待しているからです。学生のころの定期テストで解答用紙を最後に見直すというのもレビューのひとつです。作家の書いた原稿を編集者が推敲するのもレビューといえるでしょう。

では、インスペクションとはどういったプロセスでしょうか。

[ITプロフェッショナルのスキル] ソフトウェアプロセス用語集 -インスペクション-

インスペクションの訓練を受けた専門家が、数名の関係者を招集して行うレビュー。参加者には事前に資料を配布しておき、各参加者がレビュー前に問題点を把握しておき、レビュー実施時に指摘するという方法をとることが多い。開発会議より、客観性が高い。

主な手法として2点紹介します。(ソフトウェア・テストPRESS Vol.2 からの引用)

パースペクティブ・ベース・インスペクション

パスアラウンド法

パースペクティブ・ベース・インスペクションは、参加者が各人違う観点を意識しながら対象物を検査する手法です。観点は例えば、エンドユーザー観点・データーベース担当者観点・テスト担当者観点・運用担当者観点など、プロジェクトによって様々な観点があります。多様な切り口からの「気づき」が得られるといった効果があります。

パスアラウンド法は、検査対象物を事前に提出しておき、検査担当者での回覧ベースでバグを指摘してもらうという手法です。検査担当者および関係者を参集する必要がなく、効率的に「気づき」を得られます。しかし、指摘が重複したり、検査担当者によっては回答が遅れたりするなどの問題も認識しておく必要があります。

(続く)

オープンソーステクノロジー勉強会 -Webアプリケーションのテストをもっと深く考えてみよう-

第7回 オープンソーステクノロジー勉強会

QA全般について(QAエンジニアとプログラマとの違い、テストの範囲、自動化の手法)、オープンソースのテスト自動化ツールJameleonについてご紹介します。

GREE Labsなどが主催しているオープンソーステクノロジー勉強会というものがあって、Webアプリケーションのテストについてのセッションがあったとのこと。プレゼンターがテストウェアシンポジウム実行委員の加藤氏だそうで。内容は後で資料がアップされるようなのでチェックしてみようと思います。

単体テストのコツ

最近枝豆をよく食べる。夜はごはんを食べずに枝豆とおかず1品。現在、長期的なダイエットを実施中です。

==

意外にノウハウが集まりにくいのが単体テストかなと思ってて、自分で実装したプログラムも、外部委託で実装してもらうプログラムも、各人の感覚・勘あたりに頼った単体テストが周りでは多いのかも。

今僕の所属している開発チームでは、コードレビューに着目していろいろとアイデアを試してる感じで、レビューポイントをシートにまとめておいてレビュー時の確認項目として使ってる。これは一般的には　Checklist-Based Reading(CBR)　というらしい。これをある程度実践してみて感じたことは以下のようなこと。

1モジュール/関数ごとにチェックシートと照らし合わせるのはめんどくさい

コードレビューの達成目標(バグ検出なのか、コードの効率化/関数化なのか)によってチェックシートの扱いが変わる

だんだん慣れてくると、チェックシートの内容を覚えてしまうので、レビュー効率が上がる

3番目については、コードレビューの実施の副産物として今後の実装に役に立つかな、とも思った。

テスト設計レビューによる掘り起こし

プロジェクトが発足するときに、「とりあえずざっくりと外部仕様まとめて」という感じでドキュメント初版を作成し、その後まともな改訂が行われない場合が、僕を含めて周りでは少なくない。当然、仕様はプロジェクトが進むにつれてブレたり、変更したり、追加されるのが常。そうなると、仕様書に載っていることをベースにテスト設計を行う間にどんどん網羅率が下がっていく。しかも、当人が認識できないことも多い。

これを踏まえて、テスト設計レビューというプロセスは、テスト分析-テスト設計の妥当性をチェックすると同時に、そういった埋もれている仕様やポイントを掘り起こして、設計担当者当人に隠れたリスクを認識させる大きな意義があると僕は思う。テスト手法でよく知られている同値分割・境界値分析・エラー推測も、この場面では掘り起こしの手法に姿を変える気がする。

ここらへんはあとでまとめてみて、勉強会のネタにしよっと。

直交表を利用したソフトウェアテスト→HAYST法とか

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法入門」が出版されました。

僕も購入して読んでみましたので、こちらをご参考にしてもらって興味があれば、さあ入手だ！

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

ハワイのチョコをもらったと思ったら、今度は中国・西安のお土産。

==

株式会社テンアトーニ主催のテスト工程を主としたセミナー。場所は前に JaSST を開催したところみたいだ。単体テストに関するセミナーのようです。基調講演は興味ひかれる。

==

「テスト環境」を見直す！開発生産性・品質向上実践セミナー
〜その秘策は、単体テストの自動化にあり〜

　　ソフトウェア開発技術は目覚しい進歩を遂げてきました。IDEの登場に伴って
　構文エラーは事実上現存しなくなり、ガーベージコレクションを備えたJava
　などのプログラミング言語の登場によって、典型的なメモリーリークも減少、
　デバッカのおかげで隠れた問題も追跡が容易になりました。しかしながら、
　大量のコードを生成する機能は大幅に向上したものの、生成されたコードに
　欠陥が多い点はいまだ改善されていません。ソフトウェアが複雑さを増すに
　つれ、より多くのテストが必要になり、テスト開発にかかる時間と必要とされる
　リソースが増え、さらにテストを手作業で記述するプロセスには多くのリスクを
　伴うので作業効率が下がる恐れもあります。
　　第３回の本セミナーは、要求開発におけるテストの捉え方、単体テストソリュ
　ーションのご紹介、そして事例を交え、開発生産性・品質向上の実践方法をご紹
　介致します。開催概要

　■日時 2006年10月18日(水) 13：40〜（受付開始13：10〜 ）
　■会場 コンファレンススクエア　エムプラス　グランド　>>地図
　■定員 100名
　■参加費 無料
　■主催 株式会社テンアートニ
　■協賛 アジターソフトウエアジャパン株式会社、サン・マイクロシステムズ株式会社
　■企画・運営 アイティメディア株式会社

　イベントの詳細・申込みは
　https://www.atmarkit.co.jp/club/gforms/sem061018/form061018.html

漢字の練習とテスティング

会社の同僚がハワイのバカンスを終えて帰ってきた。お土産のチョコはやっぱり超甘い。

==

日本のITエンジニアはここがいい！ ここがダメ！インド人ITエンジニアが見た日本

「日本人と働いた経験から一番にいえるのは、性格がとてもまじめで仕事もきっちりこなすところです」とナイル氏は語る。日本人ITエンジニアが最も得意だと思うものはテスティングだという。「日本のITエンジニアにテスティングしてもらうのが理想ですね。ほかの国のITエンジニアは日本人以上にはできません」。さらにナイル氏は、「日本人のきちょうめんさは、小さいころから漢字の訓練をしているためではないかと思う」との説を披露した。「最初はどうしてそこまで（綿密なテスティングが）できるのかなと思いました」と笑う。

そういえば漢字の練習はさせられたねえ。漢字文化ではない国の人にとっては漢字なんてただの記号にしか見えないね。僕らがアラビア文字を見てニョロニョロとしか思えないのと同じ。そういえば、日本にある書道ってアラビア文字にもあるみたい。(沢木耕太郎の「彼らの流儀」の一篇「砂漠の雪」参照)

閑話休題。

漢字書き取りってことは回帰テストが得意ってことなのだろうか。綿密なテスティングってことは日本人はテスト設計も得意だって意味かも。もう少しこの人の「日本人はテスト上手説」を知りたいな。

ミニ勉強会無事終了

今日の午後は珍しく外出。議事録用にノートＰＣ持ってくるの忘れちった。

社内の別のチームでテスト設計やソフトウェアテスト手法について勉強したいというリクエストがあったので、簡単な資料を作ってミニ勉強会を開催。そのチームは基本的にはWebサービスのテスト工程の短縮を模索していて、どうにかテスト実施の工数を減らせないか？という課題を持っていた。僕のプレゼンでは主にテストケース作成のコツをメインに説明したので、少し軸がずれていたのかも。

テスト実施期間の効率化は素直に考えて、やっぱり自動化/テストツール導入が一番効果的。少しそのあたりを地道に調査してみようかな。

直交表を利用して3因子間網羅を高める手法って、どこかに詳しく出てないかなあ。

テスト設計の社内勉強会への第一歩

雨が多いなあ。

今日は今まで調べたり実践したりしたテスト設計(テスト手法)について他のチームにプレゼンする。仕事の合間を使ってパワポにまとめていた資料を使うのだが、はたして上手に伝えることはできるだろうか。

これがうまくいったら、社内勉強会としてもう少し大きく広めていこうかな。そのときはケーススタディも準備してみようっと。

==

テスト設計の基本とさまざまなテスト技法-1

テスト技法というわけじゃないけど、テストって昔からいわゆるKKD（経験・勘・度胸）だけでやってきたという現場が多いんじゃないですか。KKDでやっている限り、MMK（もうかってもうかって困る）という次元にはまず達しないから基本的なテスト技法くらいは押さえておかないとね。

（中略）

Mustというか、テスト担当者は境界値テストを本能でやっていますよ。

境界値分析とかエラー推測なんかは普通に業務を何年か続けていればまさに本能でチェックしてるテストケースなんだろうけど、手順というかフレームワークとしてまとめておいたほうが、考慮し忘れなんかを防げて安心かな、って思う。

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

7月に発売されたソフトウェア・テストPRESS Vol.3は、テストの自動化やWebアプリのセキュリティソフトについての特集。

自分のプロジェクト専用のテストツールが必要だ、っていうのが最初のきっかけで、ソフトウェアテストや品質工学に興味を持ち出したのだ。Vol.3では自動化のためのテストツールの紹介などがメインでされている。

その他にもマインドマップを使ってテストケースを作成する手法も紹介されていて、経験の浅いメンバーにはこういうアプローチでテスト設計を伝えればいいんだなあと勉強になりました。

# もちろん、マインドマップを使うにもまずはコツが必要ですが。

==

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

テスト専門誌。内容はというと、上流工程でのインスペクションや直交表による組み合せテストの手順など。HAYST法による水準数拡大の手順も詳しく掲載してあって、Goodですな。うちの開発チームでもこのHAYST法を改良して、活用していこうと動き中。

ちょうどこのVol.2が出てすぐに JaSST '06 Tokyo があって、内容がかなりかぶってた。

==

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

昨年創刊したテスト専門誌。

創刊号は主にテスト設計の意義やテスト手法についての解説が多く、ゼロからはじめる人向けか。

- ホワイトボックステスト
- ブラックボックステスト
- 同値分割
- 境界値分析
- エラー推測

これが創刊された当初はまだまだ僕もヒヨコちゃんだったので、2号3号がでるのがすごい楽しみだったな。

==

ロングテールになりえない場合

うちの会社の開発規模はたいていの場合は5名ほど。大きなプロジェクトになっても高々20名。

404 Blog Not Found: オープンソース=ロングテール

このメール一通分のContributionを丹念に拾うことができたことこそが、オープンソースの品質向上につながったのだ。

高々数十名のメンバーでも、オープンソースのようなロングテール的な品質向上を目指す手法はどんなものがあるだろうか。最近流行のベータリリースもその一つに入るのか。いや、でも結局バグフィックス作業はその高々数十名のメンバーなのだから、期待薄か。

第25回ソフトウェア品質シンポジウム

有料のシンポジウム。

いくつか参加してみたいセッションがある。資料公開しないかなあ。
SQeBOKってはじめて聞いた。

==

http://www.juse.or.jp/software/symposium_25spcs.html

プロジェクト成功のためのソフトウェアテストの勘所

日本コンピュウェアからのセミナー情報より。

４つのプログラムのうち３つは製品紹介で、１つは事例紹介。
個人的には事例紹介は見てみたい。有償・無償・自作ツールによる
品質積み上げの具体的な紹介は参考になるかも。

==

プロジェクト成功のためのソフトウェアテストの勘所
〜ユーザーが語る実践アプローチと品質を確保するコンピュウェア製品の紹介〜

　ITとビジネスが密接に関係する現在、品質の高いソフトウェアを構築することは、
　企業にとって重要な課題となっています。ソフトウェア品質保証時代に向け、
　テスト手法や方法論などテスト市場は盛り上がりを見せていますが、実際の開発
　現場では、どのようにしてソフトウェアの品質を向上させるべきかといった具体
　的な情報、および解決策は不足しているといわれています。
　このセミナーでは、理想論ではなく実際にソフトウェアの品質向上という課題に
　取り組み、そして“品質を強み”に企業活動を行っている企業の具体例を紹介し、
　問題解決へのアプローチとそれらを支援するコンピュウェアツール製品をご紹介
　いたします。

　■ 2006年 9月26日（火）　13:30〜17:00 (受付開始13:00)
　■ 青山ダイヤモンドホール　（サファイア）
　■ 主催：　日本コンピュウェア株式会社
　■ 入場無料（事前登録制）

　 　イベントの詳細・申し込みは
　 　http://www.atmarkit.co.jp/event/campaign/compuware/sem060926/cont060926.html

ソフトウェアテストは重要

ソフトウェアテストについて、これから書いていきます。