あっという間の月曜日

今日はあっという間だ。

==

さっきちょいと4水準の因子を取り入れた直交表で3因子間網羅率をチェックしてみたら、だいたい25%程度しか3因子間網羅率がなかった。多水準化するとそんなもんになっちゃうのかなあ。2水準系じゃなくて3水準系で2乗化法して9水準作ったほうがバランスがよかったりして？

# つーか、2水準系の直交表とはまた別ロジックで作らねば。。。

戦略的なテスト -品質を上げようとするとコストが下がり、納期が短縮する-

ソフトウェア品質を高めるには（1）Quality Architectによる戦略的なテスト by アットマーク・アイティ

すべての個別最適はもともと、全体最適を狙う手段として始められたわけですから。必要なのは、組織の構成員すべてが全体最適を狙って行動することであり、そのきっかけとなる役割を開発現場の内部に配置することです。これは各プロジェクトの戦術的成功を支援しつつ、組織全体の全体最適を推進するという高度な作業にほかなりません。この役割を担う人財を“Quality Architect”と呼びましょう。

組織の全体最適を狙って、現場内部にQuality Architectを配置する、というアプローチと似てはいるが、もう少しテストプロセスの重要性が注目されてくれば、意識の高い技術者が協力しあって自発的なワーキンググループに発展していけるのかな、と思った。配置、ではなく、発生、みたいな。結果的に現場内部にそういったアーキテクトがいる、という点では同じだが。

自分の会社では、以前よりは「自分の会社をもっといい会社にしよう」という意気込みを持った社員が増えてきてそういったウェーブの期待度も高くなったと思ってる。まだまだ、西氏のいうような高度な作業を担うほどのQuality Architect」とはいえないので、日々勉強と経験だな。

腕の良いテスト技術者は、テスト対象に検出されたバグをさまざまな観点から頭の中で分析し、同じようなバグがほかにも作り込まれていそうかどうかを推測しています。そして開発者に、似たようなバグが作り込まれている可能性と推測される機能を伝えるのです。それによって開発者はデバッグの際に水平展開をして効率的にコードや設計、仕様を修正していきます。

自分の会社の現状のテストプロセスは、「開発者へ報告」→「調査および報告」→「対処」→「確認」といったやり取りが一般的だ。ここでいうテスト技術者のアクションとしては、調査報告を元にして「レビュー重点箇所」を報告する、といったものになるだろうか。しかし忘れてはならないのは、西氏も指摘しているようにその前提にはテスト技術者とシステム開発者との間に信頼と日々のコミュニケーションが必要な点。

そして個別最適のための活動や努力が、全体最適にきちんとつながっていることを把握し確認し続けることです。それこそが全体最適を実現する戦略的なテストといえるでしょう。

これは、テスト＝ライフサイクルプロセス、ということを示していると、僕は思った。

Quality Architectは、現場が思い込んでいる「品質を上げようとするとコストが掛かる」という誤謬を払拭し、「品質を上げようとするとコストが下がり、納期が短縮する」という正しい認識に改めることが使命です。

当然ながら、ビジネス研修で教わる、品質とコストはトレードオフだ、という概念を、ここではシフトしようということだ。実感としてまだ理解できてはいないが、「品質を上げようとするとコストが下がり、納期が短縮する」という言葉を記憶しておきたいと思う。

組み合わせテストでの自分の大きな勘違い(同値分割,境界値分析,エラー推測)

HAYST法について、今一度確認のためいろいろな資料を読んでいたら、自分が大きな勘違いをしていたことに気づいた。当初水準値を決定するときに、「同値分割」「境界値分析」「エラー推測」をすべて駆使するものだと考えていたが、そうすると水準数がけっこう大きくなることが多い。単純にメールアドレスを入力するtextフィールドでも、

空欄

存在するアドレス hoge@foo.com

存在しないアドレス userunknown@bar.com

@マークがない

user部の先頭が「.」

user部の末尾が「.」

user部にダブルピリオド「..」が含まれる

domain部に「.」がない

"名前" <アドレス>

アドレス (名前)

全ての文字が2バイト文字

etc

となって、多すぎ。グルーピングしたら2因子間網羅率もかなり下がりそう。うーん。(大文字小文字区別は別因子)で、いろいろ資料を読み返してみたら、組み合わせテストで設定される水準値は正常系についてが一般的なのだった。組み合わせテストでは、正常系同値分析と正常系境界値分析で水準値を設定し、エラー推測や異常系は単因子テストで確認することがベターらしい。(正常系と異常系のカテゴリミステイクについてはまた書くので、ここではご容赦)

自分としてはすっきりとした気分だ。でも、これも解釈が間違っていたら、どうしよう。

組み合わせテストケース作成ツール（サンプルその3）

前回よりも直交表の割り付け方を工夫したので、サイズも小さいし、多因子間網羅率も高いはず。。。

テストケース作成ツール（サンプル）

次の課題は、2因子間網羅率の計算と、3因子間網羅率の計算、かな。とりあえず今日はここまで。

直交表もだいぶわかってきたので、次はHAYST法の研究

直交表についてはだいぶわかってきたし、性質も見えてきた。そろそろHAYST法のほうも本格的に研究対象にしてみようっと。

==

HAYST法とは、富士ゼロックスの秋山浩一氏などが中心となって考案したソフトウェアテストにおける組み合せ手法のひとつ。ベースとなっているのは田口玄一博士で有名な実験計画法で用いられる直交表であり、

