Galapagos Tech Blog

株式会社ガラパゴスのメンバーによる技術ブログです。

(続) テスコン(テスト設計コンテスト)2018 決勝戦いってきた

みなさまこんにちは!!テストチームとのの(@tonono2587)です。
先日テスコン決勝戦にいってきました!
テスコンとは?を整理した 前回 に引き続き今回はU-30クラスの模様をお伝えできればと思います。

gtech.hatenablog.com

U-30クラス 参加チーム

参加チームは5チームでした。(発表順)

  1. あんだーズ
  2. チームT研
  3. 新米
  4. T.B.D
  5. いんプレオ

審査後、結果発表より前の休憩時間に審査員から各チームへフィードバックの時間があったのですが、
これがめちゃくちゃおもしろかったです。
うっかりしていたらはじまっていたので途中からしか聞けませんでした。。(とても残念)
わたしが聞いたなかでは、以下のようなフィードバックがありました。

あんだーず

  • どういう情報がほしくて、このインプットを選んでいるのかが足りない
  • そのためコンセプトを実現しようとしている感がなくてモヤる
  • おそらくあたまの中で変換があった。そこが成果物にでていない
  • 意図が表現できてないかも?
  • ISO25010出してるけど、コンセプトで触れていた「品質」を定義しているわけではない。。
  • 「なぜこれが必要なのか」の説明は一生懸命やってたからとてもよかった

T研

  • 「一意に定まる」というのはどう評価すればよかったのでしょう?? →そもそも一意に定まらない、難しい。。
  • 曖昧なもの(ここでは要求定義書?)をボールペン入れたからって一意に定めるのは難しい
  • 状態遷移図に力を入れていたのがよくわかったけど、質があんまりよくなかった
  • 例えばUMLドメインモデルを書くと状態がわかると思う。そうすると状態遷移図が書きやすくなる
  • 次は状態遷移「表」もかけるようになるのかな
  • 状態遷移ではカバーしきれないので、状態遷移図で網羅できないところを考えたら、テストの全体像がみえたのでは?

いんプレオ

  • 「やったことリスト」ではいけない(足りない)
  • 書いてないことをどうがんばってテストするか
  • ティラミスはエンプラむけ?なので組み込みでつかうの難しいのでは?
  • ラルフチャートのほうがつかいやすいかも
  • 成果物が読み解きづらかった

よかったところは?悪かったところは?ここが難しかった、どうすればよかったか、などなど、成果物を囲みながら発表者からの質問に審査員が口頭で答える、という形式でした。
審査員の方々はだめなところをきっぱりはっきり隠さず指摘してくれるのですが、 発表者側もまわりで聞いている参加者もとても前向きな空気でした。 もちろん、よかったところもはっきり言ってくれていました。(^^)
めちゃくちゃ真剣にフィードバックをくれるので横で聞いていてすごい羨ましかったです。
わたしは普段の業務でちゃんとフィードバックをもらえていると思っていましたが、こんなにいろんな人に見てもらえる機会はあんまりないのではないでしょうか!いいな!!

結果

U-30の結果はこうなりました〜

【優勝】T.B.D 【準優勝】新米

おめでとうございます!

ASTER-テスト設計コンテスト'18-U-30クラス 決勝戦

講評

  • 「どうつくったか」などいろいろ考えている様子がある
  • ただ、「Why」の部分が薄い
  • いいこと考えてるのに伝わらない
  • 技術要素を扱い切れていない、理解していないように思える →腹落ちさせてからつかいましょう
  • コンセプトとやろうとしていることがちぐはぐになっています。 (風呂敷を広げすぎてたためてないとか)
  • 全体の一貫性をもったドキュメントとプロセスがほしい
  • いいテストケースをつくりたいから設計するのに、その最終的なアウトプット(テストケース)がちょっと残念になってしまっている
  • 経験が少ないぶん、poorなテスト観点になってしまうかもしれない。それでもきちんと考慮された結果として成果物を出さなけれればならない
  • そこをがんばる!

総評

  • 前回と比べて格段にレベルアップしている!!

【一貫性、全体をみる姿勢】

  • 成果物全体をみる妥当性の視点が必要
  • (温泉旅館みたいな)継ぎ足しで拡張したようなものが多い
  • ちぐはぐしていて全体がひとつにまとまっていない
  • 市場調査や要求分析はしている
  • アーキテクチャはしっかりしているがテストケースが不足している
  • 上流と下流で矛盾がある
  • 最後に全体をみて、違和感があればなおすことが必要
  • 確認の時間を最後にレビューの工程をもつとよいと思います

【習慣的に技術を高めてほしい】

  • 技術の基礎不足
  • 使っているアピールはあるが使えてない
  • ファッション的に技法の名前を上げてもバレます!笑(HAYST法難しいですよね)
  • 日頃からつかえば使えるようになる
  • テスト技法は、日頃から実践して身につけるものだと思います(例えばドラクエのように、鍛えたらレベルアップできる!)
  • テスト技術をガンガンつかっていきましょう!!
  • OPENでもいける!頑張っていきましょう!

f:id:glpgsinc:20180227181625p:plain:w300

感想

テスト分析のところでは「三色ボールペン法」がかなり使われていました。
それほど難しくないし、効果的な手なのかなと思いました。
仕様に対して、「気になる」といえるように、ここでいうとペンを入れられるように、いま社内で少しずつトレーニングしてみているので、
やっていることは間違いじゃなさそうだと安心しました(^^)

講評、総評であったように、テスト設計全体をとおして「一貫性をもたせる」ことがわたしの実務においてもヒントになりそうです。
「伝わること」は、論理的であるとそれに近くなるのでは、と思いました。
プレゼンをきいていて、「ちぐはぐな感じ」が理解できたことは、昨年の聴講から成長できたところではないかなと自分で思います!!(^o^)/

話がわかってきたところで、レベリングはまだまだです。。
身近な技から身につけるのが早そうということもわかりましたが、スマホアプリのテストにおける身近な技ってどのへんからだろう…??
テスト界の技マップみたいのあるんですかね?ひとつ技を身につけたところで(ククク…奴はテスト技法四天王の中でも最弱…) みたいのやりたくありません?(え?)

次回予告

ここまでU-30クラスを振り返りました。
フィードバックはほんとに他のチームのもききたかった。。
OPENクラスでも、おもしろいお話ありましたよ〜!
次回へつづきます(^o^)/






ガラパゴスからのお知らせ〜
ガラパゴスでは、ただいまサーバーサイドエンジニア、Androidアプリエンジニアを募集しております。
詳しくは公式HPをご覧ください。

APP ENGINEER | 株式会社ガラパゴス iPhone/iPad/Androidのスマートフォンアプリ開発