We know how to deal with functional requirements. We know they are important – we can walk the dependency chain from goals to use cases to functional requirements. But how do we get to the non-functional requirements? Leathej1 points out the elephant in the room – non-functional requirements don’t get enough attention when it comes to testing. Let’s look into it some more…
Category Archives: Testing
Posted in Process Improvement, Requirements, Software development, Testing
Tagged constraint, functional requirements, goal, karl wiegers, managing data, non-functional requirements, requirement, requirements management, software process, software product success, structured requirements, use cases
12 Comments
Foundation Series: Functional Testing of Software
Functional Testing, also referred to as System Testing of software is the practice of testing the completed software to confirm that it meets the requirements defined for the software. A functional test is typically a test of user interactions, but can also involve communication with external systems. We contrast functional testing with unit testing. We also show how functional testing provides different benefits than unit testing.
Posted in Agile, Foundation series, Process Improvement, Software development, Test Automation, Testing
Tagged automated testing, black box testing, blackbox testing, blackbox tests, functional testing, functional tests, graybox testing, graybox tests, keyword table testing, managing data, qtp, software development process, software process, software product success, software quality, system testing, testing automation, unit testing, white box testing, whitebox testing, whitebox tests, winrunner
6 Comments
Foundation Series: Continuous Integration
Continuous Integration is the software development and quality process where all team members merge their code and verifies it frequently – at least daily. This verification project includes both an automated build process and automated testing. The main benefits of continuous integration come from risk-reduction and cost-reduction.
Posted in Agile, Foundation series, Process Improvement, Software development, Test Automation, Testing
Tagged agile development, agile process, agile testing, automated testing, build automation, continuous integration, incremental delivery, incremental process, iterative delivery, iterative process, managing data, Test Automation
2 Comments
Communicate Relevant Quality Metrics
Most teams think about testing in terms of code coverage – what % of the lines of code are covered? What matters to our stakeholders is how well the software works. More precisely, how well does the software let the users work? We should be targeting our quality message in terms of use cases, because that matches their perspective and context.
Posted in Communication, Consulting, Product Management, Requirements, Software development, Testing, Use Cases
Tagged communicating quality measurements, Interaction design, managing data, measuring software quality, quality measurement, requirements traceability, software testing, software traceability, structured requirements, test traceability, testcase traceability, Testing, traceability, unit tests, use cases, white box tests, whitebox testing
2 Comments
Market Segmentation or Senseless Mistake?
A grass roots campaign has been started by Peter Provost to get Microsoft to include unit testing support included with all versions of Visual Studio 2005 (VS). Currently, Microsoft is only including it with Visual Studio Team System (VSTS) versions of VS. This looks to be a great example of a killer feature in a product providing so much surprise and delight that people are demanding that it be universally available. This is also a great example of market segmentation by Microsoft. The irony is that there is an open source alternative that makes the opportunity cost very low, and yet people are still clamoring. Let’s see why.
Learn to Fly with Software Process Automation
We can reach the next step in our software process evolution by automating much of our process. Flying squirrels evolved a technique* to quickly move from one tree to another without all the tedious climbing and dangerous running. Software teams that automate their processes achieve similar benefits. Automation allows us to increase efficiency while improving quality. And we spend less time on tedious and mundane tasks.
Passing the Wrong Whitebox Tests
We’ve talked about the value of using whitebox testing in our Software testing series post on whitebox testing. What we haven’t explored is how to make sure we are creating the right tests. We have to validate our tests against the requirements. This post shows where the flaw is in the typical whitebox testing process, and how to fix it.
A reader emailed us with the comment, “It’s been my experience that developers can’t test their own code.” Their problem was that they were missing a link in the software development chain (missing a step in the process).
Posted in Communication, Process Improvement, Requirements, Software development, Software requirements specification, Testing
Tagged managing data, PRD, requirements testing, requirements validation, software development process, testing process, testing requirements, white box, white box testing, whitebox, whitebox process, whitebox testing, whitebox testing process
Leave a comment
Software testing series: Pairwise testing
Very large and complex systems can be very difficult and expensive to test. Often, we inherit legacy systems with multiple man-years of development effort already in place, in the field and of unknown quality. With these systems, there are frequently huge gaps in the requirements documentation. Pairwise testing provides a way to test these large, existing systems. And on many projects, we’re called in because there is a quality problem.
The code freeze is killing the dinosaurs
The software development process for most companies has a flow – gather requirements, design, implement, test, release. There can be feedback loops, iterative cycles, spirals or waterfalls, but they all have these steps. When teams “freeze the code” and submit to test, they are creating their own mini-ice age and dooming themselves to extinction.
Latest Articles
Comments on all Articles
