One of the problems QA people have is deciding how much proof is enough. 

Proof is expensive and time-consuming to generate.  Even with the current test tools taking screen images and storing them, you may have to annotate the proofs and combine them with other items to send to various places.   You may want to weed out items you don’t want and add things that are missed.  Having done all of that and made a nice package, you then wonder if anyone ever looks at it.   We have had clients look and some clients need it for regulatory purposes.  However, a lot want to know it is there and they could look at it if they had a need but they don’t ever open up the package and look. 

Of course it also gets superseded with new executions of the test case, new test runs or simply new code.  Sometimes the proofs accumulate in the test tool or a directory until they overwhelm storage and get put onto backup just in case they are every needed.  Eventually either they can no longer be read or someone cleans up all the old backups.

We have two major questions:

1. Are the proofs necessary?
2. How long should they be kept?

The answer to the first question depends on risk, and the ability to learn and use items from the past.  There is no doubt that higher risk items need more proof and it needs to be kept.  But the second part is even more critical, can we use the value in the proofs to inform future testing efforts in the software.  Often a second review will identify other items that might have been missed either in the existing proof or in test coverage.

The answer to the second question is actually a process that should exist for all documentation.  There is an absolute upper limit in terms of years after which, if the proof is that old and the testcase has not been re-executed in all that time, then it is not likely it is going to come back.  Alternatively, if the testcase has been executed multiple times since the the original proof was stored and all the subsequent proofs have been retained, then we will not be going back and it is probably safe to discard the older proofs.

Either way, we do not keep everything for ever.

If you have input on the above, you might want to consider our survey.

Photo by Bekir Dönmez on Unsplash

One of the problems QA people have is explaining Software Quality Assurance to IT or to the business. 

Some people will talk about Software Testing.  Others will refer to Test Automation.  Still others will refer to Process Improvement.  Some will start down the path of Types or Phases of testing and explain all those terms.  Test Strategies and Test Plans will start to fill the room.  Test Cases, Actual Results, and Expected Results will proliferate until the explosion occurs.  Finally there will be references to that elusive animal: The software bug.

For people in IT, these references may mean something.  For people not in IT, the eyes start to glaze over very quickly. 

We are left with the question of what do you do and how does it benefit me plus a request to put it in business terms.   

If you have been in this position of knowing what you do and just how much time it takes and how much it all costs, this question can be frustrating or annoying.  Many people feel they could have dealt with a dozen test cases while trying to explain it.

Eventually, the Software Quality Analyst despairs of making the user understand and asks for them to just leave them to get on with their work.  This never works!

The business may leave for a while, but they always will come back with the same question and they will start to regard the Software Quality Assurance department as a Cost Centre.  That is also not good.

If you have been in this position contact us to watch a short powerpoint presentation that puts the above into Business Terms.

If you have input on the above, you might want to consider our survey.

Photo by Bekir Dönmez on Unsplash

Normally one of our mantras is as little paper as possible.  Only ink signed contracts or items that should not exist online longer than necessary would be printed.  So far we have succeeded in cutting the paper to a minimum.  Less than 20 pages for all the work to date this year.

However, was talking to someone this afternoon and some of the following conditions came up:

1. Testcases must be printed since it is not possible take a computer, laptop, tablet, or smartphone to the place where they are to be executed.  Paper is the only medium (plus a good writing device called a pencil).
2. The test report must be filed on paper (regulation).
3. Some items are secret and cannot be put into a computer system for security reasons.  Paper is the default storage.
4. Some of the items that are stored in the computer system are only to be printed for if sufficient security clearance is provided.

So despite an attempt to reduce the paper usage to a minimum, we have not got rid of it entirely.  There are places where it is just not practical.

Please let us know of ‘unavoidable instances of paper usage’.

If you have input on the above, you might want to consider our survey.

Photo by Sven Brandsma on Unsplash

Managing in Uncertainty

Starting a course today on “How to” for Test Leads.  Normally we would supply this course in person and with the group in one room.  Under the current conditions, that is not possible, so the course is being supplied remotely with the participants being scattered across the province.  So this is an experiment.

As a Team Lead, one of the issues is interactions with the team and that is clearly different when managing a Team Remotely (as opposed to Managing a Remote Team).  We added a number of items around:

1. Improving your virtual communication
2. Remote Management
3. Remote Communication Skills
4. More visibility
5. Starting with yourself.
6. Communicate, communicate, communicate, and if in doubt Communicate
7. How to Lead with Care and Focus
8. Usage of Tools.

It will be interesting to see how it goes.  

Give us a call to discuss after Wednesday.

If you have input on the above, you might want to consider our survey.

Photo by Sven Brandsma on Unsplash

QA as an Afterthought

Continuing with the theme from last week about recalcitrant IT, we ask why QA is often an afterthought?

1. Is it because QA is ‘traditionally at the end of the project”?
2. Is it because people have too much else going on at the beginning of a project and cannot think about QA?
3. Is it because QA does ‘not fit anywhere’ at the corporate level so ends up nowhere?
4. Is it because QA is regarded as a necessary evil which no one wants to acknowledge?
5. Is it because we do not know when QA is  needed and by the time we find out it is too late to make a difference?
6. Is it because QA does not do a good job of selling ourselves?
7. Is it because …

We could certainly go on with all the reasons that QA seems to be frequently ignored. 

Not surprisingly, when people do take the time to consider the Return on Investment for QA, they are often shocked by how much it benefits them.

Give us a call to discuss.

If you have input on the above, you might want to consider our survey.

Photo by Alev Takil on Unsplash

Just finished a short article in the latest Economist called “Why companies struggle with recalcitrant IT”.  (July 18, 2020 Edition).

Several points stood out:

1. The usual list of IT problems that get mentioned in the press.
2. It is recommended that planes be turned off and back on (rebooted) to stop the software from displaying incorrect information mid-flight.  Wonder where we have heard that before (except not for a plane!).
3. Programming is a mix of literal and creative.
4. New companies start with a blank slate while older companies struggle with legacy code which may or may not do what it says and is often poorly documented.
5. Very small errors can cause a computer system to work very differently to what was expected.
6. Programming is partially self-learned and has few standards.

None of these problems are new.  They have been in the industry for years and often gets the IT a very bad name.  Sometimes deserved but not always.  

Given the increasing role of software in the world, how much longer can we continue with this methodology?

If you have input on the above, you might want to consider our survey.

Photo by Lauren Mancke on Unsplash

1. There has been a change in direction with regard to Quality Assurance and your services are no longer required.
2. The Quality Assurance department has not changed in 18 months (the average half life) therefore we need to reorganize it.

Stop me if you have heard either of the above before (but keep reading). If you have not heard those items then where are you?

This came up as a result of a conversation with a long term friend who had the first one occur to him after multiple years at the same organization. The second one we have seen so often, we have lost count. Either the department is centralized or dispersed but it never seems to settle anywhere for any length of time.

What is interesting in either case is the following:

1. Quality Assurance still gets done despite the change in direction.
   • It gets renamed as something else but is still done.
   • it get reassigned to someone else or to another group but is still done.
   • It gets stopped for a few months until a crisis hits either internally or from a client and then it is suddenly reinstated.
2. There never seems to be a happy medium where some obvious functions are centralised and others are dispersed according to need.
3. There is no plan to move people back and forth and supply them with training until the pressure or poor quality become an issue after which there is a major catchup

If you have input on the above, you might want to consider our survey.

Photo by Lauren Mancke on Unsplash