Category Archives: software test

iOS向けBDD Toolsをいくつか使ってみた

OBJC #15 TESTINGを読んでで並べられていたBDD Toolsを使ってみました。今更感あるものもありますが、そこは復習込みで、という感じで。 Swiftで書かれたものに関してはGitHubにサンプルを作りました。Objective-Cのものは確認程度。あとはXcode 6 Beta時代のTDDチュートリアルを行ってみました。Xcode6.1.1環境で私は実施したので、いろいろAPI変わってて辛かった… Objective-C時代のBDDフレームワーク Cedar Kiwi Specta Pure Swiftで開発されているフレームワーク Quick https://github.com/KazuCocoa/sampleQuickSpecs Sleipnir https://github.com/KazuCocoa/sampleSleipnirSpecs あと、ついでにBDDのチュートリアル。 https://github.com/KazuCocoa/sampleTddInSwift XCTestを使った例 サンプルを使ってみたところと、ざっと見た感じ、Quickは良さそう。Sleipnirは、最近はさっぱり開発が止まっている様子。黒魔術な気がしたSleipnirも、XCTestを使っていないという点で面白そうでした。 Onjective-Cも、知名度も合わせてKiwiを使っていたのですが、Spectaを使ったほうがよかったかもなと感じました… ただ、SpectaはQuickの開発に本腰入れている感じがするので、今からならSpectaよりもQuickのほうが良さそう。 あと、やはりモバイルアプリはコードレベルでテストを充実できるのはModel、頑張ってControlerレベルですね。Viewははやり実際に描画させないといけないので、AppiumとかCalabashとかが必要そう。More

モバイルアプリのCIサービスが増えてたのでいくつか使ってみた

iOS/AndroidのCIサービスがまた増えてきたようなので、少し触れてみました。安定性はやはり以前からあるものが良さそうですが、今年は選択肢の多様化と価格競争も進みそうですね。あとは対Enterprise向けサービスも今はTravisだけですが他の選択肢も出てきそう。 今まで触れたことのあるCI環境 Travis CI, Travis CI Enterprise Wercker CloudBees Hosted CI 新たに触ってみたもの GreenhouseCI Ship.io Circle CI 試したことは、適当なサンプルプロジェクトを、GitHubのPushなどを契機にビルドするということです。それぞれのサービスの制限(ディクス容量や、時間制限など)までは確認していません。 GreenhouseCI ビルド対象はRepository URLの直接指定で行います。Publicなものであればそのままビルドすれば良いのですが、username & passでのログインやSSHの利用が提供されているので、private repositoryも対象にすることができます。 ビルド設定すると、Cloneしてきて、Android/iOSを識別、いったんビルドを試します。その後、スキャンしたビルドオプションをプルダウン形式で選ぶことができるので、そこで次回以降実施するものを選ぶことができます。 GitHubのWebhookに所定のURLを設定したら、GitHubへのイベントをきっかけにCIを回すことができるところまでサポートされている模様。 Ship.io GitHubに接続し、リポジトリを指定してビルドを開始します。こちらはまだBeta版らしく、動作が重たいです。 重たかったので、ちゃんと試せていないです… Circle CI Android、iOS共にビルドできそうだったけれど、iOSをビルドしようとすると以下のような文言が表示されました。まだBetaなので、気長に待つことが必要そう。 Warning: Sorry! Your build didn’t run because we are still adding capacity to the iOS beta and haven’t enabled your organization yet. We know…More

WACATE 2014 冬に参加してきた

最近常々思うのですが、テストエンジニアも役割が細分化されて、役割が再定義される時代がすぐそこそうですね。開発者が、xxx(特定の言語)エンジニア、サービス開発エンジニア、インフラエンジニアなどのように区分して呼ばれるように。例えば、最近、テスト自動化エンジニアと呼ばれる人たちが出てきましたが、それもその一つだと思います。 さて、話題は変わり、12/6、12/7の2日間で開催されたWACATE 2014 冬に参加してきたのでその話をまとめます。1ヶ月くらい経ちましたが、ようやっとブログポストになります。。。Twitterにおけるハッシュタグは #wacate だそうです。 WACATEとは WACATEは「Workshop for Accelerating CApable Testing Engineers」の略で、「内に秘めた可能性を持つテストエンジニアたちを加速させるためのワークショップ」という意味です。 前々から日程が合えば参加してみたいと思っていたのですが、日程が合わず今回初参加。初参加ながらも、分科会をさせていただきました。 ここでふと疑問に思うのが、若手の定義です。こちらのCIAの資料によると、日本の平均年齢は46.1歳のようです。そこから考えると、30代までが若者といっても良さそうな範囲ですね。 なお、WACATEとはによると 35歳以下 だそうです。More

Objc #15 Testingを読んで

ワザノバの記事で知ったのですが、iOSに特化して、特定のテーマごとに発信しているブログを覗いてみました。 その中に、Testingに話題を絞って話している回があり、面白かったのでまとめてみます。 Issue #15 Testing Behavior-Driven Development What Should I Test?という問いかけから始まり、BDD DLSの話、BDDフレームワークを使いながら、BDDに関して説明している記事。以下の流れで実際にBDDフレームワークを使って、Behaviourとしてテストを記述するとこうなる、という事例を提示しています。 BDDフレームワークとその特徴を簡単に説明 機能に対するテストの記述 ただし、これはユーザから見ると何もテスト対象がどのように振る舞うのか書いていない、と指摘。 どのような要素が表示され、それをどうするとどうなる、というような記述に説明を加えながら発展 View Controllersのテストの具体例まで表示 締め 記事の中で、BDDのフレームワークとして以下を紹介。KiwiとQuickしか頭に入っていなかった… Objective-C時代のBDDフレームワークとしては以下。 Cedar Kiwi Specta Pure Swiftで開発されているフレームワーク Quick Sleipnir SleipnirはCedarに、QuickはSpectaに影響を受けているらしいです。個人的に、Sleipnirには興味が湧きました。というのも、XCTestを使っていないらしいです。実際に試して、どこまでできるのかを図らないとなんとも言えないのですが、XCTestに縛られず、どういう風にBDDとしてテストを実施するのかに興味があります。試してみよう。 Core principles • Sleipnir is not dependent of NSObject, it is pure Swift BDD testing framework • Sleipnir is not using XCTest • Sleipnir has nice…More

