Author Archives: KazuCocoa

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

Agile UI/UX

アジャイルユーザビリティを読んでみました。 UIはUXの表層のことをさすだけなので、UXって実は開発含めすべてを考えた上で設計していかなければいけない内容なのですよね。そして、今の速いビジネススピードに競っていくにはAgileやLeanであることも大事。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

QuickCheck on RSpec

CIで何回も回すから味の出てくるテストケースを考えてみる にも書いたように、同値に区分されるテストデータの集合に対してテストを実施する場合、ランダムな値でテストデータのバリエーションを増やすことは現実的な選択肢としてありと思う。また、全網羅が難しいテスト対象の領域に対してこのようにランダムな値を適用することは現実的な選択肢になる。 ※ランダム性は議論の範囲外 ここでは、以前から知られているQuickCheckを以下でRubyのコードを使ってためしていく。 また、先日書いた RSpecによるテストコードでパラメタライズドテストを記述していく と少し比較もしてみる。More

RSpecによるテストコードでパラメタライズドテストを記述していく

以前、FitNesseなどによるSpecification By Exampleで少し示した keyword driven testingは、入力値とその操作まで変数としてテストコードに与えることができていました。 このような形式で記述するテストは、「テストしたい対象のメソッドの入力とその期待値が異なる組み合わでいくつも存在するが、それらのテストを可読性の高い状態、簡潔な表現で保ちたい」というような場合に使えます。実際、開発速度が速い場合、仕様書を別ドキュメントとして厚く保つことは難しいと思います。その対策として、可読性の高いテストで低レベル（メソッドの入出力レベル）のテストはテストを仕様書に見立てていく、というアプローチが重要な一手となります。 以下は、パラメタライズドテストと呼ばれます。rspec-parameterized’というgemを使ってます。More