Category Archives: software test

Appium1.0.0(Orion)とruby_libを使ってみる

Appium 1.0.0 がリリースされていましたね。Orionという名前っぽい。 これからruby_libなどのライブラリがappium側の正式サポートとして整備されていくわけですが、0.18.x系から1.0.0系はappiumとしての機能が追加されていく、と開発者の方はGithub上でちょくちょくいっています。そこで、0.18.x系と1.0.x系で変わったところの確認と、ruby_libを軽く使ってみての内容を以下に書いてみます。More

時間をテストの戦略に加える

ソフトウェアテストの話しです。 サービスが成長していくと、 テストが肥大化していく テストの実行速度が遅くなる 一部の変更が他機能へ影響を及ぼす などの問題が顕著になってくると思います。 そうなると、 複数のメソッドをまたがるメソッドの網羅性よりもmock/stubの利用により速度を向上させるためのテスト 速度よりも、メソッドの網羅性を重視するためのテスト テストの実行環境の並列化 などの取り組みが必要になってくるでしょう。 それに対して、開発者は何らかの指標を持って、何を重視するかの判断を行う必要がでてきます。（テスト戦略、のレベルの話しになるでしょうか。）More

Appiumを使ってRSpecの記述とTurnipの記述とで、結局はどちらが受け入れとして使えそうか

比較的、ぱっと見て操作を想像できることが受け入れ試験では大事だと思います。 そう考えると、RSpecはshared_exampleなんかで操作をまとめることができるのですが、Turnip/Cucumber形式のシナリオアウトラインを使った方が綺麗にかけそう。 一方、capybaraのように、RSpecの拡張としてFeature specを使うこともできる形があります。なら、Appiumを使って同様に受け入れ試験の形を模倣するならば、CapybaraのFeature specを参考に類似した記述を模倣すれば、RSpecのみである程度読みやすい受け入れ試験もかけるかもと思い、以下をまとめてみた。More

TurnipでScenario Outline

Turnip+Appiumで使ってキーワード駆動のシナリオテストが実施できそうね “Turnip or RSpec” x Appium 受け入れ試験レベルの抽象度のシナリオを、Appium x “RSpec or Turnip”で比較してみた TurnipでAppiumを使ってみる とAppiumとTurnipを使ってみたけれど、Turnipでscenario outlinesかけることが確認できたので、私の中でようやっとこの方向性が一段落しそう。 あとは、RSpecのshared_exampleの記述と少し比較してみて、という作業もいるけれど。More

Explore it !を少し読んでみた。第二章。

いきなり話がそれるのですが、Practice Sessionsがあるの良いですね。今はざっと読み進めている段階ですが、時間をとってPractice Sessionsに取り組もう。 第二章は、よく不具合が発生しやすいポイントを付け加える。 また、GUI越しの、ユーザ視点のテストとして使える方法を並べている。 Part2 Adding DimensionsMore

Agile Samurai Base Camp 2014 Re:TDDに参加した

Agile Samurai Base Camp 2014 Re:TDD に参加してみた。 このイベントは、 アジャイルサムライを読んだ人が、入門的に実際に手を動かそうとしているところ。 目的 テストエンジニアも、具体的な側面として少なからずTDDなり実践することができるべきだと思った テスト技法を用いたテストコードの改善に立ち向かうには、 書いて実践 することがやはりテストエンジニアには求められると感じた そのため、まずはTDDの基本を学ぼう、と思った。 まとめ TDDはやはり開発者を支援するための道具としての テスト TDDはコード（サービス）、チームを健康体にするための開発スタイル 仲間、大事。社内外で友達を見つけることは大事。 programmingを楽しく継続させるために、無理せず健康的にがんばろう その他 テスト駆動開発入門が絶版になっているらしい。私は既に買っていてよかった。 jasmine, groovy & spock のテストをみて、Spec系の記述が主流かなと思った。 というか、groovy & spockの不具合発生時のエラー表示は強力だなと思った。 レガシーコードはif文、for文から、独立性の比較的高いところをmethodにして書き出して、小さいところから実施していく。 弊社のような事例はやはり希有なので、いろいろ考えないとなと感じた。。。More

Explore it !を少し読んでみた。第一章。

探索的テストを学ぼうということで、Explore it ! を読んでみた。 Explore it ! まだ途中ですが、メモがてら。 この本は、主にはTester/Testengineerを対象とするが、この探索的テストはモデリングなどのソフトウェア開発の領域の知識も必要とする。そのため、テストを書くプログラマなどに対しても有効な情報のインプットとなる。 このExplore it!では、以下のような構成で話を進めている。 Establishing Foundations Adding Dimensions Putting It in ContextMore

アジャイルソフトウェア要求vol4最後

Agile手法に対するアーキテクチャーは、個々のチームから複数のチームへとAgile手法の拡大を進めていくと必要になっていく。一方で、AgileやLEANを失わずに進めていくことが課題。 基本的な原則More

アジャイルソフトウェア要求 第3部を読んで

13章以降の、第三部に属する箇所に関していくつか記載。   13章 従来のソフトウェア開発では、Product Requirement DocumentやSoftware Requirement Documentなどの要求仕様書を用意し、開発を行っていた。これらのドキュメントは重く、リーンな開発では特に、小さく始める、Just In Time、動くものをより素早くというところがあり従来のように重たいドキュメントは歓迎されない。また、リーンソフトウェア開発の原則にある「決定を送らせる」ことを実現するには、やはり従来のように重たいドキュメントは歓迎されない。 一方、AgileやLEANではビジョンを伝え、共有することが必須である。そのため、それらの共有に力を入れる。これは以下のような問いに対する回答であり、一般的に5〜10ページ程度の文章となる。 このシステムはなぜ構築しているのか？ これがどのような問題を解決するか？ どのフィーチャーと恩恵（価値）を提供するか？ 誰に対してフィーチャーと恩恵（価値）を提供するか？ どのような性能/信頼性/スケーラビリティで提供しないといけないか？ プラットフォームなどのサポートは？ ひな形は本書の付録にあるので、そちらを参考に。More