47都道府県のプルダウンは何水準？

今日も勉強会からの気づきとして。

==

例えば、都道府県のプルダウンメニューがあったとする。まあ、選択したら都道府県庁所在地が表示されるとか、市区町村が新たに現れるとか、いろいろありそう。

都道府県
北海道
青森県
岩手県
宮城県
秋田県
山形県
福島県
茨城県
栃木県
群馬県
埼玉県
千葉県
東京都
神奈川県
新潟県
富山県
石川県
福井県
山梨県
長野県
岐阜県
静岡県
愛知県
三重県
滋賀県
京都府
大阪府
兵庫県
奈良県
和歌山県
鳥取県
島根県
岡山県
広島県
山口県
徳島県
香川県
愛媛県
高知県
福岡県
佐賀県
長崎県
熊本県
大分県
宮崎県
鹿児島県
沖縄県

ここのテストって何通り実施するか。

当然、全部一度は試す

単純に47水準＋無選択、全部テストするよ。っていうのは、おそらくは単体テスト段階。単体テストであれば、比較的自動化もできるし、全部テストすることで上位テストを楽にできる。ただし、テストプログラムそれ自体がこの単体関数になりそうな気もするが。。。

境界値＋同値クラスで十分

まあ、どのテストフェーズかわからないが、これが一般的って意見に異論はなさそう。

• 北海道、沖縄、無選択


• 北海道、東京、沖縄、無選択


• 北海道、（各地方の代表）、無選択


• etc

とかかなあ。

実装方法も考慮して

いやまてよ、どんな実装してんだろう。まさか、if文で47分岐なんてしてないよな。配列とか使ってんだろうか。じゃ、配列の順番が正しいかもチェックしたほうがよさそうだな。漢字間違いとかないかな。2文字と3文字があるから、3文字の県は試したほうがいいかも。

ユーザ視点で

境界値はいいとして、やっぱり東京とかは頻度高いし、テストケースに入れておくか。そもそも必須項目なら、無選択っていらなくないか。プルダウンって選択しづらくないか。地図をクリックするほうがよくないか。

==

なーんて、一概に47都道府県という因子から水準を決定するのって、やり方・ポリシー・レベルによって違うと思うし、悪ければいっぱいテストする羽目になる。テストケースを減らす工夫も大事だが、テストケースが減らせる開発も大事だねえ。

デフォルトってなんぞや

昨日は、先日出版された「ソフトウェアテストHAYST法入門」の社外勉強会。

==

「デフォルト」というのは、初期値とか初期設定とか何もしないときの状態とか。ソフトウェアテストでいえば、「特にカスタマイズしていない状態」とか「標準的な値」とか、あるいは「最も利用される値・状態（最頻値）」を指すことが一般的。ただし、これってすごく曖昧な表現なんだということに昨日気づきがあった。「○○のデフォルト」といった場合、形容する○○に従属的な言葉なので、例えば、

OutlookExpressのMIME文字コード変換方式のデフォルト

GmailのMIME文字コード変換方式のデフォルト

だと、同じ「デフォルト」という条件だが、実際は違う。（Bエンコード×ISO-2022-JPだったり、Bエンコード×UTF-8だったり）これは、テスト仕様書に記載されるときに、ちょっとした勘違いや認識違い、考慮漏れを引き起こすのかもしれません。

[試験]JSTQBテスト技術者資格認定(8/25)

JSTQB試験も来週に迫っています。よくみると、今回の試験日は土曜日なんですね。いいなー。

今回の試験は、直前にテスト本が続々出ていたり（6月　マインドマップから始めるソフトウェアテスト、7月　ソフトウェア・テスト PRESS Vol.5、7月　ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方）、JaSSTが開催されていたりで、受験者も急増したんではないでしょうか。

無料で配布されているシラバスや、模擬試験などを活用したり、教科書・問題集を購入するもよし。

JSTQB教科書 JSTQB認定テスト技術者 Foundation Level試験 (JSTQB教科書)

posted with amazlet on 07.08.20

大西 建児 勝亦 匡秀 加藤 大受 佐々木 方規 鈴木 三紀夫 町田 欣史 吉澤 智美 湯本　剛
翔泳社 (2007/02/08)
売り上げランキング: 23005

