みなさまこんにちは！！テストチームとのの(@tonono2587）です。
前回 、 前々回 に引き続き、完結編としてOPENクラスの振り返りをしていきます！！
OPENクラス 参加チーム
OPENクラスも5チームでの闘いでした。（発表順）
- タニタガワー6
- 紙印テスト倶楽部
- イイてすと
- ふわパン
- てすにゃんV3
個人的にはタニタガワー6のプレゼンききやすくて好きでした。
ふわパンさんのチーム名の由来聞きました？（チームメンバーの体型が）ふわふわ＋パンダ って言ってましたよ？！めちゃくちゃかわいい！！！！！（好き！！）
結果
内容が入ってこなくてすみません。結果は以下です。
【優勝】てすにゃんV3 【準優勝】ふわパン
おめでとうございます！
ASTER-テスト設計コンテスト'18-OPENクラス 決勝戦
講評/総評でどんな感じだったのか振り返ります。
講評
【タニタガワー6】
- USAを提唱
- 「かっこいい」と自分たちで言っていた
- シンプルでわかりやすいと思います。
- なぜ4つでいいのか、なぜそれがでてきたのか、を詰めていくとよいのでは
【紙印テスト倶楽部】
- テストの取り組みは受け身になりがちだが、今回の発表は能動的にテストから仕掛けていく取り組みが内包されていてよかった
- いままでの経験を積み重ねている
最多出場で
必ず*1決勝に残っている（すごい）継続する力がすごいし、しかも毎年新しいことを仕掛けている
- アウトプットするし、たくさんの人に知らせている姿勢◯
- そのフィードバックを次につなげる循環がよい◯
【イイてすと】
- 特別枠だった、予選からレベルアップしていた
業務フロー業務分析*2につかったりするものをテストにつかう- 「見える化する」ことが大事
- あれ自体が業務フローをあらわすものなので、それをテストに適応させていきたい
- 質疑応答タイムで言っていた「テストに適用できると証明したい！」という熱い思いをはじめからだしたほうがよかった
【ふわパン】
- 他チームが新しい技を出してきた中で、普通のテスト設計をしてきた
- それがちゃんとできていた
- こういうテストありだよな～と思った
- オーソドックスにテストしていて、メンバーにこういう人がいたら安心できる内容だった
- この基本は守って向上していってほしい
- ただ、「言葉」（用語）が方言っぽくなっている （テスト技法→テストタイプ、テストポイント→テスト条件、など）
- 非機能テストからやる→やっていることは王道だが表現が違った
- 可視化して説明してほしい
【てすにゃんV3】
（すみません、てすにゃんの講評ありました？聴き逃してしまいました 汗）
どんな内容だったかだけメモ載せときます
- 製品のリリースを止めるバグを許容範囲までなくす
- bugspots（よみ：バグスポッツ）を利用
- 製品のリリースを止める事象およびバグをどう特定するか
- フォルトツリーズを用いた事象の分解
- テストで対処する/しない事象はどのように決めるか →被害金額とリスク値から決める
- 対処するためにどんなテストをどのくらいやるか？ →テストタイプのリスク低減表による許容範囲の調節
にゃ～
総評
- テスコンがはじまってから2、3年はテスコンの次の活動がなかった。 いまは審査員になったり、次の活動に繋がったりしている
卒業して、より広い活動、レベルの高い活動へ＞次の世代が同じように追いかけていく→全体が右肩上がりしている
審査員はフェアにみている →だれがつくったかは全く気にしないで成果物をみて、審査している
ひろくみて、いろんな関係をフラットにみて、だんだん落とし込む王道をいったのがふわパン
- それは関係をモデリングして、落とし込んでいって…→これは難しいこと
- 他4チームは何かほかの考え方に寄せている→こうすれば考えるのが楽になるのでは？
- 考え方の違いなのでどっちがいいとかはない
- （例えば円柱があったとして、）円をモデリング＞長方形をモデリング＞… 全部捉えようとしてしまったら扱いきれなくなってしまう
- トレードオフですね
- ほとんどのチームが何かに寄せて安心してしまったので点数が拮抗していた
全部捉えようとしてしまったらほうは、扱いきれなくなってしまっていた感じ
表せるものはなにで表せないものは何で、を理解した上でケースに落とし込む →その理解をどっち側からやるかが問題
模範解答はない
正解はない。100点の成果物はつくりようがない
業務だと納期があり、深く深く考えるには限界がある
- 一方テスコンは仕事の納期に比べれば考え抜く余裕がある
- 考え抜いたものを見せてください！
テストとは何か考えたり
プレゼンがみんな似ているのでおもしろくない〜
- 独自のプレゼンテーション がみたい！
- 型ができて「型通りやると決勝いける」みたいになってきたらつまらないよね。
感想
- 「USA」について、ユーザーストーリーマッピングがベースのテストということで、どんなテストをするのかわかりやすかった気がします。
- 一方で、それで足りているかとか、安心かどうかを考えるにはプレゼン時間はあっという間すぎてついていけませんでした(´･_･`)話がわかるようになってきたらそこまで考えられるのかな。。
- 紙印テスト倶楽部の、テストを考える前に仕様（テストベース）に対してフィードバックをする方法はすごくしっくりきました。
- 「テストベースをテスト設計成果物へ変換する」ところで、いま知識が足りなかったりもやったりしているような気がする
- bugspots、知らなかったのでぐぐりました
SHANON Engineer's Blog: Google のバグ予測アルゴリズムと bugspots の導入
- コードに手を加えられているところほどあやしい、からそこを狙え、ということでしょうか？
- ぐーぐる先生が言うなら信用できる！みたいなイメージをもちました
- 正解がないぶん考えたなりに自信をもって「こうやって正解出しました！」と言えないと大人はうんと言わないですよね。がんばりどころのヒントになりそうです。
もやもや晴れた？
前々回で整理した、わたしのもやもやは。。
- 考えた内容（設計）がうまく表現できない
- 伝わるもっといい書き表し方があるはずだ
- テスト分析してるけどなんか足りてないかもという不安感
- テスト分析にはもっといい方法があるのでは？！
→聴講を通してヒントはあったように思います！
- 全体を捉えるような視点で振り返るとよさそう
- 何かに寄せて考えてみたり、全体から落とし込んでいったり、やり方がいろいろある
- レベリング
昨年決勝戦にきたときは、正直ほとんど話についていけず、成果物の展示をみても 「字がいっぱい〜。。。」くらいにしか思えませんでした。
※ただモチベーションはものすごくあがった
今回も「字がいっぱい〜。。。」とは思いましたが（おいー）、
なんの話をしているかはわかるようになったなと思いました。
とくにU-30での発表内容やフィードバックは、自分に置き換えてみていくと実務に適用できそうなところがありました。 来年はもっと話のスピード感についていけるようになりたいです。
さいごに
参加者のみなさんお疲れさまでした！
このレポートをとおして観戦してくれたみなさまも、おつきあいありがとうございました。
テスト界ではテスコンのようないろんなイベントがありますので、どこかでまたお会いできたらうれしいです！とののでした。(^_^)/~
〜ガラパゴスからのお知らせ〜
ガラパゴスでは、ただいまサーバーサイドエンジニア、Androidアプリエンジニアを募集しております。
詳しくは公式HPをご覧ください。
SERVER ENGINEER | 株式会社ガラパゴス iPhone/iPad/Androidのスマートフォンアプリ開発
