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のスマートフォンアプリ開発

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

みなさまこんにちは!!テストチームとのの(@tonono2587)です。
タイトルのとおり、2/24(土)にテスコン決勝戦聴講してきました!! レポートしつつ振り返りたいと思いますので、おつきあいください。

f:id:glpgsinc:20180226202714p:plain:w300

そもそも「テスコン」って?

テスト大好きなみなさんには説明不要かもしれませんね。
テストがまだ好きではないそこのあなた、テスコンとは簡単にいうとソフトウェアテスト界のオリンピックです。(あえてそういっておきます!)
(4年ではなく)1年に1回、日頃磨き上げられたテスト設計の技を競い合うものです。
プロテスト現役の方はもちろん、普段テストに興味がなくても、中継生放送なんかされてしまったあかつきにはみんなテレビの前に大集合のイベントなんですよ!(あえていう)
……残念ながら生放送はされておりませんので、僭越ながらわたくしが現地で観戦してきた模様をお伝えできればと思います。

テスコン概要

テスト設計コンテスト (略称:テスコン)には、U-30、OPEN の2クラスあります。
30歳までの選手のみエントリーできるU-30クラスは今年で2回目の開催となります。
コンテストの流れは以下です。

  • 共通のテストベースをもとに、テスト設計をする
  • 定められた成果物を提出
  • 予選:各地域にて成果物による書類審査およびプレゼン審査
  • 決勝:地域を勝ち抜いたチームで書類審査およびプレゼン審査 ←こんかいココ

詳しくは公式サイトをご覧ください
ASTER-テスト設計コンテスト

予選で選ばれたチームの、さらに洗練された技をプレゼンを通して観られるわけですね!!

勝戦概要

日時:2018年2月24日(土)10:30〜
場所:日本大学理工学部 駿河台校舎1号館 144教室

御茶ノ水デアツイ闘いが繰り広げラレル〜

スケジュール:
プレゼンまでに、書類審査までが終わっています

  • 開会式
  • U-30クラス 5チームのプレゼン(各チームテスト設計についてのプレゼンと、質疑応答)
  • 休憩(審査)
  • OPENクラス 5チームのプレゼン
  • 休憩(審査)
  • 結果発表/閉会式

聴講の目的

先ほど申し上げましたように、オリンピック級のイベントですから、
いまこのとき開催しているからという理由でなんとなく観たっていいと思うんですけれども、
わたしが決勝戦を聴講しようと思ったのは、ずばりテスト設計でモヤっているところがあったからです!

  • 考えた内容(設計)がうまく表現できない
  • 伝わるもっといい書き表し方があるはずだ
  • テスト分析してるけどなんか足りてないかもという不安感
  • テスト分析にはもっといい方法があるのでは?!

そんなもやもやがあって、テスコンはそれを競うんだからなにかしら解決のヒントがあるに違いない!! と思い、各チームの表現方法やテスト分析、設計のやり方を知りたくて聴講しにいきました。

ここまででテスコンがどんなものか、そのわたしにとっての見どころを整理してみました!

次回は、U-30クラスの様子を振り返ろうと思います。
果たしてわたしのもやもやは晴れるのか!?
お楽しみに!






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

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

不具合見つけようとするとき、何考えてるのか考えてみた(完)

これはGalapagos Advent Calendar 25日目の記事です。最終日です!クリスマスです!

adventar.org

こんにちは!テストチームとのの@tono2587)です!好きなケーキはイチゴショートです。
さて、こちらのシリーズは文豪さんも巻き込まれ「不具合を見つけようとするとき、何を考えているのか?」をテーマに考えてきました。

Advent Calendarはじめました - Galapagos Engineering Blog

不具合見つけようとするとき、何考えてるのか考えてみた - Galapagos Engineering Blog

不具合見つけようとするとき、何考えてるのか考えてみた 〜ほかの人はどうしているの?〜 - Galapagos Engineering Blog

今回は最終回となります!

前回までのおさらい

「好きにテストしてみて」と言われたら、何から手をつければよいのだろう?
→やってみたところ、どうやら保証型の網羅的なテストからはじめて、だんだん見るところがピンポイントになってゆくだろうとわかった
→チームメンバーにも試してもらったところ、同じようにおかしくないことを確認してから、不具合を探しにいくだろうとのことだった。

おかしくないことを確認(保証型)

前回までのとおり、まずはおかしくないことを確認する、というのが共通のキーワードとして挙げられそうです。
「保証型」という単語を用いましたが、このソースはテスト設計コンテストのチュートリアルからでした。
f:id:glpgsinc:20171222183945p:plainASTER-テスト設計コンテスト'18-U30 クラス チュートリアル資料からの抜粋です。

残念ながらテスコンには出場できなかったのですが、このときのお話はためになることが多くてたびたび思い出します。
資料にもあるとおり、保証型と検出型、2種類を適切に組み合わせてつかうことが基本的なテストの方針となります。
やってみてわかったことは、基本方針に則ってテストをしようとしていた、ということです。
時と場合とによることはもちろんだと思いますが、今回のような「好きにテストする」場合、わたしが思うに「やばいところがはっきりしていない」場合は、
まずは漏れなくテストして、おかしくない確認から手を付けるのは効果的なのではないでしょうか。

じゃあ検出型は?

上記のように保証型のテストをしていて、何か起きればそこが「やばいところ」、「あやしいところ」であるとは言えそうです。
ならやるところがなくなるまで端からひたすらテストしていけばテスト終わり!
……とならないことはテストの原則からも明らかですよね
しかし、網にかかるまで待つだけというのも効率はよくなさそうです。 f:id:glpgsinc:20171222191653p:plain:w300

そこでこちらから攻めるためにはどうしたらよいのでしょうか。
ここでとののは、先人たちがすでに武器を用意してくれていることに気がつくわけです…!

  • テスト技法でさがす
  • バグ分析してさがす
  • 品質特性からさがす
  • ガイドワード:意地悪漢字などを用いてさがす
  • 経験からさがす

などなどなど…
この挙げ方に語弊があるかもしれませんが、わたしとしてはピンポイントで不具合を見つけようとする活動として、上記のようなものがさまざまあるというイメージがあります。

そこで

とののはまだまだ経験が足りないので、そのようなテスト活動について勉強していくことで、基礎を固めていくのだ
勉強のしどころが整理されたところで、このシリーズの着地点として勘弁していただきたいと思います。。

まとめ

正直に言うと、好きにテストしたらその人なりの「やばそうに思うところ」、つまり不具合の見つかりやすいポイントがバンバン出てくると思っていました。
それをまとめれば、テスト初心者でも不具合を見つけやすくなるのでは?と考えていました。
実際には、不具合を見つけやすいポイントをみる=不具合が多く見つかる、とは言えず、ポイントを探すことと、見つかったポイントでそこを潰していくことの組み合わせだったのだな、それが基本なのだな、とわかりました。
基本がわかったところで、自分の足りないところ、難しいところを集中強化すればレベルアップしていけるのかな、と思います。
レベリングがんばります。

おわりに

アドベントカレンダー最終日ということで、無事クリスマスを迎えることができました!
ガラパゴスブログ初登場のメンバーもいて、わいわい楽しかったです。
記事を読んでくださったみなさまにもお楽しみいただけていればうれしいです!!
今年もお世話になりました、来年もガラパゴスをよろしくお願いいたします。
ハッピークリスマ〜〜ス(^o^)

参考

ASTER-テスト設計コンテスト'18-U30 クラス チュートリアル

http://www.kokuchpro.com/event/tdc2018_Tuto_TKY/