最近のagile-testing

雑記

前回にひきつづき。

virtual training for testers

BDD/ATDD(参照)のオンライントレーニングってなんかあるんですかね、という話。だいたい有料トレーニングコースの話題なんだけど、それ以外に出てた
Rubyスクリプティングテクニック ―テスト駆動による日常業務処理術(原題:Everyday Scripting with Ruby: For Teams, Testers, and You)、pairwith.usのペアプロ動画がちょっと興味深い。

Testing moving from waterfall to iterative

テストプロセスをアジャイルにしたいがQAの反発があるという話。先週に引き続き盛り上がってる。
品質指標を測定してアジャイル開発の効果を示せとか。

Layer Acceptance Test Should Call in MVC Application

どのレイヤーに対して受け入れテストを行うかという話。もりあがってる

browser compatibility testing

さまざまなブラウザ/プラットフォームでテストすることのROIについて。特定のブラウザ/プラットフォームの組み合わせでしか発生しないバグってどれだけあるのよ。

  • うちのwebアプリはプレゼンテーション層をなるべく薄くしてる(jsやAjaxもなるべく避けてる)からそんなに必死にテストしなくてもいい。
    • ユーザが多そうな組み合わせはテストしてるけど、差が出ることはほとんどない。
    • リッチなUIを使い出したらたいへんでしょうね
  • ブラウザごとの性質
    • Firefoxはプラットフォーム間で挙動が同じと思っていいだろう
    • IEは…… IEですね
      • パフォーマンスが重要だったりファイルシステムと多くやり取りしているようなら*1(?)、いろんなバージョンのWindows上でテストをする価値はある。
      • (IE7と8の差異の話とか)
      • 結論としては、IE7/WinXPとIE8/Win7の組み合わせで自動テストをするとよい
      • デプロイ前に全ページ目視確認もすること
  • 私の経験からすると、表示上のバグくらいしかない
    • そういうのは自動化テストで検出できないため手動テストするしかない
    • あるブラウザでしか起こらない機能上のバグはそうない
    • どんなテストがいいかは結局アプリの性質と開発者の能力に依存するよね
  • リッチなJSアプリならブラウザ間で挙動が違いまくりますよ
  • ↑jQueryとか使ってるなら大抵の差異は吸収してくれるよ。レンダリングについてははブラウザ間で違ったりするけど。
  • GWTいいですよ
  • combinational testingの概念を学びなさい

*1:よくわかんなかった。原文: ... if you have lots of interaction between the browser and, say, the file system, ...