2水準系直交表の利用

禁則回避処理

組み合せ網羅率をテスト品質指標として採用

不具合の即時原因解析

パフォーマンステストの解析

といった特徴/手法を持っている。詳細の解説については今後記事として書いていけたら、と思っている。

※以下の資料を参考/引用しています

直交表を利用したソフトウェアテスト

直交表を活用したソフトウェアテストの効率化 - HAYST法の活用 -

テスターさんの募集 でいえばQAまっしぐらかも？

ソフトウェアテストに向いている人材とは by ウノウラボ Unoh Labs

先日リクルートページにテスターの募集が追加されたのですが、その際「テスターの募集条件ってどうしたらいいの？」という問い合わせを受けました。確かに、ふつうのエンジニアに比べるとテスター（QA）の募集条件って難しいです。今回はどんな人がテスターに向いているのかを書いてみたいと思います。

(中略)

4）リタイヤ型

リタイヤした腕利きプログラマやプロジェクトマネージャーにテストをやっていただく形です。例えば結婚や病気などで一旦最前線を退き、復帰しようと考えているけれどフルタイムでは動けない故に元の仕事に戻れない方などは知識経験共に豊富で最高のテスターになれます。プログラマ経験者であればテストツール作成などでも力になってくれるでしょう。そんな人材を確保出来た開発チームは幸せですね。

なるほど。時間的拘束が難しいが、経験や知識が豊富っていうのはナイスな条件かも。経験や勘だけでテストプロセスをまわしてはいけないけどね。テスト進捗管理なんかがきちんとできるんであれば在宅もありかな。

5）QAまっしぐら型

我こそはQAの星になろうという方。ほとんどお目にかかったことはありませんが、もちろん来てくださればありがたいことこの上ありません。

まあ専門技術としてQAは目標ですな。笑

社内勉強会の資料作成

社内の技術系勉強会でテストプロセスについてプレゼンするので、その資料作りをした。話したいことは山ほどあるけど、時間も限られているし、まずはデスクに帰ってすぐ実践できること、を話そうかと。例えば、テストケースの精度を向上させるために「エラー推測」「境界値分析」という手法を使いませんか？みたいな。

おそらくは経験豊富な方々は無意識的にやっていることでも、勉強会という場でそのことを「気づき」として得られればいいと思ってます。経験の浅い方々には、この基本的な手法だけでもぐーんとバグ検出の割合がアップする、はず。

目標としては、この勉強会を含めて同志を集めて社内的にワーキンググループを結成して、どんどん推し進めていけるのが理想。社外の、かなり有名人とのコネクションもあるらしいので、期待大！

でも、実際はやってみて反応をみてみないとな。。。

直交表における分割実験の意義に関する考察

今週は上司との上期成果の評価面談。特に目立った成果がないのだが大丈夫かな。。。製品検査で99点もらったのと、社外ワーキンググループのパネラーになったのとかを全面に出してみるかな。

==

直交表を左から低次な順に並べることで、右側の列に3因子間網羅率100%な列が集中することは、前に書いた。もうひとつ左側に並ぶ低次列に着目すると、0と1が比較的バラバラに出現することはなく、ある程度まとまって出現している。これは観点の違いによってメリットであったり、デメリットでもあったりする。

メリット

因子によっては容易に変更しがたいもの(OS, 接続環境, etc)があったりすると、頻繁に条件を変えてテストを実施するのが難しい。そこでこのように左側(1次因子)に変更の難しい因子を割り付けることで、テスト実施の効率化がはかれる。図では左から1次因子、2次因子、3次因子というように並んでいる。

デメリット

Webサービスでのソフトウェアテストではあまり考慮されないが、実際の実験では同じ条件で実験すると慣れてきてしまい、実験結果に影響することがある。(実験器具の扱いなど)この直交表の順番だと1次因子が同じ条件で8回実験を行うことになるため、通常は図でいえば16行をランダムに並び替えてから実験を行うことが一般的である。

以上のように、低次な順に並べることでメリットとデメリットがあるが、Webサービスの組み合せテストという観点でいえばメリットを享受できることが多いと思われる。

※本記事はあきやまさんのコメントを参考にしながら書きました。

直交表における2因子間網羅率の考え方

直交表をソフトウェアテストの条件組み合せ抽出に利用する最大の目的は、多因子間網羅率を100%にすることである。ソフトウェアの特性にもよるが、まずは2因子間の組み合せ網羅率を100%にすることが考えられる。この100%とはどういうことか。

上記のような単純な2次元マトリクスを利用することですべての組み合わせは交叉のマス目に出現する。同じ因子同士の組み合せは対角線上に出現し、2因子の順序を入れ替えた組み合わせは対角線を対称軸として上下に出現するので、必要なマス目は限られてくる。そして、このマス目数が2因子間全組み合せ数(53通り)となる。図では水準のグルーピングなどの手法を使ったため、直交法に出現しない組み合わせが4通り存在する(白色のマス目)。2因子間網羅率とは図でいう直交表に出現した黄色いマス目(49通り)の出現割合となるので、この場合は92.45%ととなる。

この網羅率を100%にするほうほうはいたって単純で、白色のマス目で表される組み合わせのテストケースを追加するだけである。

3因子間の全組み合わせを視覚的に上手に表現した表はまた今度紹介します。

属人化させないためのソフトウェアテスト技術

来週は社内のエンジニア向け勉強会開催。とりあえず30分くらいの時間でコツや技法を紹介してみようかと。

