More Agile Testingを読んで6(final)

最後間で読み切りました。ので、最後を少し。
最後はよく聞くプラクティスなので、なるほどくらいで終わる方も多いかと思いました。

ひとまずAgile More Testingも呼んだので別の本を読もう。

Agile Testing in Practive

最後のこの章では、Agile Testingのいくつかのプラクティスを書いていました。

Chapter 24. Visualize Your Testing

  • Communicating the Importance of Testing
        - かんばんを使ったテストタスクの管理を書いています。目的は進捗を把握することなので、登山のように縦方向にかんばんを管理しているものもありました。
  • Visualize for Continuous Improvement
  • Vivibility into Tests and Test Results

中には、テスターは良いテストケースを用意するためにプログラマーとアナリスト両方の経験が必要とかいていました。

Continue reading “More Agile Testingを読んで6(final)”

More Agile Testingを読んで5

ここまでで約60%超えるくらいなのですが、Appendexなど覗くと後少しで読了。実際の経験にそっていることが多かったので、比較的頭に入ってきました。

いくつか役立つことや、考えが整理できること、同じ経験を積んでることを学べたことは個人的に良い収穫でした。

ここに直接関係するわけではないですが、Turnipのようなテスト記述の勉強会したいな。時間見つけよう。

Part6: Test Automation

Agile Testingでは、テスト自動化は必須な武器です。そのため、テスト自動化に関してもある程度の幅をとって記述されていました。

Technical debt, Pyramids of Automation, Test Automation Design Pattern and Approaches, Selecting Test Automation Solutionsという構成で記載されています。

Chapter 14: Technical Debt in Testing

技術的負債はテスト自動化や他のテスト活動において、チームの速度を落とさないようにする必要があります。技術的負債を把握して様々な活動へ落とし込むために、見える化はやはり大事だと言います。

  1. ストーリーに対する見積もりにおいて、タスクカードによりデバグ作業や自動化にかかるメンテナンスも可視化する
  2. 作り込まれた不具合やブロックされたストーリーは、素早く集中して修正する
  3. コードとテスト双方に対してチームは責任を持つ
  4. 技術的負債の課題を定め、負債を減らすようにトライする
  5. 異なる専門家を集めて、全体として負債を減らす

Continue reading “More Agile Testingを読んで5”

More Agile Testingを読んで4

だいぶ進んできましたが、全般的に現在の考えを後押ししたり、参考になるものが多い印象です。もう少し頑張ろう。

Part 5: Investigative Testing

ここでは、様々な事象をより深堀りしていくためのTestingの側面の話しをしています。ほぼ、Exploratoty Testingの話しをしています。

Chapter 12. Exploratory Testing

Exploratory tester達は、事前に定義されるテストセッションには参加しません。そのかわり、経験的に、人間的に、神のような形で期待される予測と比較しながらテストを進めます。それらの差はわかりにくいですが、非常に有意義なものと書いていました。

例えば、James Lyndsay氏はScript testingとExploratory testingを比較していたり、Bad customerを演じる形のExploratory Testingでその有意義さを示しています。
Bad customerとは、

  • invalid parts of imputs – characters, values, combinations
  • Time changes
  • Unusual uses
  • Too much – long string, large, nnumbers, many instances
  • stop halfway/jump in halfway
  • wrong assumptions
  • making lots of mistales, compounding mistakes
  • using the same information for different entities
  • triggering error messages
  • going too fast

などを行うユーザをさしたりします。これらの操作は、Test Heuristics Cheet Sheetなんかが始点として良い例とも述べていました。

Continue reading “More Agile Testingを読んで4”

More Agile Testingを読んで3

次章のExploratory Testingが思いのほかガッツリ書かれていたので、いったん書き残しておこうと思います。

Part 4: Testing Business Value

Skills

本書では、しばしばBusiness AnalysisとTestingは役割が重なると言及しています。また、Testerはユーザなどへの理解、それぞれのFeatureに対するデザインの理解が必要とされます。それらをふまえ、Agile開発のチームにおけるTesterとしては以下の技術も求められるとしています。

  • Business Analysts Skills
  • UX Design Skills
  • Documentation Skills

Continue reading “More Agile Testingを読んで3”

More Agile Testingを読んで2

30%くらいまで読み進めました。
今のところ、現在の実際の経験と差がないくらいで話しが進んでいるので、私の実際の経験に対してなんか安心感。

Part2: Learning for Better Testing

ここは、主により良いテストを書くためにどう学ぶか、ということに関して書いてました。必要なスキルであったり、勉強会のような形で技術の情報共有を行うことなど、組織的な視点からも少し。

Learn Coffee sessionのような、気軽に情報を共有できる場を作ろう、というのも面白い感じ。テストの人も開発技術に関して知識を有することが大事で、こういう場は技術のトレンドや、知らない情報を手に入れるのにもってこいの場所だとのこと。

