Tag: Centre of Excellence

Is there any difference between software and manufacturing?

Last week we participated in a preparation session for an upcoming webinar. The person we will be presenting with is involved Quality Management for Products while I was representing Software.

It was quite surprising how similar we sounded in terms of what we do:

1. Product Planning Phase turning into Requirements.

2. Design Phase
3. Testing Phase
4. Production Phase
5. End-of-Life

• We both wanted measurements and opportunity to institute process improvement.
• We both looked at the entire lifecycle.
• We both looked at training as a method of attaining Quality objectives.
• We both end up with a product.
• We both wanted to add process improvement at all stages.

There does not seem to be a lot of difference. But, then again, we took our Quality Assurance from Crosby, Deming and Juran.

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

Photo by Maria Jose Oyarzun on Unsplash

Was it a Hack or Poor Testing?

Recently we went to a restaurant for a quick dessert (pick up only at the current time). Usually this restaurant is quite fast and we have our order and are out within a few minutes. This time, to minimize the number of people in the restaurant, only one person went in and the rest of us stayed in the car. For a little while we did not worry – it was a busy time and there was a line up at the drive through and quite a few cars in the parking lot. However, by the time we had been sitting for 20 minutes catching up on mail, reviewing calendars, and reading it began to seem like a long time. The lightening storm to the north was quite good to watch also so that passed some time.

Then we began to get text messages from the person inside.

When they came out, with the order in hand, we got the full story.

1. Order was submitted at the counter (not via the machine) and a receipt with number obtained.
2. Many other people were also waiting.
3. Drive through orders were being run out to the two waiting spaces (which was probably an indication of problems).
4. Then the trouble began.
5. The orders were disappearing from the screen one by one.
6. Then the entire screen went blank.
7. Once that happened, no orders were filled.
8. The person in the restaurant had to go back to the counter to get the order filled and eventually came out with it.

• Was it a one time Hack of the system?
• Was it some sort of bug?
• Was it the storm affecting the system – there was a lot of lightening?

We never found out but we did hear that there had been a similar problem a month earlier when another family member went to the restaurant to pick up supper. That seemed to be too coincidental so we suspect poor testing.

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

Photo by Charles Deluvio on Unsplash

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

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