Galapagos Tech Blog

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

テスコン(テスト設計コンテスト)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/

API Blueprintで仕様書を作ってみた

これはGalapagos Advent Calendar 22日目の記事です。

こんにちは。ガラパゴスのイバンです。

今回開発している案件ではAPI仕様書の作成を担当しております。 弊社でWeb APIまで実装する場合は大体grape-swaggerのgemで自動生成させますが、 今回はお客さん側で実装されますので仕様書のみが作れるツールがないかを調べてみました。

swaggerで作ることも可能ですが、JSONYAMLを手で書くのはあんまり気が乗らなくて他にないか もうちょっと調べてみました。

理想的には下記の要素が対応しているツールが良い

  • インプットはmarkdown形式
  • アウトプットはhtml形式

同時にモックサーバの検討もしてました。この案件は前からmockable.ioを利用されてましたが、ユーザ数やエンドポイント数の制限があって、他に良いサービスかツールがないかを調べてましたところで、api-mockというnode.jsサーバを見つけました。 残念ながらもうメンテされてない状態ですが、気になったのはAPI仕様書からモックサーバを作るツールであって、その仕様書はAPI Blueprintで書けばapi-mockがそれ読み込んでサーバを立ててくれます。

つまり、API Blueprintで仕様書を書けば、モックまでできてしまう。一石二鳥ですね。

早速API Blueprintのサイトを確認すると嬉しい驚きがありました。

API Blueprint

API BlueprintはAPIの記述ができるMarkdownベースの言語です。

# GET /message
+ Response 200 (text/plain)

        Hello World!

上記のサンプルは/messageをGETで取得すると"Hello World!"がテキストとして返すという仕様になります。

api-mockにblueprintを渡せば、モックサーバが立ち上がって、ブラウザでモックサーバのアドレスを開くとHello World!というテキストが表示されます。

もちろんjsonを返すことを示すのも可能です。

+ Response 200 (application/json)

        [
            {
                "question": "Favourite programming language?",
                "published_at": "2014-11-11T08:40:51.620Z",
                "url": "/questions/1",
                "choices": [
                    {
                        "choice": "Swift",
                        "url": "/questions/1/choices/1",
                        "votes": 2048
                    }, {
                        "choice": "Python",
                        "url": "/questions/1/choices/2",
                        "votes": 1024
                    }, {
                        "choice": "Objective-C",
                        "url": "/questions/1/choices/3",
                        "votes": 512
                    }, {
                        "choice": "Ruby",
                        "url": "/questions/1/choices/4",
                        "votes": 256
                    }
                ]
            }
        ]

上記の例ではjson自体を書きましたが、もう一つの書き方はデータ記述です。その場合はMSONを使ってこうなります。

### List All Questions [GET]
+ Response 200 (application/json)

    + Attributes (array[Question])

## Data Structures

### Question
+ question: Favourite programming language? (required)
+ published_at: `2014-11-11T08:40:51.620Z` (required)
+ url: /questions/1 (required)
+ choices (array[Choice], required)

### Choice
+ choice: Javascript (required)
+ url: /questions/1/choices/1 (required)
+ votes: 2048 (number, required)

jsonはどこへ行った?こっちの方がわかりにくいのでは?ってなるかもしれませんが、説明してないことがあります。A PI Blueprintにはモックサーバ以外、色々なツールがあります。幸いにHTMLレンダラーもありまして、ようやく欲しかったもの全部揃えました。使っているのはAglioというNode.jsライブラリ兼コマンドライン・インターフェースです。

AglioにBlueprintファイルを渡すとhtmlを作成してくれます。しかも、サンプルデータがちゃんとJSONになっていて、しかもJSONスキームも出してくれます。

HTML出力のサンプルはここから見れます

"Show"のリンクを押すと、リクエストとリスポンスのヘッダー、ボディー、スキームが見れます。

素晴らしいですね。

感想

API BlueprintはMarkdownで書かれますのでgithubなどのバージョン管理システムにアップしてチームで編集できてとても良いです。

関連ツールは充実してて簡単にスタブやhtml作成ができちゃいます。

マイナスなポイントは多分、MarkdownなのでBlueprintの規約的にはどこはキーワードか、どこは自分で自由に書けるか、わかりにくいところがあります。

簡単な紹介になりますが、参考になりましたでしょうか。今後も機会あればAPI Blueprintで仕様書を作成したいと思います。

参照

API仕様書フレームワーク

API Blueprintツール

その他