Better Software - November 2008 - (Page QA1)

ADVERTISEMENT In the face of tight timelines and large, complex projects, do you need exploratory testing (ET) or is it just a waste of time? n an ideal world, the phases of software development go hand-in-hand with extensive documentation. Specifications and requirements for each part are set out neatly, all ready for testers to begin work. But that doesn’t happen very often, does it! You’d want the tester to get involved as early as possible in the software development life cycle, so that development and testing can happen in parallel. But that’s when the software is just beginning to take shape, is likely to be unstable and buggy, and will probably be accompanied with little or no documentation. And, change requests, increments, and iterations will be the order of the day; so even if you have documentation, it’s likely to be outdated and of little use. Can testers do anything in such a scenario? The answer lies in exploratory testing (ET). Using this technique, skilled testers can gain understanding of your product—they learn more about it, explore various areas to assess how they work, and get a feel of the risky areas that are likely to throw up bugs. This will help them design test cases, execute them, and use the findings in further test design and execution. That makes it sound like ad hoc testing. But nothing could be further from the truth. Ad hoc testing is usually short-term; it consists of tests that are run only once, unless a bug is discovered. ET is a wider and deeper concept—it covers not only ad hoc testing, but all forms of testing. All testing, even scripted or automated testing, is exploratory to a certain degree, since tests could be modified on the I basis of results obtained and defects discovered. For instance, if a tester has run a particular test case and found unexpected results, the tester is bound to ‘explore’ further, and run a few more tests—which may not be part of the test suite—to discover more about the bug. That’s exploratory testing to a certain extent. Make Exploratory Testing Work Most of these challenges will cease to be important if you have a skilled testing team; or if you outsource the testing function to a skilled test services provider. ET relies heavily on the testers’ knowledge, experience, skills, creativity, and intuition. So, to make ET work for your project, it is important to find the right skills. To optimize your use of ET, well-defined procedures and documentation are required. That’s why QA InfoTech is the right choice for you, if you have software that needs to be tested rapidly, but has little supporting documentation. We have processes and metrics in place for weekend projects—those with little or no documentation, which need to be tested over the weekend; the results would be ready for you by Monday morning. Our highly skilled test team formulates an assessment strategy, by understanding what to test, why it should be tested, how to test it, and when to stop testing. We then manage the testing process to yield the best results. Our approach includes effective and timely communication with project managers, developers, and the marketing team. We use the Staticator to facilitate communication regarding test efforts, coverage and so on. We also have a well-defined methodical process to develop the test metrics or the test deliverables. Other documentation would include summary of defects; and how severe or otherwise these are, so that defect fixing can be prioritized. A Waste of Time? ET is often considered a waste of time— though the tester spends a lot of time trying to understand how the software works and in which scenarios it is likely to fail; what you get at the end is a list of bugs, which in any case, you would also get with automated testing. ET would be a far more productive exercise if the testers could share their understanding of the product and suggest improvements based on that. That is possible if processes to capture this information are introduced. Moreover, several challenges are associated with ET. Since test design and execution occur simultaneously, the test design cannot be reviewed in advance. This could lead to errors in the code and in the test cases. Challenges also arise in documenting the test cases that testers create on the fly, especially if they need to be rerun in future. Since there is very little documentation, it is difficult to find out which test cases were run at which point of time. Thus, if the tests are run a second time, it may not be in exactly the same way. This can cause difficulties if it is important to document what parts of the product were functional at each point in time. http://www.qainfotech.com

Table of Contents Feed for the Digital Edition of Better Software - November 2008

Better Software - November 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Getting Agile with User-Centered Design Google Web Toolkit Simple Summaries of Complex Projects Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.