==

僕の上司はそんなことは思っていないが、どうやら一般的にはテスト技術者というのはあまり地位が確立されていないのが現状のようだ。個人的にはかなり高度な知識や能力をもったテスト技術者はそれなりの人財だと思うし、手放すべきではない。

日本におけるソフトウェアテストの位置づけ by ただいま修行中...

実は、テストというのは非常にセンスがいる作業である。

（中略）

これに関してはどうしても属人化してしまう。そこをいかに属人化しないで、ナレッジとして蓄積していくことが企業における財産になる。

単にテストケースを作成したり、テストを実施したりすることに技術はさほど必要はない。が、「効率的」とか「効果的」といった側面で考えると、それは専門的な知識も必要。無駄なテストケースを作らず、限られたコストでどれだけの不具合を検出でき、どれだけの範囲の品質を保証できるか、その品質レベルがプロジェクトの意義に適応したものかどうかの判断、そしてその評価結果をプロジェクトリーダや主要な利害関係者に納得させられるか。まさにプロジェクト管理にかかわる能力がフルに活用されるドメインじゃないか。

この著者のご指摘の通り、そのノウハウをどうやって社内へ（あるいは業界全体へ）ナレッジとして蓄積させるかも重要な任務なんだな、と改めて感じました。

[セミナー]包括的なテスト管理と目に見える品質分析の実現セミナー

久しぶりのセミナー参加。テスト計画についてのセッションが注目かな。

==

包括的なテスト管理と目に見える品質分析の実現セミナー
　〜システム構築における品質向上のためのテスト管理のポイント〜

http://www.isid.co.jp/event/bs061110.html

システムの重要性、規模が大きくなるほど、品質の向上とテスト効率の向上が必要となります。このようなテスト／品質管理フェーズにおいて、自動化できる部分は自動化し、貴重な人的リソースを最適に配置し、組織全体の生産性を高めることが緊急課題となりつつあります。今回、マーキュリーのビジネスパートナー、電通国際情報サービス様主催のセミナーにて、これらの課題を解決するための最新かつ最適なソリューション、およびノウハウを実際の経験に基づき、詳しくご紹介させていただきます。

◇日 時： 2006年11月10日(金) 13：30〜17：00（開場 13：00）
◇参加費： 無料 ＜事前登録制＞
◇会 場： 株式会社電通国際情報サービス 3Fセミナールーム
東京都港区港南2−17−1
地図 >> http://www.isid.co.jp/place/index.html
◇主 催： 株式会社電通国際情報サービス
◇協 賛： マーキュリー・インタラクティブ・ジャパン株式会社
日本ヒューレット・パッカード株式会社

【プログラム】━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
13：30〜13：40
【ご挨拶】

13：40〜14：30
【テストプロセスの改善によるワンランク上の品質の実現】
NPO法人ソフトウェアテスト技術振興協会（ASTER) 理事
JSTQB Technical Committee委員 加藤 大受 氏

14：30〜15：15
【品質向上と効率的なテストエビデンス管理を実現する
統合ソリューションのご紹介】
株式会社電通国際情報サービス
マーキュリー・インタラクティブ・ジャパン株式会社

15：30〜16：15
【トラブル解析の標準化を実現!!
アプリケーション障害解決ソリューション “AppSight” のご紹介】
株式会社電通国際情報サービス ビジネスソリューション事業部

16：15〜17：00
【自動テストと手動テストの使い分け
テスト管理ソリューション“Mercury Quality Center”のご紹介】
マーキュリー・インタラクティブ・ジャパン株式会社

せっかくなので勉強した内容も加味したテストケース作成ツールにしたい

試験はいつになるのか不明だが、演習で学ぶ ソフトウェアテスト特訓150問の勉強はなかなかためになるかも。この本では紹介したとおり、要点をおさえておくことと基本を学ぶことに焦点があてられているため、すぅ〜っと頭に残りやすい。テスト技法やテストアプローチについての要点をまとめたら、テストケース作成ツールに反映してみたいな。

==

テストケース作成手順を、PMBOKチックに入力と出力とツールに分けてみた。まずは入力データ。

状態というのは、Webサービスであれば画面と同義語で、ログイン画面、検索結果画面、記事確認画面などがある。状態はその中に構成要素というものを複数個持っている。構成要素というのは、状態を構成している小さな機能であり、ヘッダーやフッター、バナー画像やヘルプなどの静的リンク、タイトルなどをさす。状態から状態への移動を状態遷移と定義し、各状態の2次元順序対になっている。例えば、ログイン成功（ログイン画面→HOME画面）、ログイン失敗（ログイン画面→ログイン画面）、ブログ記事投稿（記事確認画面→記事掲載完了画面）などがある。状態遷移も中に因子-水準の対を複数個持っていて、それは例えばユーザ名であったり、パスワードであったり、ユーザー種別であったりする。

これらを入力データとして、適切なツールを用いることで、いくつかのテストケースが出力データとして登場する。
状態の静的チェックケースは、状態に含まれる構成要素を入力データとし、主に自動化ツールなどでチェックケースを作成することになる。遷移条件の組み合せテストケースは、因子-水準の対を入力データとして作成される。利用するツールとしては、直交表やn因子間網羅率、重要度の分析などが適切か。そして、状態と状態遷移を入力データとすることで、ユースケース、シナリオが出力される。この場合も直交表や重要度の分析などがツールとして考えられ、その他では頻度の分析、禁則回避などが挙げられる。

