by John Parker | Dec 17, 2012 | Business Analysis, Testing, Uncategorized |
I talk to clients and potential clients daily about our business analysis solution and its capabilities for managing requirements and associated testing and quality assurance activities. We have an excellent tool for performing these activities. However, I see a lot of confusion concerning testing and quality assurance with respect to requirements management tools. In this blog, I will describe the various types of testing tools. To perform successful testing usually requires a variety of tools. There is no single tool on the market, including ours, that does it all – regardless of what vendors may claim. There are usually many people and groups that participate in testing activities and each group may require a different type of tool, depending of course on what they are trying to do. Below is a list of people that generally participate in testing activities. Users Developers Quality assurance teams Business analysts DBAs Product owners/sponsors Compliance and internal audit Performance testing engineers Penetration and security test consultants There are many different types of tools available for testing. Testing tools can generally be categorized into following three main classes: Test Management Tools, Test Data Planning and Preparation Tools, and Automated Testing Tools. A description of each tool class is provided below. Test Management Tools Test management tools are focused on the overall testing cycle, as well as test management and reporting during complete project cycle. These management tools are further classified based on the purposes of different functionalities they perform or which testing phase they emphasis upon. Test management tools can generally be categorized into three categories: Requirements management tools Test management tools Review tools...
by Karl Wiegers | Aug 6, 2012 | Business Analysis, Testing, Uncategorized |
Someone once asked me when you can begin testing your software. “As soon as you’ve written your first requirement, you can begin testing,” I replied. It’s hard to visualize how a system will function just by reading the requirements specification. Tests that are based on requirements help make the expected system behaviors more tangible to the project participants. And the simple act of designing tests will reveal many problems with the requirements long before you don’t execute the tests on an operational system. If you begin to develop tests as soon as portions of the requirements stabilize, you can find problems while it’s still possible to correct them inexpensively. Requirements and Tests Tests and requirements have a synergistic relationship. They represent complementary views of the system. Creating multiple views of a system—written requirements, diagrams, tests, prototypes, and so forth—gives you a much richer understanding of the system than can any single representation. Agile software development methodologies often emphasize writing user acceptance tests in lieu of detailed functional requirements. Thinking about the system from a testing perspective is very valuable, but that approach still leaves you with just a single representation of requirements knowledge. Writing black-box (functional) tests crystallizes your vision of how the system should behave under certain conditions. Vague and ambiguous requirements will jump out at you because you won’t be able to describe the expected system response. When BAs, developers, and customers walk through the tests together, they’ll achieve a shared vision of how the product will work. A personal experience really brought home to me the importance of combining test thinking with requirements specification. I once...
