Should we test our software? Should we test it more?
The answer to the first question is almost invariably yes. The answer to the second question is usually “I don’t know.”
We write a lot about the importance of testing. We have several other posts in our series on software testing. How do we know when we should do more automated testing?
This is the third in a three-part post about using tags as a means to organize an automated unit test suite.
Part 3 of this post can be read as a standalone article. If it were, it would be titled Design elements of an automated unit test framework using tags. If you’re only reading this post and not parts 1 and 2, pretend that this is the title.
This is the second in a three-part post about using tags as a means to organize an automated test suite.
Part 2 of this post can be read as a standalone article. If it were, it would be titled Top five problems with test automation suites. If you’re only reading this post and not parts 1 and 3, pretend that this is the title.
This post is a follow-up to our previous case study on incorporating unit testing into an existing team’s development environment. The case study is based on a real solution that has already started reaping rewards for our client, and is gaining momentum. We’re now looking at making it easier for the development team to maintain this test suite, and proposing some extensions – including a form of tagging.
The three most important things to understand about the quality of your software are the three things most relevant to your business and your stakeholders (and arguably, your boss).
Top three measurements of software quality
1. How do people perceive our quality?
2. How big of a problem is our quality?
3. How bad is our software, really?
This post is a test automation case study, but at a higher level.
We’ll talk about it in terms of defining the problem, and then discuss the objective (what we proposed to do to solve the problem), the strategy (how we went about doing it) and the tactics (how we executed the strategy). Since this happened in the real world, we’ll also identify the constraints within which we had to operate.
These articles are written primarily for business analysts and product managers. Hopefully they are helping you with thinking, doing, and learning. Welcome aboard!
Latest Articles
Comments on all Articles