ざっとまとめてみたこの配置をたたき台にしてもう少し考えてみるかな。

[本]組込みソフトウェア開発向けコーディング作法ガイド[C言語版]

ココログフリーメンテナンスが終了しています。

==

うちの会社では特にC言語によるコーディングが多いが、作法やルールは特になかった。ので、この本を使って何か品質向上活動をしようかと。ななめ読みではあるが、基本的なこと（変数初期化や例外処理の記述など）から特殊なことまで、あるいは信頼性、移植性、保守性といったカテゴリーに分けられていて、必要そうなものだけピックアップして自分のプロジェクトに使うといいかな。

状態遷移表をベースにしたテストケース

今更ながらユースケースの勉強をきちんとしたほうがソフトウェアテストももっと深く勉強できそうな気がしてきた。

==

状態遷移表という表記方法があって、2次元のマトリックスを縦軸(あるいは横軸)に現在の状態を、横軸(あるいは縦軸)に遷移後の状態をとり、その交叉するマス目に該当するイベントを記述するものである。表現の形式によってはイベントを横軸や縦軸にとったり、矢印などを用いた有向グラフの形で表現される場合(状態遷移図)もある。（下図はウィキペディアより引用）

Webサービスにおける多くの組み合せテストはある画面Ａからある画面Ｂへ遷移する際の条件をベースにして作成されるのであれば、この状態遷移表をうまく使って組み合わせテストケースの組み合せを考える手法があってもいいんじゃないかと。（すでにあるのかも）

また、上図でいえば行単位で眺めると、S1にはD1とD2の遷移が考えられ、S2にはD3,D4,D5の遷移が考えられる。これはS1の遷移に関する因子が「D1」「D2」という水準値をもつ、とも捕らえられるので、その組み合わせを効率的に作成することもできるだろう。実施カバレッジは100%とする必要はないが、設計カバレッジを向上させる手法にはならないだろうか。

直交表の高次群同士の排他的論理和は低次群に出現することについての考察

直交表の拡張の仕方が違うと列の順序も違ってくることに関する考察の続きです。題名が漢字ばっかり。。汗

==

田口玄一博士の工夫「低次の列から並べる」というのはどういうことか。例えば、基底aとbからなるL4直交表を左からa、b、a+bとする。これを次の大きさの直交表＝基底a、b、cからなるL8直交表へ拡張するとき、図のようにc、c+a、c+b、c+a+bと高次群の4列を追加すると、左から「低次」の順に並ぶ。すると、追加した4列はすべての列が基底cを含んでいるため、その中から任意の2列を抽出して排他的論理和を計算すると基底cが相殺されて、基底cのない左側3列のいずれかになることがわかる。つまり、高次の4列の中で抽出した2列の交互作用は必ず左側に出現し、当然3因子間網羅率が100%となるのである。

これはL16直交表、L32直交表、L64直交表・・・と同じ仕組みで成立する性質である。

[本]体系的ソフトウェアテスト入門

先ほどの本に続いて、ポケットブックではなくきちんとした書籍も購入。

こちらについてはまだamazonから届かないので、届き次第のレビューということに。

[本]演習で学ぶ ソフトウェアテスト特訓150問 JSTQBテスト技術者認定Foundation対応

JSTQBという認定試験があり、基礎的な知識を確認するためにはよい試験かと思ったので、勉強して受験してみようかと。ということで少し軽めの問題集みたいな本を購入。

分厚くもなく、要点をおさえておけてなかなか使いやすい本ですね。演習問題は全くひねりはなく本当に自分の学習度を測るのが目的であれば使えます。カバンに入れておいて電車とかで読もうと思います。これを読んでみると今までの僕のブログでの用語の使い方は統一性もなく、お恥ずかしい限り。。。そこらへんも注意してこれから記事を書いてみようっと。

組み合わせテストケース作成ツール（サンプルその2）

テストケース作成ツール（サンプル）

ひとまず、サンプル2号を作成。でも、やってみると直交が崩れてる。。。ショック。。。

今日はもうおしまい。

==

自分で試してみた。因子数は14個、いくつかは多水準化が必要な場合でやってみたらサイズが128に膨れてしまった。この大きさは妥当なのだろうか。それに、テストケースは出来上がってるけど、本当に網羅してるのかってのが一目じゃわかりにくいな。何か検算機能をつけてみるかな。

直交表は「有効」であっても「万能」ではない(2)

最近は直交表というキーワードでこのブログにたどり着く方も多いかと思います。僕も同じく徘徊している一人ですから。

==

HAYST法／直交表に関する教育や実践での問題 by つれづれなる技術屋日記

HAYST法の推進者からは、更に数の多い因子への対応法の話が出る。つまり、そのままだとより大きなサイズの直交表を小さなサイズの表にする手法の話。頭では理解できるものの、上記の抵抗感と同様にふと疑問が湧いてしまう。抵抗感は何かと以前から考えていたが、”直交性”が保てるかとの疑問かもと思うようになった。
”直交性”は相関の逆数で、大きければ大きいほど直交表としてはいいと言える。ただし、具体的な算出方法が思いつかない。２つの因子で、各因子の水準が数値なら出来なくはない。が、因子が増えると計算が面倒。まして、水準が離散的とかOn/Offのようなケースをどう考えたらいいのか？？？

