こんにちは！テストチームとのの（TW:@tono2587）です。
今回は2/23に参加した「テスト設計コンテスト」のことを書きます。
時間は経ってしまいましたが、初めてのテスコンだったので張り切ってレポートします！
・テスト設計コンテストとは？
・決勝戦概要
・U-30クラス
・OPENクラス
・全体講評メモ
・感想など
テスト設計コンテストとは？
名前だけは聞いたことがあったのですが、いったいどんなコンテストなのかは知りませんでした。一緒におさらいしましょう！
簡単に言うと、「テスト設計のスキルを競い合うことで、さらに高めていきましょう！という会」な認識です。
公式サイト：http://aster.or.jp/business/contest.html
「OPENクラス（だれでも）」と「U-30クラス（30歳以下のみ）」の2つのクラスにわかれており、それぞれで予選がおこなわれた上での決勝戦となります。
わたしはチュートリアルは参加せず（知らなかった…）、この決勝戦のみ聴講で参加しました。
今回のテストベース
U-30クラス：「話題沸騰ポット」
OPENクラス：カラオケシステム
テストベース仕様、採点基準についてはコチラから↓
http://aster.or.jp/business/contest/rulebooku30.html
http://aster.or.jp/business/contest/rulebook.html
決勝戦概要
◇日時
2017年2月23日（木）
10:00 U-30クラス決勝戦開始
12:30～13:30 昼休み
14:40 OPENクラス決勝戦開始
18:10 終了
◇参加チーム(発表順)
| U-30クラス | OPENクラス |
|---|---|
| OPTiM | てすにゃんRev2 |
| いんプレオ | 紙印テスト倶楽部 |
| ヤングレッジ | STUDIO IBURI |
| でこパン462 | モモテツ |
| チームT研 | わんだーズ |
| SHINNOSUKE | |
| TBD |
☆持ち時間は発表15分→質疑応答5分の計20分
U-30クラス
優勝 でこパン462 準優勝 SHINNOSUKE
総評メモ
井芹洋輝さん（審査委員長）より
入賞チームについて
でこぱん462
テスト要求分析の発散と収束が上手だった（まとめが上手かった）
3つの目的でビューを分けてやっていたところがよかった
テストの手法を理解してつかっていたSHINNOSUKE
わかりやすかった
よく内容をみるとあれ？ってところがある
アーキテクチャを2つつくって片方を採用したところがおもしろいが、根拠が少ないTBD(準優勝惜しかった)
テスト要求分析でいろんな分析をやっている
新しい技術にチャレンジしているのがよいが、なぜその手法なのか、どうつながっているのか、それがみえず説得力に欠ける
技法、手法をつかうなら理解していることも証明できるとよい
U-30クラス全体について
テスト開発プロセスの基礎ができていない
技術力不足
チュートリアルで設計について説明があったけど、それを満たしていない
手法の使い所がおかしい、正しくない竜頭蛇尾
分析がテストケースにまで落ちていない
テスト設計は、「テスト」が成果物であり、本質。
「テスト」をよくすることが一番で、そのためにやっている。テストの厚みの分析が足りない
根拠の分析が弱い。
「なにを」テストするかはできているが「どこまで」テストするかが足りない
上記の改善について
品質 についてよく考えて下さい。理解してください。
ポットに対してテストが仕様書どおりではそもそもテストが足りない。
（倒れる危険があったり、子どもがつかう、という前提がある。）「よいテスト」について考えてください
保守性の高いテスト、マネジメントが高いテスト、等
テストの内部品質を工夫しましょう各「技」はしっかり身につけてください
技ばかりにこだわってはいけない。それをつかってこそ
OPENクラス
優勝 STUDIO IBURI 準優勝 わんだーズ
総評メモ
鈴木三紀夫さん、湯本剛さんより
- 成果物をみて
とんでもない成果物の量で圧倒しているチームもあったが、それは本当によいかどうか - アーキテクチャはいろんなビューでみなければいけない。
どう組み合わせたら品質がよくなるのか
いくつかのアーキテクチャのビューのなかで、順番のやつが簡単です
「アーキテクチャ設計」とは…をよく考える - アジャイル開発にチャレンジするなら中途半端ではなく、それについてもしっかり勉強しておかないといけない
- 「用語」をしっかりつかうこと。
一般的な使い方をしたほうがよい。発表にそれぞれ違う定義でつかわれている。この発表ではこうです、という定義がされていてもいつもと違う使い方だと誤解しそうになる
全体講評メモ
西康晴さん（審査委員長）より
- テスコンはじめの4年は主に「テスト観点」で勝負がついていた。
そこからテスト要求分析の技術がついてきて、2年くらい前からテストアーキテクチャ設計の質で勝負が決まるようになってきた。 設計方針とはなんなのか をしっかり考える
ものの設計とは何か?
車輪で走るような自転車の設計、とかはわかりやすいが、じゃあ「テスト」の設計は？？？
テストの設計は何が動くのかよくわからないからソフトウェア設計よりも難しい。
参加者みんなで技術力をアップさせていっている。テストレベル、テストタイプ などの定義は世界にもある。
それをどういう順番で並べるかを検討する方法はまだ世界にはない。
UMLテスト 2.0とかに入ってくるかもしれない
世界最先端です！今回はテストベースが「派生製品」だった
じゃあ次回は？自動化を考えたら設計の中身も変わってきたりするでしょう要求分析→アーキテクチャ設計
この流れが、過程が踏まれてない成果物がただの日記で、「理由」「意図」がない
やることが決まっていて、何も考えずにやったことを出せばOKがもらえる仕事になっているつかう用語、技術は理解してつかわなければならない
自分たちの技術にする、アイデアにする、現場の工夫をコンテストの機会で整理してください
それをフィードバックにして、自分たちの強みにする
感想など
- 同じテストベースを与えられているのに、成果物も発表も同じものはひとつもない
逆に、自分たちの立ち位置の説明→設計の流れ説明→要求分析→テスト設計の流れはだいたい共通していたので、基本的なテスト設計の流れを知ることができました。 - プレゼン（発表）も得点に入っている
設計した成果物だけではなくて、プレゼン内容が得点に影響するところがおもしろかったです。自分たちの設計したことを相手にわかるように説明することも、ときには必要なスキルなのだ思いました。 - すぐできそうなこと
「用語」や「手法」を正しく理解すること。スキルアップには基本知識を増やすことが一番はやそう - 「世界の最先端です」
総評のこの話が一番わくわくしました！最先端技術のすぐそばにいる！
学んだこと
- テスト設計の基本の流れを理解しました
- テストの成果物も設計により様々なのだと知りました
- 十分な設計をするためにテスト設計の基本知識を身につけることが近道だと教えてもらいました
- 技術を高める機会が社外にもあることを知りました
さいごに
参加者には発表者や関係者が多い印象でしたが、聴講のみでも参加できてよかったです。
参加前にもう少しテストベースについて読んでいったり、予習していけばよかったなと思いました。（そのほうがもっと話が入りやすかったかも）
総評で「世界の最先端にいるから、本とかに自分の名前のついた手法が載ったりするかもよ（意訳）」と言われたときはすごくテンションがあがりました！
勉強のし甲斐がありますよね。これからもがんばりましょうー！！！
「最先端」が大好きなぼくのはたらく会社がこちら
www.glpgs.com
