Author Archives: KazuCocoa

テストレベル in Google

多くの伝統的なソフトウェアテストでは通常、単体テスト、結合テスト、シスムテストなどによりテストレベルを区分しているかと思います。 一方で、自社の開発スタイルがLEANやAgileのように伝統的なV字型に適合しない場合も多いかと思います。（私が現在勤めているところでは、伝統的な開発スタイルが合していないように。）そのような場合にも関わらず、V字型の時のテストレベルを使い続けると、開発スタイルとテストの間に溝がうまれてくることでしょう。おそらく明らかに。 その中でも、やはりスピードのある開発を継続していくためには、開発者への負荷を高めないながらも、サービスとして不具合というようなリスクを抑えた開発を継続できるよう、テストレベルを区分して、組織として妥当な開発を行うことができる必要があると考えます。Agile開発でいう、開発とテストの結合ですかね。 少し今更感もありますが、Googleにおけるテストレベルに該当する箇所を振り返ってみることにします。More

Selenium3のCapablityのDraftにappiumが出てきましたね

Appiumの0.17.3がリリースされてましたね。 あと、Selenium 3のspec draftにて、capabilityにappiumなどが追加されてきましたね。 https://code.google.com/p/selenium/source/browse/spec-draft.md?repo=mobile ======= Desired Capabilities ——————– New desired capability keys: * `automationName`: specific automation tool, e.g., `appium`, `ios-driver`, `selendroid` * `platformName`: platform to automate, e.g., `Android`, `iOS` * `platformVersion`: platform version e.g., `4.3` (for Android) or `6.1` (for iOS) * `deviceName`: specific device names including version information, e.g., `Nexus 4`, `iPhone 4S`,…More

Testing Cloud Services: How to Test SaaS, PaaS & IaaS (Rocky Nook Computing)を呼んでみて

Testing Cloud Services: How to Test SaaS, PaaS & IaaS (Rocky Nook Computing) を呼んでみて Cloud Serviceに対するテストとして、米国Amazonにて上位に入っていた本をざっと呼んでみた。 内容は、NISTによるCloud Computingの定義と、その上でのリスクドベーステストを行うためのリスクの洗い出し、さらにはそれらの指標の計測に言及したり、テストベースを作成する所までの話しがまとまってて、リファレンスとして使えそうでした。More

Pull Requestにドメイン知識を載せること

最近、レビューの話でいろいろ盛り上がってましたが、あわせて考えてみた。 主にはLEANやAgileを重視している、サービス業を展開している開発現場の話しです。 また、以下ではPull Requestベースの話です。 いきなり本題ですが、技術的な実装に対するレビューのためのPull requestに関しても、User Storyを書き、そのStoryの何を行うための実装かをまとめることって、必要なんでないかなと。 ここには利点がいくつかあると思っていて、More

Appiumの不安定なところいくつか

Appium 0.16.0 がリリースされましたね！ さて、iOS/Androidともに動作確認しているのですが、いくつか出くわした現段階の不具合を備忘録かねて共有です。More

受け入れてテスト自動化に向けて

も少しいろいろ考えてみたけれど、受け入れテストを実際に書く場合、 1. Turnip部（.feature, .step）には主要ストーリ、変更の少ない箇所を記述する。featureの記述者の想定はユーザストーリーを描く人ら。 2. RSpec部で、より細かな確認事項を書く とするのはどうかなと思い始めた。 というのも、保守観点を意識すると、RSpecのほうがエンジニアは保守しやすいのではないかなと。 私自身、RSpecのほうが気軽にかけましたし。More

受け入れ試験レベルの抽象度のシナリオを、Appium x “RSpec or Turnip”で比較してみた

最近、スマホアプリの受け入れテストの機能的側面を自動化する場合、どのような手段が妥当なのか？ということを考える。 それを、Appiumを基本に、RSpecとTurnipの2つを中心に比較して考えてみる。 どちらを選択したら良いのかなということに対して結論からいうと、何がよいのかという判断自体は – 誰が受け入れ試験のシナリオを記述するか – 誰が自動化コードをメンテするか – どのような開発スタイルか に大きく依存しますかね。More

「サイトパフォーマンスのインパクト」を読んで

LEAN START UPのMeasureを行うために何を品質をとらえればよいのかを日々考えているのですが、今回は以下のワザノバの記事から少し考えてみました。 サイトパフォーマンスのインパクト サイトパフォーマンスがプロダクトにどのような影響を与えるかは色々な資料で見たのですが、数字が頭には残ってなかったので、EtsyのLara Swansonがこちらのブログで事例をまとめてくれていて助かります。 ページの読込みに3秒かかれば、40%のユーザが離脱する。 Amazonによると、ページの読込み時間が100 ms増えると、売上が1%落ちる。 Googleは、検索結果の表示数を増やして、ページの読込み時間が0.5秒増加すると、売上とトラフィックが20%低下した。 Akamaiによると、75%のオンライン購入者は、フリーズ / クラッシュ / ページ読込みが長過ぎる / 購入フローが複雑という経験をするとそのサイトでは購入しない。 Googleでは、Google Mapsのサイズを100KBから80KBに削減したら、ユーザの再訪率が改善した。 Etsyではモバイルページに160KBの画像を追加すると、12%の端末で直帰率が増えてしまった。 DoubleClickでは、クライアント側でのリダイレクトを1箇所取り止めると、モバイル端末でのCTRが12%改善した。 Amazonが画像ファイルを圧縮JPEGファイルに変更すると、モバイル端末でのバッテリー消費が20%減り、Facebookの場合は30%削減できるという研究結果もある。More