Tag Archives: test

アジャイルソフトウェア要求を5章まで読んで

Explore it! を読んでいたのですが、勤先での立ち振る舞いから、こちらの情報を早くインプットしたくなったので・・・ アジャイル要求を5章まで読んで。 書かれていたのは、ソフトウェア開発プロセスの歴史のお話しと、LENAなAgile開発での中核となる成果物、User Storyからその達成までの全体像でした。 以下は私の理解の要所要所を。詳しくは本書をお読みください。 ※過去に紙の本買ってたのですが、携帯性からついついKindle本にも手が出てしまった・・・More

“Turnip or RSpec” x Appium

過去、こちらにて、AppiumにおけるテストシナリオをTurnipとRSpecのそれぞれの記述で比較してみました。 当時からまたいろいろ試し、考えてみた結果、ひとまずこうかな、という結論に達したのでメモがてら。More

CIで何回も回すから味の出てくるテストケースを考えてみる

テストの価値の話し。 前提として、銀の弾丸のように様々なシチュエーションに耐える話しではないことは断っておきます。 ソフトウェアテストを知っている人の場合、ランダムな値をテストのインプットとすることは良くないと考える方が多いと思います。一方で、最近ではコミットごとにCIをぐるぐる回すような開発環境も日常化してきました。その、CIをコミットごとにぐるぐる回す環境を活かし、ランダムな値をテストに取り入れ、より効率的なテストができないかとここ数ヶ月思っています。 結論から言えば、同値に区分される入力値に関して、1つのテストケースにおいてCIをまわすごとに異なる値を入力とする機構を仕込むことで、CIをまわせばまわすだけ、1つのテストケースでまわしただけの組み合わせにて入力値の確認ができる、という形です。 ここで、同値に区分されるべき値の中からランダムに要素を選ぶので、試験を失敗するということは実装を誤っているか、テスト（想定する振る舞い）を誤っているかのどちらかといえる可能性があり、それに気づくことができます。More

テストレベル in Google

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

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

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

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

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