直交表を組み合わせで利用するときのメリットは2因子間、3因子間といった多因子間の組み合せ網羅率100%な組み合わせを効率的に作成できる、といったことだと思っています。なので、「直交表としてよい」という指標としては例えば「2因子間網羅率」だとか「3因子間網羅率」でいいのかな、と。もちろん、網羅率だけを品質の指標として使うのは危険であり、直交表やHAYST法が万能ではないというのはそのためである。

６）HAYST法を救世主・絶対視する人達の存在。 HAYST法の推進者がそうだとは思わないが、HAYST法や直交表でテスト件数が相当減るとか品質が上がると思っている人達がいる。従来のテストを行う事自体を否定する事すらある。

直交表やHAYST法という名前だけが一人歩きしてしまったり、「直交」といういかにも数学的な用語がついていることから、ブログの著者が指摘するような危惧はぬぐえない。僕の認識としては、勘や経験だけで考えるよりも効率的に、効果的にテストケースが作成できる、といったイメージは持っています。品質が上がるというのはどちらかというと間接的な効果くらいかな、と。

よし。これからも、ブログのタイトル通り、日々勉強と反芻を繰り返していくぞ。そして実務にも活かしたい！

プログラマーとテスターのコミュニケーションをベースにした品質向上について

各方面でソフトウェアテストについてのブログ記事が登場してて、それを読むだけでも勉強になりますね。

==

テスティング -テスティングの勘所- by 今日思うこと

ソフトウェアも人間がくみ上げるものであるから、バグの出方にも当然個性が出てくる。あるプログラマーは偉ー処理を軽視する。別なプログラマーはルーチン処理でよく無限ループにはまってしまう。などなど。

（中略）

話を戻そう。バグのくせを見つけるためには、まずプログラマーの性格を知ることが重要となる。そのために私はよくプログラマーに話を聞きにいった。仕様をどう理解しているのか、その理解をどういうアルゴリズムで実装しようとしているのか、自分でも自信がないところ、などなど。雑談を織り交ぜながら、しょっちゅう話を聞きにいった。

ソフトウェアテストの原則「欠陥の偏在」にも似たところがあるが、不具合は特定の箇所に集中しやすい。それは一般論として不具合を生みやすい要因があるのかもしれないが、実装を行ったプログラマーの癖や特性というのも大きく関わっていると思う。例えば、グローバル変数を使いやすい人もいれば、極力使わずに実装しようとする人もいる。構造体を多用したり、低水準のシステムコールを使用したり、様々である。

そういった癖や特性については主に静的レビューである程度把握することができると思うが、それはたいてい同じプロジェクトメンバーであり、開発する側の人間がレビュアーとなるのではないかと思う。マストさんの手法は、テスト担当者がその担い手となるというアプローチであり、より進んだ手法ではないかと思う。直接ヒアリングする、というところまではいかなくても、まずは癖や特性をデータベース化（見える化？）するなどのひと工夫によって、少しは効果が得られるのではないかな。

そうやって、担当プログラマの性格＝実装パターンが見えてくればしめたものである。某超有名アニメの腐海
に遊びにいく主人公が風が見えるように、目の前のソフトウェアにバグが見えるようになってくる。

この境地に達したテスト技術者はかなりすごいね。まさに救世主。青き衣のもの。

テストケースの「正常系/異常系」というカテゴライズについて

ソフトウェアテストには7つの原則(*)があって、そのひとつに「テストは欠陥があることしか示せない」という原則がある。これはどういうことかというと、テストというプロセスでは「不具合がない」ことは示せない、示せるのは「不具合がある」ことだけだ、ということを意味している。つまり、テストの目的＝不具合を見つけ出すことなので、より多くの不具合を見つけられるテストケースが優秀といえる。

テスト仕様書に「正常系/異常系」のカテゴライズは必要？ by クライングドーベルマン

第三者テスト、とかソフトウェアテスト専門部隊、に属する僕個人の意見としては、「正常系/異常系」のカテゴリーはテスト仕様書には特に必要ないように感じる。多分、「正常系/異常系」というカテゴリーはテスト実行の優先度として使用する目的で設定していると思うが、「とりあえず正常系から先にテストする」という戦略は時として重大なテスト漏れを発生させる危険があると思う。

（中略）

非常に極端な例ですが

5万ページを端から端まで印刷する正常系

パスワード欄に「' OR 1=1--」と入力する異常系

システム運用上、一般的に言って後者の優先度のほうが高いと思う。

極端な例ではあるが、まさにその通りだと思う。僕も一昔前は「正常系/異常系」というカテゴリーを使ってテストケースを分類していたし、今でももしかしたらそういったカテゴライズを念頭に考えているときも、あるかもしれない。もちろん、このカテゴリ分けが正しい場面もあるだろうが、テスト実施の優先度をきちんと分析する、という癖をつけないと、上で挙げられているような本末転倒的なテストをしてしまうかもしれません。

いうまでもないが「正常系には不具合がないからサボっちゃえ」という意味ではないです。5万ページの印刷は
極端な例ですが、10000件登録可能なアドレス帳についてはきちんと10000件登録でき、利用できることを試す
必要はあります。（CSV形式ファイルのインポート機能がついてたりするので）

このブログはあとでもっとみておこうっと。

(*) テスト技術者資格制度 シラバス（学習事項）

直交表の拡張の仕方が違うと列の順序も違ってくることに関する考察

