Paul Smyth recently wrote a post for finextra detailing seven reasons why software development is so hard and often runs into deadline and bug issues. He makes some good points and does a nice job looking at the software development process from both the developer and tester point of view.
Here’s an overview of Paul’s seven points, along with my thoughts on how they pertain to testing in particular:
1. The software industry is young
Humans have been building house, roads and bridges for thousands of years. We’ve no idea how many house or bridges collapsed in the early days as humans learned the correct techniques for building these structures. …
In comparison the software industry is only about 50 years old. We still have a long way to go before we have the body of experience behind us that the construction and manufacturing industries have.
Yes, the industry is still relatively new so we’re still trying to figure everything out. But, unlike building physical structures, software is constantly changing right under our noses. Once a bug is finally common enough to be routinely addressed, another one pops up – sometimes as a result of fixing the initial bug. Plus the continual development of new technologies – hardware, operating systems, add-ons – adds new challenges while testers are still trying to overcome previously-known challenges. The earth stays mostly the same no matter when or where you’re building a bridge, software doesn’t.
2. Every line of code is a potential point of failure
Each line of code will have dozens, even thousands, of possible inputs, outputs, states or dependencies to deal with. It can impact, or be impacted by, other lines of code or by external factors. Even if it was possible to document every test case for a line of code you still couldn’t be sure that there wasn’t some unknown factor that could cause an error.
And testing a single line of code is only part of the challenge. No line of code exists on its own. It is part of the whole system and the whole needs to be tested to ensure that all parts of the application function correctly. …
This one pretty much hits the nail on the head. Without unlimited time and resources, there is no way to test 100% of the new software. Even with unlimited time and resources, the fact that many projects are essentially brand new means there may be hidden bugs that testers don’t think to look for. The fact that development and testing teams traditionally don’t work together only exacerbates the code challenge – though we’re starting to see a shift away from this divided practice.
3. Lack of user input
Without the involvement and input of a user representative the project is doomed to failure. This person should be a subject domain expert with the authority to make decisions and a commitment to the project timescales.
As a usability tester, how many times have you looked at a new application, been confused and wondered how in the world the developers thought it was a good idea? Then, when you log the bug, the only response you get is “works as designed.” Sometimes developers can be so heads-down in their project that they don’t realize the software isn’t end-user friendly. This can also be a problem for testers. If a tester has been working on a particular project since the beginning, they can be blind to the fact that it’s not intuitive. Since they already know how the software is supposed to work it seems easy to use to them.
4. Users don’t know what they want until they see it
Even with good input from the users no amount of analysis of user requirements can take away an immutable fact that users only think that they know what they want. In truth, it’s not until they start seeing something, and using it, that they begin to really understand what they need. This is especially true when the software is being developed for a new idea or process that they haven’t used before.
Paul looks at this point more from a development standpoint, noting that requirement changes are common but drastically effect development and project deadline. From a tester standpoint it speaks to the fact that in-lab testers don’t necessarily match end-user demographics, so they can only guess at how users will respond to the software. In-the-wild testing, using professional testers who mimic your target demographic is a way to address this issue.
5. There are no barriers to entry to become a programmer
There is one argument that states that software development is so hard because programming is so easy. In other words it is relatively easy to learn how to write code but there is a huge gap between that and delivering great software. …
There is no barrier to entry into the programming world and thus it is awash with many poor programmers who adversely affect projects. In addition, even potentially good young developers will still make mistakes that a more experienced developer will have learned to avoid.
Switch the word “programmer” with “tester” and the sentence is just as true. Though there are tester certification programs out there, they are by no-means necessary like some training programs are (think doctor or lawyer).
6. All software is affected by external factors
Software is “mindware” and therefore doesn’t obey physical laws but it usually must conform to external constraints such as hardware, integration with other software, government regulations, legacy data formats, performance criteria, scalability etc.
Understanding and catering for all of these external factors is a near impossible task. Even a seemingly simple requirement, such as supporting multiple browsers, exponentially increases the difficulty of both building and testing software. If you then add in a requirement to support multiple versions of each browser then you are again exponentially increasing the complexity and the difficulty.
This is the challenge of the testing matrix. Testers must take a developer’s work and test it against a variety of hardware/software combinations, plus real world factors such as carriers, network connections and unexpected load spikes.
7. Estimating is an art not a science
Of course experience guides you in your estimating and the more experience you have the more likely you will be to anticipate the unknowns. Too many projects run over because overly optimistic estimates are set by inexperienced people who expect everything to flow smoothly and who make no allowance for the unknowns.
Testers get particularly frustrated with this because it it usually not the QA department setting the deadline. Plus, if development runs over the deadline typically isn’t extended. Instead, testing is expected to be completed in a shorter time frame. These practices put added pressure on testers. In fact, companies under-appreciating QA and underestimating the difficulty of the job are two recurring complaints among testers.
This was just a sneak peak at Paul’s full list. He makes some great points that I didn’t even touch on here, so be sure to read the original post in its entirety at finextra >>>