テストレベル 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

再び実践アジャイルテストを再読してみる

ご存知の方も多いかと思いますが、再度、業務とも強く結びつきが出てきましたので実践アジャイルテストを読み返そうかと思っています。 http://www.amazon.co.jp/実践アジャイルテスト-テスターとアジャイルチームのための実践ガイド-IT-Architects’Archive-ソフトウェア開発の実践/dp/4798119970/ref=sr_1_1?ie=UTF8&qid=1392105229&sr=8-1&keywords=アジャイル+テスト 開発者寄りの技術的な視点からテスト自動化や、機能追加/変更に対する移植性を高める自動化対応など進んでいますが、やはりリリーステストなどのようにそちらに寄りすぎない方が望ましい内容もあったりします。 私個人はRailsアプリやiOS/Androidアプリの開発や環境整備などの自動化スクリプトなど、開発者寄りで仕事することも多々あるのですが、基本はテストエンジニアを目指している人なので、そちらに寄りすぎない視点を持ちたいなと、最近になって再び思うのでした。More