Amazon.co.jp で詳細を見る

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

posted with amazlet on 07.08.20

正木 威寛
技術評論社 (2006/07/28)
売り上げランキング: 12904

おすすめ度の平均:

ソフトウェアテストの用語がコンパクトにまとまっているよい本だと思います。
受験者にも、そうでない人にもオススメ

Amazon.co.jp で詳細を見る

資格があれば品質が上がる、というわけではないですが、継続的な勉強のための一里塚として考えておくのもいいかと思います。第4回目は年越し2月くらい？

L2^k直交表からL2^(k+1)直交表が作られる証明

閉店間際に丸善で購入。

けっこうライトな数学本で面白そう。

==

ソフトウェアテストPRESS#2にある「直交表の拡張（100ページ目）」の手順で表を拡張すると、それもまた直交表となる。


こちらのPDF資料を引用させてもらいました。

それを証明してみようかと。（ソフトウェアテストではなく、すでに趣味ですが）ただし、証明とはいってもブログで証明を書くのはしんどいのでポイントだけ。やり方は帰納法で。

• サイズが8（=2^3）へ拡張すると直交表となる
　これは自明。
• 直交表サイズが2^kへの拡張が正しいと仮定

　つまりはL2^k直交表については直交性が成立していると仮定しておく。
• 上記方法で表を拡張し、サイズが2^(k+1)の表を作成する
• この表が任意の2列に対して直交性をもつことを示す

　任意の2列を選び、左側にある列を列x、右側にある列を列yとする。



1. 列xおよび列yがともにk次因子以下


　k時点での仮定により自明。
2. 列xがk次因子以下、列yが(k+1)次因子


　列yはもともと、k次因子以下の列と左から2^k番目（0と1が交互に現れる列）の列との成分和で表現される。k次因子以下の列は行が2倍に拡張されていて、2^k番目の列は0と1が交互にあわられる性質を持っているため、直交の性質は保存される。（ちょっと端折った）
3. 列xおよび列yがともに(k+1)次因子


　列x、列yともにk次因子以下の列と左から2^k番目（0と1が交互に現れる列）の列との成分和で表現されるので、相殺されて結局はk時点での仮定により成立する。
• したがって、任意のk（k≧3）について成立する

証明中に少し出てくる、「高次因子群同士の交互作用が必ず低次因子群に表れる」という性質は、ソフトウェアテストへの応用という観点でいえば重要かも。

多水準化は計算で求める？線点図で求める？

夏ばて、ばてばて～。

==

N水準系直交表を変形させて、多水準化する手法がある。むやみやたらと列を結合するのではなく、列aと、列bと、列a、bの交互作用列a+bの3列を1列とみなして、4水準列を作ったりする。列a、列b、列c、列a+b、列b+c、列c+a、列a+b+c（順序は見易さで並べました）の7列を1列とみなして、8水準列を作ったりする。

これは直交という性質を維持するためであるが、上記のように交互作用を計算で求める手法と、線点図（田口玄一博士が提唱）を使って機械的に求める手法の2種類があると思っている。（「ソフトウェアテスト HAYST法入門」第5章でもテクニックとして紹介している。）

以前スクリプトで多水準化を作ってみたのだが、どうも線点図で求めたときと結果が違うのだ。。。これって、演繹ではなかなか最適な多水準化ができないってことなのだろうか。特にサイズが大きくなると、だめみたい。

時間があれば作り直すー。

==
2007/08/11 一部修正。取り消し線を追加。きちんと手順を追えば最適解が出せるはず。自作スクリプトが間違ってるみたい。

[書籍]「ソフトウェアテスト HAYST法入門」 で入門してみる

amazonで予約してた本が届きました。

本書はまえがきにもあるとおり3部構成となっている。

ソフトウェアテストの必要性・組合せテストの効果性

直交表とHAYST法、その実践

HAYST法の組織的な展開

技術的な勉強としては2部がメイン。テストPRESS#2での「直交表による組み合わせテスト入門」でわからなかったこと、理解が進まなかったことがあった方には、この書籍はかなりの助けになる。僕も気づきがあったし。テストPRESSとの比較を交えて何点か。

