1. Start together. Or in other words, ‘start planning with testing involved on day one.’ "In reality, any ramp up period is never sufficient," according to one of our software testers. The risks associated with pushing testing as far back in the SDLC (in order to save on resource costs) might not be cost-effective in the long run. In addition, if you fail to create a process, or perhaps a testing strategy as part of the development, then chances are you’ll incur more costs and further delay shipping your product. QA members need to get as much visibility into requirements.
Good planning is essential for success, as a general practice. For testing, this includes identifying test objectives, methods of testing, resources and roles, tools, risks, reporting, timetable, environment, priorities, and regression test approach. It’s been recommended that for "every stage of development design, a corresponding test strategy should be created to test the new feature sets."
Test automation necessitates that both developer and software tester identify and assign conventions for Selenium locators, for example, at the onset. These locators allow software testers to find elements on a page that can be used in automated tests. If the developer changes that locator (in the next iteration), then the tester then has to make edits, which is typically more time-consuming versus starting from scratch. In addition, it is not a trivial task to uniquely identify locators, but tools such as Firebug come in really handy.
2. Document well. Or in other words, ‘you never know what you will forget in the future.’ In some cases, this also means, ‘make it easier for other people to understand your work’ aka ‘have some respect’. Just do a simple comment, such as what that script does. It doesn’t have to be an essay.
Again, any ramp up period is never sufficient. Say, a transition happens and somebody new has to jump in and read the code — what if he fails to understand what a script does for lack of documentation? He can write out a new one, instead, but he doesn’t know he’s re-writing something that’s already been written!
It’s best to have very detailed test cases, however just enough documentation should suffice for our agile development. Getting everybody — including the product owner / customer — on board test-case preparation helps ensure completeness of the test cases.
3. Divide and Conquer. Manual testing typically can start earlier, perhaps 2-3 iterations earlier, followed by automated testing. During development, it’s challenging to do test automation as there are moving parts. As a general practice though, once the application becomes stable, that’s the time automated testing can take place.
It’s also good practice to separate the testing environments because, "there’s a possibility that when scripts start running, the one doing manual testing might accidentally manipulate a certain data." Worse thing that can happen is that the test automation crashes, and that means the manual testing will have to stop.
"Automation would run faster within its own environment."
4. Test early, test often. "The value for us is that if we roll out incremental deployments, we can test early and apply fixes immediately. If we can apply fixes early, then we have more time to focus other bugs. In any case, having a sufficient test coverage is always recommended," said a project manager.
The agile approach means testing as early as possible, and that involves unit testing for developers, integration testing, and then system testing. In addition, "each feature is being fully tested as it’s developed."
Run at least three passes of testing. "Your first past at testing simply identifies if the function is working. We call this happy scenarios," said another software tester. "The second pass is to test the happy scenario and the unhappy scenarios."
Source: http://www.sys-con.com/node/2732409