直交表と交互作用で直交表における交互作用列がどこに現れるかについて言及したところ、あきやまさんから「右半分を使えば3因子間網羅率100%になる」というご指摘をいただいた。しかし、実際は僕の作った直交表ではそうならなかった。これはいったいどういうことなのか、について検証してみようと思う。（図はこのPDF資料を引用）

ソフトウェアテストPRESS Vol.2では、基本となる列の要素を倍に増やし、0と1が交互に現れる列とのXORを右に並べていくことで直交表を拡張している。具体的には下の図のように左から基本3列、0と1の交互列、基本3列のXOR列で構成される7列のL8直交表が完成する。

この拡張ルールで直交表を作成すると、右半分（4～7列）に属する任意の2列については交互作用が必ず左側（1～3列）に出現することになる。これは3因子間網羅率を100%にするという目的から考えれば、視覚的にわかりやすい形をした直交表といえるだろう。

対して僕の直交表の作成方法は、L2^k直交表の場合は、k列の基底a1、a2、...、akの線形結合の組み合わせでその他の列を生成している。
これはプログラムを使って直交表を作成するという観点からすると、シンプルなアプローチではあるが、上記の拡張方法とは異なり、いちいち交互作用列を見つけ出す必要がある。

以上のように、直交表の作成方法によって若干性質も変わってくるのである。

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

GREE Labs による第7回オープンソーステクノロジー勉強会の議事録がアップされていたのでチェック〜。

第7回オープンソーステクノロジー勉強会 −開催のご報告−

JaSST実行委員でもある加藤大受さんの講演内容はかなり整頓された内容で、自分の学んだ内容の反芻にはとてもいい資料でした。参考にさせていただきます。Webアプリケーションについては僕はかなり知識不足なので、この資料は今後何度もお世話になりそうだ。

• SPAM判定などの学習機能のテストの場合、どうやって性能テストを行う？
• 何をもってSPAMにするかの基準値があるはずなので、その仕様にあわせて簡単なテストケースを書く。
• 学習機能は、何をもって学習するのかを定義して、学習のテストをする
• SPAM判定も同様。
• その上で、実際はSPAMを収集して、テストする。

これは、質疑応答の中にある「SPAM判定の学習機能」についての問い。これは悩みのタネである。SPAM判定機能のやっかいなところは、相対的な判定基準でしかなりえないこと。ウイルス判定はほぼ間違いなく誰にとってもウイルスはウイルス。でも、SPAM判定は人によってそのしきい値が違うので、なかなか明確な基準を作るのが難しい。そこについては議事録ではあまり深くは掘り下げていないようだ。現場ではもっと何かやり取りがあったのだろうか。

Firefoxだと動かなかった。。。

組み合わせテストケース作成ツール（サンプル）でアップしたサンプルページ、Firefoxで試したら全然動かなかったみたい。。。なので、少し修正してみました。

Gmailのメール作成画面の条件パターン

あぁぁぁ、恥ずかしい・・・

テスターの条件

先日みつけた今日思うことより。

テスティング -テスターの条件- by 今日思うこと

次に大切なこと、それは 『ものの見方が柔軟である』 こと。「マウスはマックのように１ボタンでなければならない」 といったように 「ＯＯＯ は ＸＸＸ でなければならない」 的な発想では質の高いテスティングは望めない。ユーザーは時に、開発者がまったく想定していない使い方をするものである。想定をしていない ＝ 作りこみをしていない ＝ テストもしていない ＝ バグが発生する、という構図になる。

会社に入った当初、僕のトレーナー役だった先輩からよく「テストをするときは天邪鬼になってやろう」とアドバイスしてくれたことを思い出す。普通に使っていては不具合は見つからず、単に消化したテスト項目数を増やすだけ。当時は感覚的にはわかった気がしたけれど、ソフトウェアテストの勉強をして、エラー推測・境界値分析というキーワードを目にするまで具体的に自分の手法としては確立していなかったと思う。

マストさんがおっしゃっているテスターに必要なこの能力は、エラー推測や境界値分析の観点に近い考え方かも、と僕は捉えています。何年もシステム開発に携わっている方からすれば、そんな手法勉強しなくても経験上やってたよ、という意見が出てくる気がする。でも、こうやって誰かの口から、どこかのサイトでひとつの手法として目にすることで、より一層自分の中の確固たる技術として根付くんじゃないかと僕は考えています。ソフトウェアテストについての勉強にはそういった意義があると信じています。

僕がもうひとつテスター（＝テスト技術者）に必要な能力を挙げるとしたら、それは妥当性検証力、かな。世の中にはいろいろな統計情報やメトリクスがあります。網羅率○○％、ステップ数あたりの不具合数、工数あたりのテストケース数、などなど。その中で、今自分が扱っているプロジェクトにはどの指標が適切なのかを見極める能力です。自分にその能力がなくても、誰と検証をすれば見極められるかがわかれば、それもＯＫ。そこらへんの能力は一言で「バランス感覚」という言葉にも帰着するのかも。

みなさんはどんな能力が必要だと思いますか？

組み合わせテストケース作成ツール（サンプル）

昨日の夜から風邪のためだるくかったので、薬を飲んで、雑炊とかを食べてだいぶ楽になってきた。

==

テストケース作成ツールの一部がだいたい形になった。2因子組み合わせテスト作成部分。直交表をベースにしてHAYST法に沿った多水準化（＝2乗化法）で実装。サンプルとしてGmailのメール作成画面でのメール送信パターンを使ってみた。因子や水準の抽出はかなり適当。。。