なぜ、すべての組合せをしなくてもいいのか？

直交表はすべてのn因子組み合わせがまんべんなく現れる性質がある、というのは説明されているが、じゃあどうして出現しない組合せをしなくてもいいのか。実は単機能テストや総当り表を使えば、その理由がより理解される。ちなみに2因子組み合わせを100%網羅するという点ではall-pair法も同様に実現できるが、この方法では高次因子間で偏ることも説明されている。

禁則ってどう考えたらいいの？

テストPRESS#2では見開きで2ページ弱だった禁則の解説が、今回は1章分、21ページもある。僕はここが苦手だったので、もう少し深く勉強してみなくては。

線点図と交互作用

線点図を使えば多水準化ができるももちろんだが、2列と交互作用列との3列で4水準列を作成する説明や、独立な因子同士は交互作用列を使いながらサイズ膨張を防ぐなど、より数学的な解説も多くなった。成分表示も追加されてました。（a、a+b、cみたいな）

効果とサイズのバランシング

サブシステムに局所化して、あとから結合する方法である程度の網羅性を犠牲にしつつも、サイズ膨張を防ぎ、効果を維持する手法などはテストPRESS#2にはなかったか。

そのほか、コラムが充実しているし、状態遷移の行列の積による考察もなかなか興味深い。しいて個人的な意見を言わせてもらうと、直交表が効果を持つのは、単機能テスト前提という場合が多いと思う。そのあたりの言及はされていたが、もっとしつこくあってもよかったなあと思った。単機能テストと組み合わせテストは野球で言えばスターターとクローザー、みたいな。どっちも点を取られないように抑えなくちゃいけないが、どちらも特性がある。なーんてね。

今後の期待としては「応用編」「実践編」などの続編（！）や原因結果グラフ・デシジョンテーブルなどの兄弟本も出るといいなあ～

==

今後、勉強会なども開催される予定なので、自分の勉強メモや気づきを書いていきたいです。

ソフトウェア・テストPRESS #5 - 技法道場をCEGで考えてみる練習

ココログフリーのメンテ終わったー。

==

今回のテストPRESSはおかずが多いですね。マインドマップのテスト本のフォロー記事や、「テスト計画の立て方、書き方、進め方」とか、テストツールとか、チームの話とか。

その中で、池田さん＆鈴木さんの技法道場が連載化したようです。今回はくす玉マシンを題材に、状態遷移図→シナリオを作成する手順を詳しく紹介しています。少し強引ですが、原因結果グラフで解いてみようと思い、少し考えてみました。この場合、残された1枚のメモだけが仕様であり、こんな感じ。

くす玉マシンは、くす玉の昇降とくす玉を開封する機能を提供する

くす玉が下がっている状態でコントローラの「くす玉ボタン」を押すとくす玉が上がる

くす玉が上がっている状態でコントローラの「くす玉ボタン」を押すとくす玉が開く

くす玉が上がっている状態、かつ、くす玉が開いている状態でコントローラの「くす玉ボタン」を押すとくす玉が下がる

くす玉の昇降中、コントローラの「くす玉ボタン」と「電源ボタン」は無効

開いているくす玉は人が閉める必要がある（自動で閉じる機能はない）

電源ボタンはくす玉が止まっているときに有効

電源が入っている状態で「電源ボタン」を押すと、くす玉が割れていなくても、割れていても下に降りる

くす玉が降りている状態で「電源ボタン」を押すと、電源が切れる

電源が入っていない状態で「電源ボタン」を押すと、くす玉が下がっている状態とする

原因ノードはこんな感じかなあ。

結果はこんな感じ。「そのまま」という結果ノードも作ってみた。

んで、原因結果グラフを作っていたが、全てをまとめるのが難しかったので、各結果ノードに対する原因ノードの関係、というくくりで作ってみた。制約とかの表示は割愛しちゃいましたが。

中間ノードが31～34まで出現したが、31＝くす玉が昇降中、って感じだが、それ以外の名前がイマイチつけられない。（それって中間ノードとして怪しいのかも。。。）今日はこの辺で。けっこうエイヤーで考えたから、あとできちんと見直して、そしてデシジョンテーブルに落とし込むかな。