サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Google I/O
shiozi.hatenablog.com
テスト設計からテスト実行までを一人で行っていた人が、テスト設計だけを担当してテスト実行を他の人に任せるようになったときに、テスト設計者の暗黙知が表現できていないなどの理由でテスト実行者が異なる認識でテスト実行することがある、「ここまでみてほしい」と思うところまでみてもらえない、というもどかしさを感じる、ということを経験したことがあるかたはどのくらいいるのでしょうか? 私も初めてこのケースに遭遇したときは「なんでそこまでみないのっ??!」と驚いたり、自分でできたらこんな見落としはしないのに・・・と思ったりしました。。。今でも思うことはありますね(^^; このようなことが起こると、テスト設計時の狙いが実行時に漏れてしまうため、なるべくテスト設計者とテスト実行者のずれを少なくしたいと思うのですが、その際に「誰でも同じようにできる」を目指してしまうことがあります。特に10年前とかそういう傾向が強か
qiita.com アドベントカレンダーの17日目です。 記述自体は11月に行っていましたが公開を遅らせたのはWACATE2016冬のポジションペーパーに記載した内容をもとにしているから。ということで、WACATE2016冬当日の公開・・・♪ 意欲的になるっていうのは比較的簡単かなぁと思うけれど、意欲的になっても行動に移すのは難しいなぁと思っています。そして意欲的にさせるのは更に難しいと思っています。みなさんはどう感じていますか? そこに到達したい!実現させたい!やってみたい!と思っても、自分が目指すところに行くための始めの一歩がみつからなかったり、始めたものの次にどうしたらよいのかわからなかったりと、なかなか思うようにたどり着けないことが・・・私自身にも周りにもあるなぁと感じています。 例えば・・・よく耳にするのが「テスト技法を学んだのだけれども、それを現場で使うためにどうしたらよいのか
最近構想していることについて書いておこうと思いました。 これがいいという話ではなく、こうしてみようかなぁという話です。 背景として、今の現場(ブラックボックスのテスト専門のテストチーム)では、まったくと言っていいほどテスト分析、テスト設計とテスト自動化が進んでいません。現場の特性として自動化できる箇所に制限はあるのですが、それでもできる箇所もあるし、比較的自動化させやすいWebUIを持つものが多いため、その気になれば自動化できます。しかしながらテストコードはおろかHTMLすら書いたことが無いメンバーばかりという難点があります。そしてテスト分析やテスト設計も・・・まぁこれまでの記事でおわかりになるように仕様書の記述からテストケースを挙げることに慣れている状態で、仕様書がないと思考停止してしまう状態です。 そんなところに、どうやってテスト分析と自動化を導入していく?という話。 最初は、UIのテ
このページを最初にブックマークしてみませんか?
『shiozi.hatenablog.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く