Galapagos Engineering Blog

株式会社ガラパゴス エンジニアチームによるブログです。

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

これは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ツール

その他

ProtoPieでAppStore動かしてみた!ファイナル 第3回

Galapagos Advent Calendar 企画、21日の記事になります。

adventar.org

こんにちは。UIデザイナーのまあのんです。



ProtoPie動かしてみた!レポートラストファイナル最終回になります。
過去の記事はこちらからどうぞ! ↓

gtech.hatenablog.com

gtech.hatenablog.com


ブログって継続的に続けられた記憶がないのですが、アドベントカレンダーのように前もって日程が決まっているとやらねば!って気もちになります。素晴らしい文化です。




それではやっていきましょう。

あらためて流れを説明すると、

-動かす流れおさらい-

  • スクロールする

  • イメージをタップすると詳細ページに遷移する

  • 詳細ページに遷移する時にイメージが拡がる

  • 一覧に戻る時イメージが縮む


今回で最後まで完成させます!


Step3.イメージをタップして遷移して拡がる


f:id:glpgsinc:20171215192530g:plain:w200
この動きを、、つくりたいのです、、



結論からいうと、レスポンスの動作は下記の形になりました。それぞれ説明していきます。
f:id:glpgsinc:20171221050047p:plain:w700

①グラデーション背景、虹のイラスト
表現したい挙動:ふわっと広がって画面上部に移動
レスポンス:Scale→拡大、Move→画面上部に移動 共にEasingはEase In&Out

第二回ではグループごと動かしてみましたが、それぞれ別レイヤーに変更することで空間に奥行きを感じるようなモーションになりました。
また、Easing機能はEase In&Outをチョイス。他にも多種多様なアニメーションカーブが揃ってます↓
f:id:glpgsinc:20171221060324p:plain:w500

ProtoPie - Basics

公式サイトより。これでも一部です。カスタムできないからなのか、正直AfterEffects先輩もびっくりなラインナップ数。

マテリアルデザインのモーションデザインの原則によると、現実世界のような普段から慣れ親しんだ動きを取り入れることで、使う人が心地よく理解しやすいモーションになると考えられています。動きをつける際は一度マテリアルガイドラインに目を通しておくことをおすすめします!

Material motion - Motion - Material Design


②今日のAPP/値段/アプリ名テキスト、アプリアイコン
表現したい挙動:画面上部に移動
レスポンス:Move→画面上部に移動

③タブバー/ステータスバー
表現したい挙動:すっと消える
レスポンス:Opacity→100%から0%に変更

④テキストエリア
表現したい挙動:画像下からすっと出てきて、テキストが遅れて表示
レスポンス:Opacity→0%から100%に変更
テキストはタイムライン上でかなり後に設定しています。


一通りの動きをつけ終えました。
ここでプレビューを見てみましょう。

f:id:glpgsinc:20171221103209g:plain:w200


ヌルヌル!!!!







f:id:glpgsinc:20171221062210p:plain:w500


忘れてはいけない大切なレスポンス、Jump。


■遷移系のインタラクションでかかせない『Jump』

Jumpはシーン間の移動ができます。このJump以外のレスポンスで十分遷移されたように見せることは出来ますが、レイヤー構造が複雑で遷移先のアクションも必要な場合は一度Jumpでシーン移動することをおすすめします。ちなみにシーン移動する際はフェードインなど簡単なTransitionを追加することができます。

今回は遷移時に複雑なアクションが必要だったため、一旦このシーンで遷移後の画面を作成→それと同じ画面のシーンをJumpで差し換えてアクションを行います。




Step4.詳細画面でのアクション→一覧に戻る時にイメージが縮む



Jumpでシーン移動した後のアクションになります。 f:id:glpgsinc:20171221071536p:plain:w700

詳細画面に表示されるポップアップの動きもさくっと再現していきます。↓

f:id:glpgsinc:20171221111346g:plain

①アプリのポップアップ
表現したい挙動:スクロールして上部イメージが見えなくなると下からぽよんと現れる
トリガー:Range 対象→スクロール範囲 Property→スクロール position450(テキストエリアあたり) ≦ ScrollOffsets of スクロール
レスポンス:Move ×2→下から定位置より少し上に移動/定位置に移動 共にEasingはEase In&Out

