Arkisto: November 2009

Software Quality Is Secondary To Business Activity

25. Novemberta, 2009 | Kirjoittaja: Antti Niittyviita

Safety is central when it comes to designing and building nuclear power plants. The construction sites have specifically chosen people, who inspect the work others do. These fellows need to be experienced and know what they are doing.

A car can only be inspected by a qualified person. Car engineer’s training, work experience, special courses for car inspection etc qualify people for this line of work. One cannot find employment with zero training.

At construction sites that handle electricity there is a person responsible for checking the safety of connections. That person signs the papers with his or her own name.

Medical procedures require a certain qualification.

All these things mentioned above are essential for general safety, so quality assurance must also be top level. Potential flaws can lead to loss of human lives, so quality inspections are especially understandable.

What about these:

Producers of whiskey and wine are especially careful regarding the quality of their products. The people who are responsible for quality inspections are experts in their own field and have a long experience doing their job. I can think of a white-bearded old man. Bad quality can be sold in bulk, but it will never be released on the market under one’s own brand. Even if it would intoxicate.

In music business, the record group’s representative is the producer. The producer is that person, who observes the record all the way from the recording to the mixing. An inside quality inspector it is. Usually not very inexperienced fellows.

Neither are about life and death, even though bad music or sour wine can kill the mood.

How is quality assurance seen in software development?

  • We have no specific university level or polytechnical education for this line
  • Testing is seen as a portal work for actual real development work (“Well, test this summer and we’ll see about coding next year.”)
  • Tester’s career practically ends at test manager’s duties. The next step is project leader. Experience in testing does not get to accumulate.
  • Tester’s salary is significantly lower than that of a coder with the same amount of work experience.

And still we are talking about a person whose job it is to critically evaluate the work others do.

When a software firm claims quality to be important, it is worth asking how it is shown in the respect for quality assurance. Is testing treated as the neighbour’s idiot son, whom the big boys of quality development see most of the time as a pain in the ass? Or is testing seen as an equal player in your team? How is it done at your place?

Shutting Down The Professionalism?

18. Novemberta, 2009 | Kirjoittaja: Antti Niittyviita

It became more profitable to sell crap for cheap than quality for a high price! Rest in peace, craftsman!

…wrote Markku Saksa in his column ‘näin ajettiin ammattimies alas’ in Taloussanomat. The current trend does seem to be striving for a quick profit at the cost of quality. So, is testing therefore profitable anymore? The boundaries of overquality and adequate quality are both sliding down. The end client has also begun to be satisfied with what there are available.

Personally, I never buy the first version of a household appliance. I would rather wait until the product has been sufficiently tested and the worst flaws have been fixed. At the grocery store I always check the labels from several packages, such as the expiration date from the milk. For the hell of it, just check the information from your usb hard drive or router from the store’s shelves. Compare the information in the serial labels. It is exciting to see how many different versions from the same model there can be on that one shelf. Testing has been outsourced to the end user. Not good!

Professionalism has still not been entirely shut down. Modern professionalism is about concentrating on the right things.

Apple did a cunning trick from the perspective of quality assurance with their phone business, I found. The entire product development has transparently started from the idea that the end user is only catered with positive user experiences. In reality, the functionality behind iPhone is not that good. Type acceptance tests lag behind and the operator is agonized when one iPhone can reserve web resources that should be enough for dozens of phones. But that does not matter, since quality has been put in the right place.

When it comes to costs of quality, in addition of right timing the costs should be concentrated in where they matter the most. End user products should concentrate on user experiences. That is also business risk planning.

If you plan on going to the market at an early phase and you have chosen to do it at the cost of quality, ensure that you have at least tested the right things. The things that influence how you will be received at the target group.

More About the Purpose of Testing

11. Novemberta, 2009 | Kirjoittaja: Antti Niittyviita

Let us continue the topic from last week. In that text, I claimed that figuring out the purpose of testing reduces the amount of unnecessary work. Let us go a step further.

The purpose of testing is defined ultimately by that optimum level, where the sum of external and inner costs of quality is as small as possible. To greatly simplify, external costs of quality mean the expenses arising from returned products, pullbacks, losses of image etc. Internal costs of quality mean the expenses arising from testing and fixing bugs while the product is still in development.

To illustrate, it looks something along the lines of:

(English version of the picture)

Defining the optimal level on a principal level is quite straightforward. One can figure out one’s own testing expenses with adequate accuracy and one can influence them with things such as tools tailored for its function and by developing processes further. In other words, one can lower the slope for accumulating expenses. It is easy to understand that bug hunting and fixing for an eternity does not serve the financial results.

The primary source of information for evaluating future costs for external expenses is to go through the ‘after costs’ for earlier projects. Enterprises that have become stable have hopefully saved such data, but in the case of fresh enterprises, this can be problematic. One might not have enough project history. Then, one needs to define optimal level according to the best estimate.

What do you think? Would Sampo Bank do something different with the testing, if it were to now start a renovation project for the web bank? Or the people who implemented the electronic voting system?

Testing is not an item of expenditure, but an investment. Investing in testing serves the purpose of finding bugs at the cheapest possible development stage. Treat testing like any other investment: Systematically and with respect.

Why Do We Test?

6. Novemberta, 2009 | Kirjoittaja: Antti Niittyviita

Earlier in the entry ’Up the Feature Manager’s Alley’, Antti wrote about a project that had used quite a creative and agile test case updating. When a test case at a critical point for the project had been marked as fail, the test was changed in a manner that made the result end in a pass.

What is the point of testing? It could be that a test case was just so specific and improbable that you needn’t heed its result. But then, such a test case should not have been made in the first place.

How many projects actually even think as to why something is tested?

Cem Kaner remarked in his article ‘What Is a Good Test Case’, that the purpose of testing should be kept in mind at the planning phase of the testing. How else could we define the testing resources, tools, plan the test cases etc?

Let’s open Kaner’s thoughts a bit. The purpose of testing is defined by the test target, the testing phase, target’s and the significancy of the use purpose, and so on. After these definitions, the purpose of testing can be one or more of the following:

  • Minimizing the expenses of tech support and customer service. Try to find the bugs that result in a lot of calls to tech support. Such item could be, for example, the Internet services of a bank.
  • Minimizing the litigation resulting from safety. Discovering bugs that could result in accident or injury are at top priority. A crashing air traffic control software can cause cold sweating to the supplier.
  • Checking in relation to the software specification. Test only the specification requirements, don’t test any other possible combinations. This does not really suit end user products :)
  • Find ways to use the product regardless of bugs. Even though some method does not function according to the specification, the bug is not critical if you can bypass it. Software users have likely become accustomed to this.

The list is far from perfect, but should work as an example. If the feature manager would have specified the purpose of testing before the testing phase, there would not have been a) any unfit test cases to be planned, or b) any ‘wrong’ test results.

Stop for a moment, before you start testing. Clarify to yourself and for your team what exactly are you testing. Futile flailing about gets reduced. You save nerves, time and money. Furthermore, the chances of project making its way through grow significantly.

Do you, dear readers of the blog, fully clear as to why some things are done? Please, share good or bad experiences.