| || |
Test Automation in Agile Project
If we want to automate tests in a Agile Projects, just curious what would be the correct approach.
To me before automate tests we must complete the manual testing of a story. So would it be better, first complete the manual story testing and then create a another card to automate the same story in the next iteration or could be same iteration based on the priority
Further is there a practice in agile where we automate tests straight away?. But I think then it would be a more effort and it might leads to delay it getting stories into done state. Are there other pros and cons?
Appreciate your thoughts
A BDD/ATDD approach would be best. This way you are writing your automated tests as the requirements for "done".
I agree tests first is generally the best way to go. It usually ensures more comprehensive tests and more focused design. There's several googletesting blogs about this topic. It also forces product to be designed with testability in mind.
I think what you end up doing will most likely be have to adapt to the level of maturity in your software process and skill level of your dev team. BDD/TDD is generally harder to do if you do not have enough Sr. or Architect level engineers on your team as it usually involves predefined interfaces and contracts in order to be able to automate before product code is written.
I'd like to throw out there, not to think of manual testing and automated testing as part of the same quality bucket. I'd like to think of automated tests as tests to ensure deployment and configuration, and manual testing as ensuring that what is built meets customer needs. Usually the big trap people fall into is think that automated and manual tests are testing the same thing, and try to automate all their manual tests and end up with too much test code to maintain (which is usually not as well architected as product code). You want to always have a good test plan and figure out what level of risks exist in which area, and allocate the testing effort proportionally.
Thanks for you replies.
Got more questions for better clarification
1. In BDD/ATDD should we focus on system tests or E2E tests? As these code will be written by developers what would
be the testers role there. Focus on exploratory testing?
2. If the the Agile Project doesn't follow BDD/ATDD what would be the better approach.
3. Do the manual test first and then automate E2E test per story?
But in our case testers try to automate system tests as well. Is that a good practice in agile projects? If so what
advantage you get out of it? Because to my thinking E2E automation is much important.
Last edited by shabar; 07-12-2014 at 04:07 PM.
It's usually better to automate first. The reason for BDD is to force that to happen via process. Generally in shops where automation isn't done first, the short term pressure of releasing quickly will end up creating a situation where automation takes a back seat in order to rush the release.
Originally Posted by shabar
But in our case we got web UI and and back end API development. So we cannot perform E2E acceptance testing until we get the fully developed integrated system even though we have the tests.
Originally Posted by dlai
Therefore is there a practice to implement BDD for system level testing (not for acceptance level) to be able to run those once back-end API development is completed.
If so do we need to have another set of BDD acceptance level testing for us to run when we get the fully integrated system?