■条件がそろうと発生するアクション、『Range』
レイヤーのプロパティが変わる際、ユーザーが設定した条件を満たした場合にレスポンスが行われます。
ポップアップの場合、スクロール内の特定の範囲のみ表示する仕組みだったため、対象をスクロールコンテナ、条件をイメージとテキストエリアの間辺りから下へスクロールすると発生する形にしました。


レスポンスではMoveを2回。軽くバウンドするような動きをつけるためタイムラインをずらしています。
ぽよんぽよんって動き、、ほんとは動かしてる時めっっちゃくちゃ楽しいから色々遊びたくなる。。けど、今回はあくまで模写修行です。我慢我慢


②アプリのポップアップ
表現したい挙動:表示されてる状態でイメージのエリアまでスクロールするとスッと消える
トリガー:Range 対象→スクロール範囲 Property→スクロール  ScrollOffsets of スクロール ≦ position260(イメージエリアあたり)
レスポンス:Opacity→100%から0%に変更


バツボタン
表現したい挙動:バツボタンをタップすると一覧画面に遷移する
トリガー:Tap 対象→バツボタン
レスポンス:Jump→シーンを最後のアクション追加用の画面に変更

最後はやっぱりJump追加です。このシーンではjumpで遷移後に縮むモーションを追加していきます。


最後のシーンに遷移してきました! f:id:glpgsinc:20171221082151p:plain:w700

ここでは詳細から一覧の画面に戻るだけなので、レスポンス的にはお馴染みのもので逆戻りしているだけです。
トリガーのStartをご説明します。
f:id:glpgsinc:20171221082920p:plain:w500

■シーン移動後自動的にうごきだす『Start』
プロトタイプが実行・またはシーンが展開された際にレスポンスが展開されます。Twitterのようなアニメーションのスプラッシュも作れちゃいます!

これをトリガーに縮むモーションを追加して、完成です!




完成、、、、

完成、、、、、、、、、、、、




ぜひ実機で、さわってみてください。↓

share.protopie.io



とはいえ、プロトタイプ



とはいえ、プロトタイプです。表現の幅に限度があるようです。

実際に触ってみるとわかるのですが、一覧画面で初期位置からズラしてタップすると、広がるはずのイメージ画像が画面の上部固定で表示されず、強制的に詳細画面に遷移するような挙動になります。ムムム。
どうやらスクロール可能なグループから複雑な遷移のアクションは指定が難しいようで、公式で配布されてるデータでは複雑な遷移のものは決まって画面固定でした。
(ひとつだけ、pagingメインでタップすると画面内の指定の場所に配置されるギャラリーを発見したものの、解読に断念)
これに苦戦しているようならいっそXcodeを体得したほうがいいのではとも、、
このこがどこまで出来て、何を苦手としているか、これからもっと探求していきます!


もし解決方法しってるよ!とがいらっしゃいましたらお気軽にメッセージお願いしますm(._.)m

とはいえ、便利



とはいえ便利です。実際にクライアントへデザインをプレゼンする際にProtoPieをつかってみたところ、
いつものプロトタイプと比べてヌルヌルしてるじゃん!すごいじゃん!といつもよりテンションが1段階あがっていました。
(提案物に対しての反応ではないので、素直に喜んでいいのか分からなかったけど)

これまでは静止画のプロトタイプ、AfterEffectsで作成した動画を流してプレゼンしていましたが、パット見のビジュアルで判断され、結果的にユーザーの使い勝手を損なう危険をはらんでいました。

思い描いた動きを短時間で作成でき、かつ実機で直接操作感をチェックできるProtopieは
デザインに大きな説得力を持たせてくれる、UIデザイナーにとって理想の具現化ツールなのかもしれません!


以上、Protopieでつくってみたレポートこれにて終了です。

adventar.org

Galapagos Advent Calendarも、のこり2記事となりました。最後までお見逃しなくです。


参考記事
https://www.protopie.io/learn/
さよなら Pixate, よろしくProtoPie – heru – Medium
【Protopieのススメ】UIデザイナーのためのインタラクションモックアップツール - Qiita