テスト設計コンテストを振り返ってみる。
※感想などは、あくまでも中岫の主観
テスト設計コンテストのお題となるテストベース(※1)
テスト設計コンテスト'11～13「SESSAME 話題沸騰ポット」
テスト設計コンテスト'14「自動販売機プログラム(ASTERオリジナル)」
今回は'11～13で使われた「話題沸騰ポット」に関してのお話。
話題沸騰ポット
「話題沸騰ポット」、一言で言うと、沸騰、保温機能付きのポット。
＃話題沸騰ポットの要求仕様の詳細こちら
仕様書の書式はUSDM(※2)。
概要はこんな感じ
～概要～
第1章はハードウェア構成とハードウェア要求仕様
外観と操作パネルについて
第2章は操作要求仕様
各操作部位の操作とその振る舞いについて
第3章は温度制御行為
温度制御による振る舞いについて
第4章は温度制御方式
温度制御の仕組みについて
USDMで書かれてるので、仕様がまとまってるかなと思いきや
一筋縄ではいかない。
どこか読みづらさがあった。
＃なんでだろう？
テストベースを理解するために
まずはやってみたこと。
初参加の時は、各自が思いのままに読み込むところから開始。
写経したり、書き直してみたり。
個人の理解は進んだけど、まとまりはなかったと思う。
２回目の参加の時は、テストベースの全体を把握するようにモデルを作成するところから開始。
自分はまともにモデリングというものをやってきたことがなかったため、正直どうしたら良いか悩んだ。
自分が選んだアプローチは、テストベースの構成要素を切り出し、関係性を結んで整理する。
ということを思いのままにやった。
＃おそらく一般的な表現方法があったとおもうけど、無知なために独自路線へ・・・
自分の描いたモデルは、モデルというには細かいと思っていたが、
メンバーの一人が全体を一枚絵でズバッと描いてきた。
この一枚絵がちょうど良い粒度に感じた。
＃これが後の「おぐチャート」と呼ばれるもの
この絵はどうやって描いたのか？
と伺ってみると
「なんとなく」
とのこと。
＃この感性はすごい。
いきなり全体絵を描く、自分とはまったく逆のアプローチ・・・。
異なるモデルができたけど、全体と詳細の理解度は深まったと思う。
テストベースをモデル化するって、有効なのかも。
ざっくりと整理
２つのモデルの違い
・「おぐチャート」、対象の状態遷移を主に表している動的モデルになる。
→動的モデルのおぐチャートはこちら
・自分が描いたのは要素の構造を表しているので、静的モデルになる。
→静的モデルの構造図はこちら
→異なる視点から整理する
アプローチは違い
・「おぐチャート」は全体像からのアプローチ（トップダウン）
・構成要素を積み上げて行くアプローチ（ボトムアップ）
→上からも下からも攻める
モデリングして良かった点
・メンバー同士での理解を共有できるようになった
・テストの全体像が把握できるようになった
・モデルをスームイン／ズームアウトすることでテストレベルの単位で整理がしやすくなった
＃構造的なモデルは最初から何かもの目的をもって作られたわけではないため、使いきれてなし無駄があると思う。
＃モデルを構築するのに必死すぎて、目的を考えず。
＃最初は、DFDも意識していたはずが…。
＃MVCモデルも使えないかなぁとか欲張りだしたり、そこからテスト詳細設計につなげたかったのだが、うまく使えず…。
＃もうちょっとまともな使い方があったかも。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
※1)テストベース（test basis）
コンポーネント要件やシステム要件を推測できる全てのドキュメント。これらのドキュメントがテストケースのベースとなる。(JSTQB用語集より)
※2)USDM
Universal Specification Describing Manner。要求を仕様化する技術・表現する技術。
【参考】
・JSTQB ソフトウェアテスト標準用語集
・SESSAME 話題沸騰ポット
・ASTER テスト設計コンテスト'14 テストベース
記事：中岫
テスト設計コンテストになんで参加したのかを振り返ってみる。
※感想などは、あくまでも中岫の主観
テスト設計コンテスト'12（初参加）
=====================================================================================
【経緯】
JaSST'11 Hokkaidoで
「道内在住のエンジニアのみなさ～ん、テスト設計コンテストに参加したい人いませんか？」
と募集してみたところ
・
・
・
返事がないただの(ry
シャイな道民はなかなか名乗り出ない。
募集期限も差し迫っている、北海道から参加チームが無い、というのもアレだと思い。
ADC「しょうがない、ここは私が(^^)/」
NK3「じゃあ、俺が(==)/」
OGS「じゃあ、私も(><)／」
ADC+NK3「どうぞ、どうぞ！！」Σ(゜ロ゜ノ)ノ ←OGS
という感じで、やる気いっぱいの有志を集めて参加することになりました。
「北海道らしい、なまらなテスト設計をやるべさ！！」
と意気込んだそうな。
=====================================================================================
このような感じで初参加。
この参加は、半分（いや、それ以上？）義務感的なところがありました。
そのためコンテスト主旨をほとんど理解していませんでした。
=====================================================================================
【結果】
賞なし
=====================================================================================
ぶっちゃけ、参加してみたもののアーキテクチャなんてものを全く理解していません。
そりゃ、コンテストでは勝てませんね。
～この挑戦で感じたこと～
・テスト対象の全体をとらえることが難しい
・会社も職種も違うメンバーでチームを組むことで、多様な意見、考えが吸収できる
・普段一緒に仕事しているわけではないので、用語一つをとってもかみ合わない
＃普段自分がやっていることを当たり前にやってみても意図が通じない
・コミュニケーションがとりづらい
＃お互いのお仕事の状況が見えないので
もっと得ることがあったはずなのに、実感がない。
目的意識が無いまま参加というのが良くなかった。
優勝チームの資料を見てみると、
なるほど、と思うことは多々あったのですが、実際に手を動かしてみるとできない。
何でだろう？理解できてないのかなぁ？そこがわからない。
何か他にあるのかな？
という状態に陥る。
また、コンテスト後に行われた「負け犬の会」なるもので、
そこの参加者が、「わかる」と言っていた…。
（まじで？？）
それを自分でできるの？それ、やってみるとそんなにできないよ？
できる人はできるのか？できる人だけができるもので良いの？
という感じで周りの反応を見ていた、自分。
「負け犬の会」の後、なんか悔しくて、遠吠え的に
「わかる」と言った奴、コンテストに出てこい！！
なんてツィートしてみた。
そんな初参加。
テスト設計コンテスト'13（参加２回目）
=====================================================================================
【経緯】
OGS「Ueさんがチームでテスト設計コンテストに出るんだって」
NK3+ADC「へぇ～そうなんだぁ・・・がんばって欲しいもんだねぇ～」
OGS「私、前回負けたのがくやしいの・・・」
NK3+ADC「ふぅ～ん、くやしかったんだねぇ～・・・・・・・、で？」
OGS「私やるっ！ Ueさんに絶対負けないもん(><)／」
NK3+ADC「どっ、、、どうぞ、どうぞ！！」
OGS「・・・まさか、私一人でやらせるわけ？あんた達・・ (▼▼) 」
NK3+ADC「まっ、、まさかぁ・・・めっ、めっそうもない！！(ToT)」
OGS「もちろん、そこにいるOGTも参加するよね？？？(▽▽ﾒ) 」
OGT「はっ、はいっ・・・?((((ﾟДﾟ；))))))))) 」
と、やる気いっぱいで集まった有志たち。
=====================================================================================
こんな経緯ではありますが、自分が参加した一番の理由は、
「前回が悔しかったから」
と言うのがホンネです。
あとはもう少しアーキテクチャってなんだろう？
というのを考えたかったから。
=====================================================================================
【結果】
前回王者の2連覇
自チームは準優勝！！
http://aster.or.jp/business/contest/contest2013.html
=====================================================================================
前回よりもテストアーキテクチャというものを意識はしたものの、
まだまだアーキテクチャというのが分かっておらず…。
地方予選をなんとか勝ち抜き本選へ。
地方予選後、審査員のアドバイスをもとにブラッシュアップのはずが、
成果物も時間に終われるように整理することに…。
ツギハギ感がたっぷり。
一応ごまかしたつもりが、審査員にはばればれでした（汗
～この挑戦で感じたこと～
・今まで得た知識を何とか使ってみようとするため、ものすごく実践的な勉強になる。
＃実務では、こんな技法使ってみたい！！と思ってもなかなか出来ませんよね。
・アーキテクチャを意識したけど、やっぱしまだ分からない
＃モデリング技術を身につけたいと感じた
フィードバックで「もっと一般的な技法など使わなかったのはなぜ？」
という感じの意見があった。
後から思えば、確かにもっと一般的な方法が使えたかも。
やってる最中は、知ってても使う余裕が無かったという感じ（汗
まあ、自分的には思いのままにやらせていただいたので、結果には満足気味の２回目の参加でした。
ここまでが前回までの参加動機と結果。
今回はというと
テスト設計コンテスト'14（参加３回目）←今回
=====================================================================================
【経緯】
・正直、自分は前回でお腹いっぱい感。
もういいかな、と思っていたら、テスト対象が一新されるとのこと。
↑ちょっと興味が沸く
・今回の審査基準に「工程の一貫性」があるらしい。
昨年の成果物はツギハギのため、今回の審査基準だと評価が低そう。
なんか改良したいかも。
＃一貫性を保つのに一人でやってみるかなぁと思っていたら某Ue氏に先手を取られる
・TEF道のイベントでテスコンに出てみたい人を集めてみたら、お一人いました。
→と言うわけで、チームを一新して個人ではなくチームとして参戦することに。
・気持ち的にテスコンを広めたいという気持ちもある
=====================================================================================
今回のメンバー構成
・100点を目指すメンバー
・実際にテスト設計をやってみたいメンバー
・テスト設計はじめてだけどチャレンジするメンバー
・やりたいメンバーがいるならやってみようというメンバー←自分
それぞれの異なる思惑を持つメンバー構成。
はてはてどうなることか。
ここで、チームで参加するメリット、デメリットを勝手に考えてみた。
【個人で参加】
◆メリット
・自分がやってみたいこと、つかってみたい技術、理論を思いのままに試すこと
・自分のペースで作業ができる
◆デメリット
・自分の知っている技術、知識の範囲でとどまる
・レビューアがいないため、思い込みで終わることもある
【チームで参加】
◆メリット
・いろんな知見が交わるため、発想の幅が広がる
・作業分担ができる
・レビューができるため、客観的なものが出来る
◆デメリット
・成果物の統一感がとりづらい
・打ち合わせなどの待ち時間が発生する
・なかなか決定出来ない
↑意見が合わないと争いが起きる場合も
どちらにもメリット、デメリットはあります。
どちらが優れていると言うことではないです。
個人でストイックに作業することで、自分の出来る幅を知るのもありですけど
自分的にはチームで作業した場合の方が、より良いものが出来る気がしています。
あと、教わる、伝えるなどで自分の勉強にもなることが多いかなと。
記事：中岫
※感想などは、あくまでも中岫の主観
テスト設計コンテスト'12（初参加）
=====================================================================================
【経緯】
JaSST'11 Hokkaidoで
「道内在住のエンジニアのみなさ～ん、テスト設計コンテストに参加したい人いませんか？」
と募集してみたところ
・
・
・
返事がないただの(ry
シャイな道民はなかなか名乗り出ない。
募集期限も差し迫っている、北海道から参加チームが無い、というのもアレだと思い。
ADC「しょうがない、ここは私が(^^)/」
NK3「じゃあ、俺が(==)/」
OGS「じゃあ、私も(><)／」
ADC+NK3「どうぞ、どうぞ！！」Σ(゜ロ゜ノ)ノ ←OGS
という感じで、やる気いっぱいの有志を集めて参加することになりました。
「北海道らしい、なまらなテスト設計をやるべさ！！」
と意気込んだそうな。
=====================================================================================
このような感じで初参加。
この参加は、半分（いや、それ以上？）義務感的なところがありました。
そのためコンテスト主旨をほとんど理解していませんでした。
=====================================================================================
【結果】
賞なし
=====================================================================================
ぶっちゃけ、参加してみたもののアーキテクチャなんてものを全く理解していません。
そりゃ、コンテストでは勝てませんね。
～この挑戦で感じたこと～
・テスト対象の全体をとらえることが難しい
・会社も職種も違うメンバーでチームを組むことで、多様な意見、考えが吸収できる
・普段一緒に仕事しているわけではないので、用語一つをとってもかみ合わない
＃普段自分がやっていることを当たり前にやってみても意図が通じない
・コミュニケーションがとりづらい
＃お互いのお仕事の状況が見えないので
もっと得ることがあったはずなのに、実感がない。
目的意識が無いまま参加というのが良くなかった。
優勝チームの資料を見てみると、
なるほど、と思うことは多々あったのですが、実際に手を動かしてみるとできない。
何でだろう？理解できてないのかなぁ？そこがわからない。
何か他にあるのかな？
という状態に陥る。
また、コンテスト後に行われた「負け犬の会」なるもので、
そこの参加者が、「わかる」と言っていた…。
（まじで？？）
それを自分でできるの？それ、やってみるとそんなにできないよ？
できる人はできるのか？できる人だけができるもので良いの？
という感じで周りの反応を見ていた、自分。
「負け犬の会」の後、なんか悔しくて、遠吠え的に
「わかる」と言った奴、コンテストに出てこい！！
なんてツィートしてみた。
そんな初参加。
テスト設計コンテスト'13（参加２回目）
=====================================================================================
【経緯】
OGS「Ueさんがチームでテスト設計コンテストに出るんだって」
NK3+ADC「へぇ～そうなんだぁ・・・がんばって欲しいもんだねぇ～」
OGS「私、前回負けたのがくやしいの・・・」
NK3+ADC「ふぅ～ん、くやしかったんだねぇ～・・・・・・・、で？」
OGS「私やるっ！ Ueさんに絶対負けないもん(><)／」
NK3+ADC「どっ、、、どうぞ、どうぞ！！」
OGS「・・・まさか、私一人でやらせるわけ？あんた達・・ (▼▼) 」
NK3+ADC「まっ、、まさかぁ・・・めっ、めっそうもない！！(ToT)」
OGS「もちろん、そこにいるOGTも参加するよね？？？(▽▽ﾒ) 」
OGT「はっ、はいっ・・・?((((ﾟДﾟ；))))))))) 」
と、やる気いっぱいで集まった有志たち。
=====================================================================================
こんな経緯ではありますが、自分が参加した一番の理由は、
「前回が悔しかったから」
と言うのがホンネです。
あとはもう少しアーキテクチャってなんだろう？
というのを考えたかったから。
=====================================================================================
【結果】
前回王者の2連覇
自チームは準優勝！！
http://aster.or.jp/business/contest/contest2013.html
=====================================================================================
前回よりもテストアーキテクチャというものを意識はしたものの、
まだまだアーキテクチャというのが分かっておらず…。
地方予選をなんとか勝ち抜き本選へ。
地方予選後、審査員のアドバイスをもとにブラッシュアップのはずが、
成果物も時間に終われるように整理することに…。
ツギハギ感がたっぷり。
一応ごまかしたつもりが、審査員にはばればれでした（汗
～この挑戦で感じたこと～
・今まで得た知識を何とか使ってみようとするため、ものすごく実践的な勉強になる。
＃実務では、こんな技法使ってみたい！！と思ってもなかなか出来ませんよね。
・アーキテクチャを意識したけど、やっぱしまだ分からない
＃モデリング技術を身につけたいと感じた
フィードバックで「もっと一般的な技法など使わなかったのはなぜ？」
という感じの意見があった。
後から思えば、確かにもっと一般的な方法が使えたかも。
やってる最中は、知ってても使う余裕が無かったという感じ（汗
まあ、自分的には思いのままにやらせていただいたので、結果には満足気味の２回目の参加でした。
ここまでが前回までの参加動機と結果。
今回はというと
テスト設計コンテスト'14（参加３回目）←今回
=====================================================================================
【経緯】
・正直、自分は前回でお腹いっぱい感。
もういいかな、と思っていたら、テスト対象が一新されるとのこと。
↑ちょっと興味が沸く
・今回の審査基準に「工程の一貫性」があるらしい。
昨年の成果物はツギハギのため、今回の審査基準だと評価が低そう。
なんか改良したいかも。
＃一貫性を保つのに一人でやってみるかなぁと思っていたら某Ue氏に先手を取られる
・TEF道のイベントでテスコンに出てみたい人を集めてみたら、お一人いました。
→と言うわけで、チームを一新して個人ではなくチームとして参戦することに。
・気持ち的にテスコンを広めたいという気持ちもある
=====================================================================================
今回のメンバー構成
・100点を目指すメンバー
・実際にテスト設計をやってみたいメンバー
・テスト設計はじめてだけどチャレンジするメンバー
・やりたいメンバーがいるならやってみようというメンバー←自分
それぞれの異なる思惑を持つメンバー構成。
はてはてどうなることか。
ここで、チームで参加するメリット、デメリットを勝手に考えてみた。
【個人で参加】
◆メリット
・自分がやってみたいこと、つかってみたい技術、理論を思いのままに試すこと
・自分のペースで作業ができる
◆デメリット
・自分の知っている技術、知識の範囲でとどまる
・レビューアがいないため、思い込みで終わることもある
【チームで参加】
◆メリット
・いろんな知見が交わるため、発想の幅が広がる
・作業分担ができる
・レビューができるため、客観的なものが出来る
◆デメリット
・成果物の統一感がとりづらい
・打ち合わせなどの待ち時間が発生する
・なかなか決定出来ない
↑意見が合わないと争いが起きる場合も
どちらにもメリット、デメリットはあります。
どちらが優れていると言うことではないです。
個人でストイックに作業することで、自分の出来る幅を知るのもありですけど
自分的にはチームで作業した場合の方が、より良いものが出来る気がしています。
あと、教わる、伝えるなどで自分の勉強にもなることが多いかなと。
記事：中岫
今年のテスト設計コンテスト（以下、テスコン）に参加することになりました。
今回で参加は3回目。
7/1に申し込みが開始され、7/31に締め切り。
今までどおり（？）期限ギリギリに申し込みをすると、
「キャンセル待ちのご連絡」というメールが！？
「えっ？なんで？？」
と思っていたら、
“各地区ごとにエントリーチーム数が決まってる”
という情報をキャッチ。
（以下、サイトより抜粋）
=================================================================
参加登録カテゴリごとに参加チーム数の制限を設けています。
参加は申し込み順といたします。
なお申し込み受付終了後、各カテゴリの定員数に満たない場合は
もう片方のカテゴリからの繰り上げ受付をいたします。
参加受領は事務局よりご連絡いたします。
企業・学校法人チーム：2チーム
一般チーム：1チーム
=================================================================
うかつでした。
申し込めば参加できると思っていました（汗
北海道は、昨年までは参加チームを集めるのに苦労していたことを考えると、
自然と参加チームが募るって、良いことですね。
テスコンの知名度が上がったということですね。
よかった、よかった～。
と喜んでいる場合ではなく、自分が参加できるかどうかの瀬戸際に…。
・
・
・
結局、キャンセル待ちのかいがあって、滑り込みで参加できました（汗
で、今年の参加が決まったということで、
今まで参加した成果物から何かヒントが得れないか、
自分の振り返りメモついでにブログにしてみます。
＃今やってることのネタばれはしないようにします（汗
まずはテスコンって何？というところから。
特定非営利活動法人（NPO法人）ソフトウェアテスト技術振興協会（ASTER:Association of Software Test EngineeRing）が主催のコンテストとなります。
公式サイトの直リン
テスト設計コンテスト'14
テスコンの概要
「ソフトウェアが世の中の基盤として定着するにつれ、その信頼性、安全性、使用性等を保証するテストの重要性はますます高まりつつあります。しかしながら、テストは・・・」
要は、
ソフトウェアを実装する設計技術と同様にソフトウェアのテストすることについても設計技術があって、その設計のやり方や考え方を共有しつつ、競って技術を高めよう！！
ということ。
競うって？何をどうやって？って思いますよね。
審査基準が公開されています。
以下、昨年度との審査基準との比較（各項目の詳細はサイトを参照）
昨年までは、採点の多くのウェイトを占めていたテストアーキテクチャが少し軽くなった。
（それでも一番のウェイトだけど）
詳細設計が少し比重が重くなり、一貫性というのが出てきました。
＃昨年までは、メンバーが思うようにやってみて、ツギハギした感が強いのと
＃設計詳細よりもアーキテクチャを抑える、と言う内容だったので、
＃今回がそれと同様だったらまずいです…
たぶん、わかりやすいテストアーキテクチャを考えると、
おのずと一貫性がでてくるんだとは思います、なんとなく。
さて、ここで出てきた「テストアーキテクチャ」
正直、いまだに理解し切れていません、自分。
審査基準のあたりにも概要的な説明がありますが、
JaSST'12 Tokyoのテスト開発方法論（智美塾）の資料から抜粋します。
【テストアーキテクチャとは】
複数のテストバスケットにグルーピングされたテスト観点の集合のこと
テストバスケットとテストバスケット間に何らかの関係を持つ
テストバスケット？テスト観点？？
なにやらいろいろ用語が…。
【テストアーキテクチャの要素】
・テスト観点
テストの関心ごとを列挙したもの
・テスト観点の種類
テスト目的：欠陥を見つける始点
テスト対象：欠陥を持ってるもの・ところ
・テストフレーム
基本的に、テスト目的とテスト対象が結びついたものをさす
テスト目的しかないもの、あるいはテスト対象しかないものも認める
・テストバスケット
複数のテストフレームを 何らかの視点でグルーピングしたもの
・テストタイプ
同じテスト目的をまとめたもの
・テストレベル
同じテスト対象をまとめたもの（順序関係を持つ）
テストの対象をある目的をもってどうテストするかを考えて、
それをグルーピングして整理したものをアーキテクチャと呼ぶのかな？
と理解。
◆テストアーキテクチャで目指すもの
テスト設計の構造を表す
一目で見渡せる
目的・観点・使用場面が異なれば複数の絵になる
記表は問わない
抽象的にとらえたときにどうかと言うこと
テストの全体像をなのかな？
たしかにこういうテストするコトガラを分かりやすく抽象的に整理あいたものがあると、
テストケースを作成する人、テストの対象を作る人、テストを実行する人たちで、
どのようにテストをするか、共通認識できるようになる気がしますね。
◆良いアーキテクチャ
○分かりやすい
○抜け画内
○構造・形が見える
×たんなる一覧表ではない
×最初からテスト実装を並べていくのもアーキテクチャではない
○意思、関心ごとでまとまっている
○どうやってテストするか、ではなく、何をテストするか
○目的と対象とが明確になっている
○俯瞰性と網羅性を併せ持つ
ふむふむ、この辺を意識すると良い感じのテストアーキテクチャが出来そう。
でも、結局何をやるのだ？
とまだモヤッと。
【テストアーキテクチャ設計】
どうやって（How）テストするか
・テスト全体の要素と構造を明らかにする
・テスト要求分析のアウトプット、すなわちテスト観点（テストすべきこと）を、網羅・俯瞰できる構造を作るアクティビティ
・テストのしやすさを考慮して要素の関係を最適にする
・テストの観点を体系化することはテスト手段を導くことに密接に関わっていることと、テストアーキテクチャ設計をするなかでテストすべき観点を発見することもあるため、厳密な意味でのWhat-Howの関係と言うよりもWhatとHowがオーバーラップしているイメージでとらえた方が良い
なにをテストするかを分析して、それをモトにどうやってテストするか、
を考えると良いのかな。
網羅と俯瞰とテストのしやすさがキーワードっぽい。
アーキテクチャを最初に考えたら、アーキテクチャはそれで終わりではなくて、
さらにそれを基にした作業で新たな観点などが出てきたら反映するということか。
行ったり来たりするんだな。
なるほど。
これらの成果物を競うというのが「テスト設計コンテスト」
ちなみにコンテストのInputはコレ（テストベース）。
スケジュールはこんな感じ。
7月 参加受付
8月 テスト設計コンテストチュートリアル
9月 成果物の締め切り（？）←不明
10月 テスト設計コンテスト北海道予選（JaSST Hokkaido）
3月 テスト設計コンテスト本戦（JaSST Tokyo）
まずは、地方予選の突破をめざすぞ～
＃今年は参加登録が終わりましたが、興味がもった方はぜひ次年度トライしましょう！！
【参照サイト】
・テスト設計コンテスト公式サイト テスト設計コンテスト'14
・テスト設計コンテスト'14 審査基準
～JaSST'12 Tokyoの資料～
・智美塾オープニング
・テスト要求分析の概念
・テストアーキテクチャ設計の概念
・テストバスケット間の構造f
・テストアーキテクチャの考慮点
・テストアーキテクチャの具体例
今回で参加は3回目。
7/1に申し込みが開始され、7/31に締め切り。
今までどおり（？）期限ギリギリに申し込みをすると、
「キャンセル待ちのご連絡」というメールが！？
「えっ？なんで？？」
と思っていたら、
“各地区ごとにエントリーチーム数が決まってる”
という情報をキャッチ。
（以下、サイトより抜粋）
=================================================================
参加登録カテゴリごとに参加チーム数の制限を設けています。
参加は申し込み順といたします。
なお申し込み受付終了後、各カテゴリの定員数に満たない場合は
もう片方のカテゴリからの繰り上げ受付をいたします。
参加受領は事務局よりご連絡いたします。
企業・学校法人チーム：2チーム
一般チーム：1チーム
=================================================================
うかつでした。
申し込めば参加できると思っていました（汗
北海道は、昨年までは参加チームを集めるのに苦労していたことを考えると、
自然と参加チームが募るって、良いことですね。
テスコンの知名度が上がったということですね。
よかった、よかった～。
と喜んでいる場合ではなく、自分が参加できるかどうかの瀬戸際に…。
・
・
・
結局、キャンセル待ちのかいがあって、滑り込みで参加できました（汗
で、今年の参加が決まったということで、
今まで参加した成果物から何かヒントが得れないか、
自分の振り返りメモついでにブログにしてみます。
＃今やってることのネタばれはしないようにします（汗
まずはテスコンって何？というところから。
特定非営利活動法人（NPO法人）ソフトウェアテスト技術振興協会（ASTER:Association of Software Test EngineeRing）が主催のコンテストとなります。
公式サイトの直リン
テスト設計コンテスト'14
テスコンの概要
「ソフトウェアが世の中の基盤として定着するにつれ、その信頼性、安全性、使用性等を保証するテストの重要性はますます高まりつつあります。しかしながら、テストは・・・」
要は、
ソフトウェアを実装する設計技術と同様にソフトウェアのテストすることについても設計技術があって、その設計のやり方や考え方を共有しつつ、競って技術を高めよう！！
ということ。
競うって？何をどうやって？って思いますよね。
審査基準が公開されています。
以下、昨年度との審査基準との比較（各項目の詳細はサイトを参照）
| 項目 | '14配点 | '13配点 | 備考 |
|---|---|---|---|
| テストアーキテクチャ設計 | 30点 | 40点 | |
| テスト詳細設計・実装 | 20点 | 15点 | |
| 工程間一貫性( | 10点 | - | 今回から追加 |
| 技術 | 20点 | 35点 | |
| 文書 | 10点 | 10点 | |
| プレゼン | 10点 | - | 昨年度は、プレゼン点は、本選決勝でのみ加点 |
| 特別 | 20点 | - | 昨年度は、特別点の上限を公開されていない |
昨年までは、採点の多くのウェイトを占めていたテストアーキテクチャが少し軽くなった。
（それでも一番のウェイトだけど）
詳細設計が少し比重が重くなり、一貫性というのが出てきました。
＃昨年までは、メンバーが思うようにやってみて、ツギハギした感が強いのと
＃設計詳細よりもアーキテクチャを抑える、と言う内容だったので、
＃今回がそれと同様だったらまずいです…
たぶん、わかりやすいテストアーキテクチャを考えると、
おのずと一貫性がでてくるんだとは思います、なんとなく。
さて、ここで出てきた「テストアーキテクチャ」
正直、いまだに理解し切れていません、自分。
審査基準のあたりにも概要的な説明がありますが、
JaSST'12 Tokyoのテスト開発方法論（智美塾）の資料から抜粋します。
【テストアーキテクチャとは】
複数のテストバスケットにグルーピングされたテスト観点の集合のこと
テストバスケットとテストバスケット間に何らかの関係を持つ
テストバスケット？テスト観点？？
なにやらいろいろ用語が…。
【テストアーキテクチャの要素】
・テスト観点
テストの関心ごとを列挙したもの
・テスト観点の種類
テスト目的：欠陥を見つける始点
テスト対象：欠陥を持ってるもの・ところ
・テストフレーム
基本的に、テスト目的とテスト対象が結びついたものをさす
テスト目的しかないもの、あるいはテスト対象しかないものも認める
・テストバスケット
複数のテストフレームを 何らかの視点でグルーピングしたもの
・テストタイプ
同じテスト目的をまとめたもの
・テストレベル
同じテスト対象をまとめたもの（順序関係を持つ）
テストの対象をある目的をもってどうテストするかを考えて、
それをグルーピングして整理したものをアーキテクチャと呼ぶのかな？
と理解。
◆テストアーキテクチャで目指すもの
テスト設計の構造を表す
一目で見渡せる
目的・観点・使用場面が異なれば複数の絵になる
記表は問わない
抽象的にとらえたときにどうかと言うこと
テストの全体像をなのかな？
たしかにこういうテストするコトガラを分かりやすく抽象的に整理あいたものがあると、
テストケースを作成する人、テストの対象を作る人、テストを実行する人たちで、
どのようにテストをするか、共通認識できるようになる気がしますね。
◆良いアーキテクチャ
○分かりやすい
○抜け画内
○構造・形が見える
×たんなる一覧表ではない
×最初からテスト実装を並べていくのもアーキテクチャではない
○意思、関心ごとでまとまっている
○どうやってテストするか、ではなく、何をテストするか
○目的と対象とが明確になっている
○俯瞰性と網羅性を併せ持つ
ふむふむ、この辺を意識すると良い感じのテストアーキテクチャが出来そう。
でも、結局何をやるのだ？
とまだモヤッと。
【テストアーキテクチャ設計】
どうやって（How）テストするか
・テスト全体の要素と構造を明らかにする
・テスト要求分析のアウトプット、すなわちテスト観点（テストすべきこと）を、網羅・俯瞰できる構造を作るアクティビティ
・テストのしやすさを考慮して要素の関係を最適にする
・テストの観点を体系化することはテスト手段を導くことに密接に関わっていることと、テストアーキテクチャ設計をするなかでテストすべき観点を発見することもあるため、厳密な意味でのWhat-Howの関係と言うよりもWhatとHowがオーバーラップしているイメージでとらえた方が良い
なにをテストするかを分析して、それをモトにどうやってテストするか、
を考えると良いのかな。
網羅と俯瞰とテストのしやすさがキーワードっぽい。
アーキテクチャを最初に考えたら、アーキテクチャはそれで終わりではなくて、
さらにそれを基にした作業で新たな観点などが出てきたら反映するということか。
行ったり来たりするんだな。
なるほど。
これらの成果物を競うというのが「テスト設計コンテスト」
ちなみにコンテストのInputはコレ（テストベース）。
スケジュールはこんな感じ。
7月 参加受付
8月 テスト設計コンテストチュートリアル
9月 成果物の締め切り（？）←不明
10月 テスト設計コンテスト北海道予選（JaSST Hokkaido）
3月 テスト設計コンテスト本戦（JaSST Tokyo）
まずは、地方予選の突破をめざすぞ～
＃今年は参加登録が終わりましたが、興味がもった方はぜひ次年度トライしましょう！！
【参照サイト】
・テスト設計コンテスト公式サイト テスト設計コンテスト'14
・テスト設計コンテスト'14 審査基準
～JaSST'12 Tokyoの資料～
・智美塾オープニング
・テスト要求分析の概念
・テストアーキテクチャ設計の概念
・テストバスケット間の構造f
・テストアーキテクチャの考慮点
・テストアーキテクチャの具体例