Gmailのメール作成画面の条件パターン

何か気づいたことをコメントしてくださると助かります。＞見てくださった方々へ

※追記
- ボタンを押すとテストケース表が表示されます（10/08）
- javascriptも初心者なので気づいたことがあれば（10/08）

あとで書く Seleniumとかオープンソース勉強会の資料とか

今日で製品検査日程終わり。と、同時に風邪ひいたかも。。。

WebアプリケーションテストツールのSeleniumについてや、オープンソーステクノロジー勉強会の資料がアップされてたので、それについて書こうとしたけど、風邪が治ってからにするか。

直交表は「有効」であっても「万能」ではない

東京地方は大雨な一日になりそうです。

==

直交表という組み合せテストの手法を勉強していて、以下のようなブログ記事に遭遇。

直交表の功罪 by つれづれなる技術屋日記

その人は、ソフトウェアでの組み合わせテストを直交表で作る事になっているんだが、成果としてもう○ヶ月近くモノが出ない。たった一つの直交表すら出来てこない。そもそもどんな組み合わせテストをするかで、細かい部分とおおざっぱな部分とで粒度がいい加減。因子と水準はそれなりに抽出しているが、機能のための因子が相当足りない。

(中略)

直交表の功罪かもと思った１日。ソフトウェアテストでの直交表の利用自体は、喜ばしい事だが、人によってはそれによって万事解決と思う人もいるみたい。

ソフトウェアにおける統合テスト・機能テストは、さまざまな条件を変えてシステム動作が仕様どおりに動作するかを確認する必要がある。単純に「条件の個数×条件の振り幅」で組み合わせを考えると非現実的な組み合わせをテストケースとして考慮しなくてはならない。でも、一般的には1条件、2条件〜3条件の組み合わせが網羅されているだけで、ソフトウェア内の不具合のほとんどが検出できると言われている。（何条件まで検証が必要かはそのプロジェクトの特製、コストや要求される品質によって変わる）

ソフトウェアテストで直交表を利用するというのは、2条件、あるいは3条件の組み合せ表をなるべく少ないテストケースで網羅しよう、というアプローチのことで、このブログの著者がいっているように「万能」な道具というわけではない。適切な因子と水準の抽出ができなければ不具合の検出が少なくなるだろうし、直交表を適用できない場合もなくはない。

今作成しているツールでも直交表を利用した組み合せテストケースが登場するが、やはりツール利用者の経験量・知識量などが因子と水準の抽出に影響するので、アウトプットに品質のブレが発生する可能性がある。「テストケース作成における生産性」は向上しても品質が追いつかないとまずいな。この問題の解決手段としては、今のところ「サジェスト機能」くらいか。もう少し工夫が必要かも。

また、直交表の話になってしまったが、とりあえず今朝邂逅したブログ記事についてでした。

テスティングの役割、インスペクションの役割

インスペクションとは、「不具合を作らない手法」で、テストは「不具合は見つけ出す手法」だと僕は思って
いて、【松尾谷徹が語る】現場力を高めるテスト(1)でも同様の考え方が掲載されている。

テスティング -ソフトウェア・テスティングとは？- by 今日思うこと

私がソフトウェア製作を説明する上でよく使う例えが “三権分立” である。“仕様の策定（スペック）”＝立法、“仕様の実装（プログラミング）”＝行政、“仕様の検証（テスト）”＝司法となる。つまりテスティングとは、裁判所の仕事に当たる。

この三権分立の例えは、なるほど、と思った。仕様というテストにおける「法律」が存在し、裁判、すなわちテストはその「法律」を基準にして実施され、裁かれる。この例えを使えば、インスペクションというアプローチは法律を制定するところで実施される手法、ということになりそうだ。品質という数値化しづらいことを扱うのでテスト完了の見極めが難しいと言われるが、このブログでいう上流工程でのテスティング（≒インスペクション）の評価も意外に難しいんじゃないかな、と最近思ってます。

次回以降もこちらのブログは期待してます。

最近はこういったソフトウェア品質向上関連のブログがけっこう目立つようになってきて、勉強しやすくなってきたな。

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

今回は3つのプロセスの中で「テスト」に焦点をあててみたいと思う。

==

テストの手順として思いつくものとして、

1. テスト対象の分析をする
2. 分析結果を元にしてテスト設計をする
3. テスト設計をテスト計画・テストケースといった具体化をする
4. テスト計画に沿ってテストケースを実行する
5. テスト結果を分析し、テスト対象の評価をする

といったステップが考えられる。まずはテスト対象を抽象化したり、ドキュメントからテスト対象を明確化したり、ドキュメントに載っていない性質を洗い出すことからはじまる（分析）。その分析を元にしてテスト対象の品質を向上させるという目的で、どういった検証をどういった期間でどういったアプローチで行うかを検討する（テスト設計）。設計されたテスト計画は、掘り起こし作業によってより具体的な項目となり（テストケース作成・実装）、その検証作業が実行される（テスト実施）。検証結果が当初の目的＝テスト対象の品質向上が達成されたかを確認し（評価）、テストプロセスは完結する。

このプロセスの中で明確化されてはいないが、重要な作業として私は「テストケースの順位付け」を挙げたい。テストケースの並べ替え、でもよい。順位付けはテスト設計者によって多少変わるだろうし、プロジェクトによっても変わることが予想されるが、私の考えではより影響度の大きい、より重要度の大きいものをテストケースの処理順序で前のほうに配置し、比較的軽微なテストケース（文言チェック・静的リンク切れチェックなど）は中間くらいに、終盤には組み合せテストケースの網羅漏れケースを配置すべきではないかと考えている。まずは修正コストの大きいと思われるテストケースの検証を行い、最後はフリーテストと似た位置づけで網羅漏れテストケースを実施する。

