Comments on: Sharing Lessons Learned, Making New Friends at QA&TEST 2009 Conference in Bilbao, Spain

By: home security system reviews

home security system reviews — Tue, 10 May 2011 12:19:36 +0000

I’m typically to blogging and i really recognize your content. The article has actually peaks my interest. I am going to bookmark your web site and maintain checking for brand new information.

By: Buy Backlinks

Buy Backlinks — Wed, 25 Aug 2010 09:51:39 +0000

This is a good blog. Keep up all the work. I too love blogging and expressing my opinions. Thanks

By: Hung Nguyen

Hung Nguyen — Tue, 17 Nov 2009 17:22:35 +0000

In our high-volume automation model, the offshore team does all of the test design, writing and maintenance. Test execution, failure analysis, and bug reporting can be done by on- and offshore team. The onshore team then can spend more time on exploratory testing and giving direction and advices on new tests, and also on reviewing tests.

By: Dmitry

Dmitry — Mon, 09 Nov 2009 18:15:09 +0000

Hello,
i have another tough question that is hidden in the books and in the classrooms. Designing Automation tests (AT), Writing AT, executing AT, etc. Here is complete process in determination of Auto Tests Life Cycle. Who is doing what within QA team? or what what is the best way to organize the process: DAT (Design AT) –> WAT (Write AT)–> EAT (Run/Execute AT) –> AAT (Anylyze Results from AT) –> LBAT (Log Bugs based on AAT) –> MAT (Maintain AT). Form my experience: DAT and WAT is work of both QA and Automation Engineer. The most complicated and challenging part for managers – EAT and AAT. In your off-shore model who is doing this most important and most challenging part? Who is tracking the validation of the results? The are tons of questions assosiated with this, please explain. Thanks,
Dmitry

By: Hung Nguyen

Hung Nguyen — Wed, 04 Nov 2009 17:05:39 +0000

In my practice, high volume test automation is method centric with the support of keyword technology behind it. As to any test automation technology, you are correct: analyzing test results is a huge and time-consuming task that must be accounted for as part of the cost of automation. Certainly, false negatives (Fail test does not mean that there is a bug in the AUT) are common events in comparison-based automation. The key in the strategy is having a method to minimize the debugging and maintenance of the tests. This is what I normally refer to as handling “the high rate-of-change” and it is unavoidable. If you spend more time to analyze and maintain your tests than adding new tests, then the automation solution will not or scale or give you the return that you wish. All of this is not easy, but it is doable and must be done. As to theory can be very different than reality, I also agree. Talking theory is easy! The valuable lesson only comes when you actually have done it!

By: Dmitry

Dmitry — Fri, 30 Oct 2009 20:43:55 +0000

Hi again,
i am reading news now regularely. And more i read about high volume test automation, more questions i have. As i mentioned before, automating different applications with different tools or writing atomation code from scratch, i learnt a lot and know well that theory and words very often are far away from reality. Let me ask you one simple question: how do you analyze test results outcomed from high volume (close to million as you have mentioned before) auto tests? Do you count time for investigation the results. You should know well that most of the automation will not report the exact problem spot and most often the next step will show the error, rather than actual error in application. Let me know. Thanks!