テストって学んでいくとロジック側によっていく気がするのですが、何か手を動かす側とロジック側、適度なバランスで進めることができると良いですね。

Part3: Planning

Levels of Precision for Plan.

Continue reading “More Agile Testingを読んで2”

More Agile Testingを読んで1

More Agile Testingを読み始めたでも書いた通り、Kindleで読み始めた。

introductionを少し読んで、まずは現在関わっているモバイルアプリ分野のテストで取り上げられている体験談と、自分の立ち位置が同じなのか、異なるのかを確認するために What Is Your Context? を読んでみた。これに少なくとも共感できそうなら、今回の書籍は今の私の助けになるだろうと踏んで。

以下、簡単に。

Continue reading “More Agile Testingを読んで1”

More Agile Testingを読み始めた

Agile Testingは、製造業的な品質保証やテストとはことなる、サービス業としてのテストという側面が強い分野で特に有効な考え方だと感じます。例えば、Webサービスを主な製品とする企業の場合、そのサービスを改善するためのWebアプリ/モバイルアプリの開発サイクルは1日、1週間、2週間と短いものです。その間、頻繁に仕様も変わります。このように小さく速くサイクルを回すAgileな開発分野に置けるテストに関して言及されたのがAgile Testing。

そういう文脈でいうと、私の現職も同じ領域に属しています。

特に今はモバイルアプリに関係しているのですが、そこで必要になるスキルセットは、より広範囲に、より人よりになってきているように思います。つまり、UI/UXの分野や、Usabilityのような分野の知識もより必要になってきているということです。

そこらへんの情報を整理するという意味も込めて、Janet Gregory、Lisa Crispinらが新たに手がけたMore Agile Testingを読み始めました。Kindle版です。氏らは、実践アジャイルテストの原書を書いた方々で、ここが一番書籍としては有名かと思います。

内容は、

  1. Introduction
  2. Learning for Better Testing
  3. Planning-So You Don’t Forget the Big Picture
  4. Testing Business Value
  5. Investigative Testing
  6. Test Automation
  7. What Is Your Context?
  8. Agile Testing in Practice

です。軽くIntroductionは読んだのですが、内容に入る前に What Is Your Context? を先に読もうと思います。ここでは、Mobile分野や、DevOpsとの関わりの文脈でのテストエンジニアについて書かれているので、基礎情報としてまずは読んでおくのが良いかなと思った次第です。

並行して、IAシンキング系の書籍も読んでいるのでまとめも忘れそうですが、時間作れたらBlogにもちょくちょく内容のまとめでも書こうと思います。

The National Software Testing ConferenceのレポートWebSiteみた

The National Software Testing Conference が 5月20-21日に開かれましたね。そのレポート記事が目に入ってきたので、共有がてら。

Trends and Challenges in the Testing Community

ここでは、”Agile”がキーワードだったようで。
Agile、バズワード化してきた感はありますが、従来のウォーターフォールや、それに対する反復手法、スパイラルモデルなどを経験した上で業界の中で今活発になっている開発手法ですね。

Agileは、主に開発行程という観点ではこの中で反復手法から派生したものになるのでしょうか。Agileマニフェストが示すように、より軽量に、フィードバックを中心として開発を進めるもの。これが良い業界も、逆にウォーターフォールが良い業界もあるのは言わずもがな。

一方で、海外では公的機関含めAgile Developmentを要求する所が増えてきているのは面白いところ。

それはさておき、上のURLに合わせて記載されていたURLを以下に抜粋。

Continue reading “The National Software Testing ConferenceのレポートWebSiteみた”

Appiumを使ってRSpecの記述とTurnipの記述とで、結局はどちらが受け入れとして使えそうか

比較的、ぱっと見て操作を想像できることが受け入れ試験では大事だと思います。
そう考えると、RSpecはshared_exampleなんかで操作をまとめることができるのですが、Turnip/Cucumber形式のシナリオアウトラインを使った方が綺麗にかけそう。

一方、capybaraのように、RSpecの拡張としてFeature specを使うこともできる形があります。なら、Appiumを使って同様に受け入れ試験の形を模倣するならば、CapybaraのFeature specを参考に類似した記述を模倣すれば、RSpecのみである程度読みやすい受け入れ試験もかけるかもと思い、以下をまとめてみた。

Continue reading “Appiumを使ってRSpecの記述とTurnipの記述とで、結局はどちらが受け入れとして使えそうか”

アジャイルソフトウェア要求vol4最後

Agile手法に対するアーキテクチャーは、個々のチームから複数のチームへとAgile手法の拡大を進めていくと必要になっていく。一方で、AgileやLEANを失わずに進めていくことが課題。

基本的な原則

Continue reading “アジャイルソフトウェア要求vol4最後”