Mockサーバ比較とWireMockメモ

少し前から、モバイルアプリケーションに対してHermetic testと呼ばれる類のテストタイプを実施できる環境を整え始めました。その中で、JSONで記述したHTTPレスポンスを返すだけのような、簡単なMockServerを探していました。 なければ簡単なものを作ろうとも思ったのですが、結構期待していたものがあったので、メモ。 調べたもの MockServer WireMock mockwebserver OCMock あたり。他にもありましたが、ざっと見て次〜としていた。More

システムテスト自動化カンファレンス2014に参加してきました

システムテスト自動化カンファレンス2014に参加してきました。 ビルドバイプラインなどの話は日常なので、個人的にはやはりシナリオの書き方をどうすれば良いか、が興味の焦点でした。自然とテストケースを実装していると、共通化などのプログラミング的な話は誰もが行き着くでしょう。シナリオの記述と、その具体化されたコードを分離させたほうがメンテナンス性も上がることも。一方で、それらがどれだけベストプラクティスに近いかなどが不安ではあったりするので、そこらへんに興味がありました。 結果的に、ひとまず本書を読もう、となりました。CIツールなどの具体例は日常になっているので、どちらかというと第1部のところが興味の主なところ。読んだ後は、社内で伝搬できたら良いな。 以下、スライドと感想などMore

Selenium/Appium Advent Calendar 2014の2日目に投稿した

Selenium/Appium Advent Calendar 2014の2日目に投稿しました。 七転び八起きなAppiumを使ったモバイルテストのたしなみ 主にはAppiumを使ったテストを書く上で出会ったTipsなんかをつらつらと書きました。 あのようなTipsはAdventCalendarのようなところだと結構気軽にかけるから良いですね。 ソフトウェアテスト系においても宣言したので、もう1つ書く予定。More

More Agile Testingを読んで6(final)

最後間で読み切りました。ので、最後を少し。 最後はよく聞くプラクティスなので、なるほどくらいで終わる方も多いかと思いました。 ひとまずAgile More Testingも呼んだので別の本を読もう。 Agile Testing in Practive 最後のこの章では、Agile Testingのいくつかのプラクティスを書いていました。 Chapter 24. Visualize Your Testing Communicating the Importance of Testing 　　　　- かんばんを使ったテストタスクの管理を書いています。目的は進捗を把握することなので、登山のように縦方向にかんばんを管理しているものもありました。 Visualize for Continuous Improvement Vivibility into Tests and Test Results 中には、テスターは良いテストケースを用意するためにプログラマーとアナリスト両方の経験が必要とかいていました。More

More Agile Testingを読んで5

ここまでで約60%超えるくらいなのですが、Appendexなど覗くと後少しで読了。実際の経験にそっていることが多かったので、比較的頭に入ってきました。 いくつか役立つことや、考えが整理できること、同じ経験を積んでることを学べたことは個人的に良い収穫でした。 ここに直接関係するわけではないですが、Turnipのようなテスト記述の勉強会したいな。時間見つけよう。 Part6: Test Automation Agile Testingでは、テスト自動化は必須な武器です。そのため、テスト自動化に関してもある程度の幅をとって記述されていました。 Technical debt, Pyramids of Automation, Test Automation Design Pattern and Approaches, Selecting Test Automation Solutionsという構成で記載されています。 Chapter 14: Technical Debt in Testing 技術的負債はテスト自動化や他のテスト活動において、チームの速度を落とさないようにする必要があります。技術的負債を把握して様々な活動へ落とし込むために、見える化はやはり大事だと言います。 ストーリーに対する見積もりにおいて、タスクカードによりデバグ作業や自動化にかかるメンテナンスも可視化する 作り込まれた不具合やブロックされたストーリーは、素早く集中して修正する コードとテスト双方に対してチームは責任を持つ 技術的負債の課題を定め、負債を減らすようにトライする 異なる専門家を集めて、全体として負債を減らすMore

More Agile Testingを読んで4

だいぶ進んできましたが、全般的に現在の考えを後押ししたり、参考になるものが多い印象です。もう少し頑張ろう。 Part 5: Investigative Testing ここでは、様々な事象をより深堀りしていくためのTestingの側面の話しをしています。ほぼ、Exploratoty Testingの話しをしています。 Chapter 12. Exploratory Testing Exploratory tester達は、事前に定義されるテストセッションには参加しません。そのかわり、経験的に、人間的に、神のような形で期待される予測と比較しながらテストを進めます。それらの差はわかりにくいですが、非常に有意義なものと書いていました。 例えば、James Lyndsay氏はScript testingとExploratory testingを比較していたり、Bad customerを演じる形のExploratory Testingでその有意義さを示しています。 Bad customerとは、 invalid parts of imputs – characters, values, combinations Time changes Unusual uses Too much – long string, large, nnumbers, many instances stop halfway/jump in halfway wrong assumptions making lots of mistales, compounding mistakes using…More