さて、皆さんはテストケースの順番はどうやって決定していますか？

（続く）

やみくもに作るのはよくない

やっぱり、やみくもにコードを書くのはよろしくないな。

==

今作成中のテストケース作成ツールでは

1. 各画面に対するチェックケース
2. 各画面フローに対する組み合わせテストケース
3. シナリオテストケース

あたりを自動的に作成しようかと。

各画面チェックケースというのは、静的情報の確認がメイン。レイアウトチェックとか、画像表示チェックとか、リンク切れチェックとか。そこらへんは別に自動的に作成しなくてもいいんだが、まーせっかくなので。

各画面フローに対する組み合わせテストケースというのは、「○○条件で△△を実行した結果は□□となるはず」といったテスト内容になるはずなので、

1. 1因子テストケース


2. 2因子テストケース

となる予定。ここではなるべく3因子間網羅率を100%にしながら、水準組み合わせを行う必要があるが、それについては今までここで書いてきた情報が役に立つ。グルーピングなどによってn因子間網羅率が100%を下回るケースもでてくると思われるので、そこも自動的に計算して表示させたいな。

# ところで、2因子テストケースを作成すると、実は1因子テストケースって含まれちゃってる気がするが、どうなんだろう？？？

シナリオテストは、一般的には視点を変えて（不正利用を試みるユーザ、初心者ユーザ、といった視点で）実施することを指すのだが、うまく表現できるかなあ。

あと考慮すべきこととしては、各テストケースの優先順位か。それと、因子・水準などのサジェスト機能。境界値分析やエラー推測をさくっと設定できたり、を目指して。

サーバ冗長化の罠

直交表マニアになってたので、切り口を変えて。

==

Webサーバやメールサーバは並列にサーバを用意して、冗長性を持たせることがよくある。複数台のサーバをロードバランシングすることでハード故障などによるサービス停止を防止することが可能なので、一般的な品質向上のアプローチのひとつ。

でも、ここにはひとつの罠があると思っていて、定期的にサービスの拡張や各サーバのメンテナンス目的で新しいサーバを導入したり、切り離し→再組み込みといった作業が発生する。ここでネットワークの設定やロードバランスの設定、アプリケーションの設定を怠るとたちまち1/nという確率でサービス停止が発生する。（しかも、1/nという確率なので意外と早期発見されないケースが少なくない）

品質向上のための冗長化も、ポイントを抑えないとトラブルの種が潜んでる。

直交表と交互作用

直交表を用いることで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の場合も同様である。

テストの自動化の理想と現実

先週、「プロジェクト成功のためのソフトウェアテストの勘所」というセミナーが開催された。興味もあっていってみたかったが、都合がつかず。ということで、ネットで参加者のレポートを検索。。

「プロジェクト成功のためのソフトウェアテストの勘所」参加レポート を書きました(アークウェブ ビジネスブログ)

「プロジェクト成功のためのソフトウェアテストの勘所」参加レポート(wiki)

主にソニー高橋寿一さんの基調講演のポイントがメモされている。テーマはテストの自動化と理想と現実についてであり、安易なテスト自動化への傾倒には罠がある、といった感じだ。僕も今テストケース作成をツール化しているのだが、あまりにも網羅率への意識が強いとテストケースの肥大化と無駄化が進んでしまい「バグをみつける」という目的から逸脱しそうになる。サービス/機能を全て網羅することは重要ではあるが、それはテストのもうひとつの目的、「品質保証」の切り口でなければ意味がなくなってしまう。

「テスト網羅率100%です」などといった頭の悪いこと言わないようにしよう

まずテストケースを設計するときは網羅率100%を目指して作り、そのあとから有効なものや優先順位の高い項目をリストアップしていく、といった作業がいいんじゃないかと今の僕は考えている。著者のいうとおり、ただ安直に「網羅率100%」というだけではコストに見合った品質は得られない。

# 網羅率100%(に近い)テストケースを作るのってすごく大変なので、そこをツール化しようとチャレンジ中
# 万能ではないにしろ、GUIをメインにしたサービス限定とかで実現してみたいな

(自動化に)向かないテスト

• 回帰テスト（賛否両論あり）

僕はどちらかという賛否の「賛成」のほう。扱っているプロダクトの特質からかもしれないが、ここをどう自動化・効率化するかが大きいと思ってます。インターネットのサービスでは総じて同じことが言えそうな気がします。あくまで私見ですが。

状態遷移テスト

• 状態遷移は状態遷移図を書いた後、自動化する価値がある

ポイントだけなので詳細は推測になってしまうが、状態遷移図をインプットとしてテストケースやテスト実行を自動化する、という意味であれば、なるほど、それは価値は意外と大きい。各画面とその遷移グラフから何をチェックすべきか、といったノウハウがあればテストケース作成はある意味シンプルかも？

回帰テスト（リグレッションテスト）

• 上手く自動化する手法はない。自動化には最深の注意が必要

講演者である高橋さんが回帰テストの自動化に否定的だからなのか。もう少し詳細情報がないかググってみるか。

==

その他、かなり有益な情報が載っているので、上記以外はあとで読む。