KazuCocoa

Testing and Cheking

“テスト”という言葉が多様な意味を内包していることは知っている人も多いと思います。就業中では、確認、検証という言葉を自身の身の回りでは使っているのですが、いったん整理。引用は以下のサイト Checking vs Testing Quote from http://www.satisfice.com/blog/archives/856More

Explore it !を少し読んでみた。Appendixより。

Test Heuristics Cheat Sheet from Explore it !より。本書はExampleもいろいろ記載しているので、理解を深めるときは本書をご購入ください。 Test Heuristics Cheat Sheet from Explore it ! General Heuristics Abstract: 抽象化何をする機能/システムか？に焦点を当てる Never and Always The things that the software should always do or never do. To discover the Never and Always for your system. Beginning, Middle, End Vary the position of an element. e.g. Deleteing…More

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

Explore it !をやっとこさ読み終えましたので、最後にメモ。積ん読も消費しつつある・・・アプリ作りたい。 Part3の話は、2章までの話しに対して主に肉付けを行うもの。 Explore When There Is No User interface UIの無いシステムに対して探索テストを行う。例えば、RailsだとRubyのpryやirbでシステムを起動して、引数や返り値から観察する。 Explore an Exisiting System 既存システムに対して探索的テストを行うとき、簡単な問答から行いましょう。なにをするものか？インプットは？アウトプットはどのようにして生まれる？簡単なインプットやシーケンスになる行動は？など。また、ステークホルダーに質問を行い、より明確にしていきます。テストしながら、発生したことを書き留めていき、いくつかの総合的なスキルを持って、振る舞いを観察、発見を繰り返していきましょう。エビデンスを統合していき、様々な思慮を巡らせ、タイミングを理解するために状態遷移を使い、様々なスキルを用いましょう。More

Facebookのモバイルアプリ開発におけるリリース2

1つ前の記事にFacebookのモバイルアプリ開発のYouTubeを貼付けました。少しそこからいくつか重要そうな、開発スタイルの移り変わりに関してピックアップしてみます。 ※使っている画像は、すべて動画からのスナップショットです。今まで、以下の形でWebアプリ/Mobileアプリの開発を行っていたが、スケールしない事態になった。 Webは各サービスの責任範囲で開発を行う Mobileは専用のエンジニアが開発を行うMore

Facebookのモバイルアプリ開発におけるリリース

Facebookのリリースプロセスに関する話。結構面白いです。 SOAで開発を行っている企業の場合、参考になるかも。 Hacker Way: Releasing and Optimizing Mobile Apps for the World 面白いのは、やはりWeb/Mobileとでリリースプロセスもサイクルも異なることですね。 Deployやそのロールバックの問題が小さいWebと、それらの問題が大きなアプリの差が出ている感じ。More

続・テストの種類に関して振り返ってみた、GoogleのS/M/Lもね

以下、テストタイプとGooglenS/M/Lのテストレベルに関して簡単に整理。 E2Eのテストにおける、テストタイプいくつかをざっと整理システムレベルの機能テスト基本、機能仕様にシステムの振る舞いが合致しているかを確認するテスト Story TestやScenario Testはこちら。 Mobileアプリだと、Mobileアプリから何らかの操作を行い、サーバと通信して、結果を描画する所までを1つの流れと見る。日時、株価、乱数や通信環境に依存した結果を検証することも求められるが、それは難しいので可能な限りUnit testのテストレベルでテストを実施できるようにすることが望ましい時間を止めたテストを行うなどは、システムレベルでは難しい・・・More

テストの種類に関して振り返ってみた and Web/Mobileアプリ業界の品質管理とは？

テストの種類を定義する目的問題多くの場合、テストや品質の話を誰かと行うとき、互いのテストや品質に対する認識範囲が異なるため、議論が平行線や発散することが多いそこである程度認識範囲を限定するために用語の定義を行うこれにより、テストや品質に対して事前に共通の認識範囲を持った上で話すことができるようになり、議論の発散などを防ぐまた、その範囲内で効率的な方法をとることができるようになり、他の重要なことに力を割くことができるようになるMore

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