Why is Shift Left not occurring?

Recently NVP contributed to a blog on why Shift Left was not occurring. Speaking as someone who has experienced it from a Test Lead position, our concern was the inability to free up resources while still continuing with existing testing. The full article can be found here.

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

Photo by Charles Deluvio on Unsplash

Recently I was asked to provide a short history of a local Quality Assurance organization.

Starting with the previous organization, I went through the 25-year history in about 5 minutes. The one major overriding change in those 25 years was the advent of the internet that created a vast information trove that is free to all. Prior to that, people were isolated within their organizations with limited contact with people with the same interests in other organizations. Solutions to problems were generally home-grown.

Having provided that very brief synopsis we were left with three questions about the purpose of the organization:

1. Are we an organization dedicated to networking?
2. Are we an education organization?
3. Are we a social organization?

Unfortunately we do not have enough of the history documented to determine what has been the best use of the time. Clearly my synopsis was based on what I remembered and I was not always in attendance at all the meetings or always on the board. So the question is still open.

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

Photo by Jon Tyson on Unsplash

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