Yesterday I had a call from a participant in my recent BayAPLN session. I completely screwed up and, when I tried to save the phone message, I deleted it, and somehow the number that my phone saved, I could not call back. So, I’d like to try to answer the question, as best I remember it, here. If you still have questions, please email me, because this is such an important topic.
Since I listened to this question in my car and could not write it down, I don’t have it exactly, but it was along the lines of: “My team has no automated testing. One of our user stories did not have all the testing completed by the end of the sprint, because there was not time to complete the manual tests. Would you please recommend tools to help us?”
I know of a lot of great testing tools, GUI drivers and frameworks. If you want to do GUI testing, you can’t go wrong with Canoo WebTest, Selenium, Watir. Robot Framework, FitNesse and other frameworks can be used for testing at the API level or combined with a driver for testing through the GUI. Those are just a few examples of what’s available. Even better, your team can write its own testing frameworks and harnesses.
But tools aren’t the point. The point is that the best people to solve your testing problems is your own development team. By “development team”, I mean programmers, testers, BAs, DBAs, sys admins, everyone involved in delivering software. If you aren’t delivering user stories in a sprint because testing isn’t finished, you need to look at that problem as a team. By bringing all your team’s different roles, experiences and viewpoints to bear on this problem, you will think of experiments to try, and you will arrive at solutions.
Give yourselves time to experiment. Engage everyone involved in delivering software in solving the issues of getting all testing activities done each sprint or iteration. This diversity of viewpoints means you will eventually succeed. YOUR TEAM can solve this problem. Give it a chance!
5 comments on ““Our manual testing…””
Completely agree. Tools are useful, but it’s the PEOPLE that use the tools that matter most.
Tools will never replace good character, work ethic, and process frameworks that helps people work together better!
[…] “Our manual testing…” […]
Automation is only as good as the test cases pumped into it. When I build frameworks I target usability for self service non technical operational use. http://fischertech.tech.officelive.com/Selenium1.aspx this is an incomplete website with only image stubs, but it shows an idea of the cases can be created in Excel and fully descriptive from a manual tester’s perspective and the same document can be read by the automation. Test cases can be recorded with the Firefox selenium IDE recorder and further enhanced for web element location durability build over build. Also I setup the team so we have one test tool developer focused to accommodate automation for the QA test team. The QA team becomes the developer’s customer and they focus on tools to accommodate tester quality throughput of regression testing so manual testers can focus on new test coverage & new features. It’s critical the automation framework & scripts don’t’ bog down the QA team. Otherwise it becomes another failed tool development effort. It’s important the developer feel their pain and tries to solve with a software tool. Either, off-the-shelf or in-house custom or hybrid. Most manual testers like the automation because it removes the mundane aspects of the regression testing build over build. If the developer creates an acceptable tool platform, manual testers will adopt the test case development methodology for automation scripts and operation of the framework. Once the tools are deployed and accepted, the developer can move on to other projects but you always need a developer owner of the automation to keep up with manual test team needs.
A couple of more comments on Manual testing.
As “recently as 1998, in one Fortune 100 company, performance testing was conducted while one test engineer sat with a stopwatch, timing the functionality that another test engineer was executing manual testing”. [Elfriede99]
Manual testing is that part of software testing that requires operator input, analysis, or evaluation.
Manual Testing should be documented in great procedural detail. This helps in repeating the tests consistently, in the way they were intended.
At first I thought your comment was ironic, but after looking at your site, I think you really believe this.
If it can be documented in great procedural detail, it can be automated. Collaborate with programmers to automate those tests, and spend the time you save doing more valuable manual exploratory testing.