NVP Software Solutions

Tag: Quality Control

  • Communication in Testing and QA – How to Communicate

    Communication in Testing and QA may seem pointless in today’s over-communicated world. We can use so many methods of communication that the point may seem more like how to stop sending or receiving so much information rather than the reverse. That is missing the point of this particular topic. Communication is listed as the number one skill required in testers.

    The second question in our series is how to communicate. Again, this may seem like an unimportant question when there are so many methods of communication. Actually it is more important than ever. With so many methods of communication how do we make sure our message stands out to the final recipient. Clearly marketers spend a lot of their time thinking about this question and experimenting with various methods to get the attention of their target audience. Equally obviously, some Quality Assurance or Quality Control communication is mandated by the tool that exists in the organisation or the process that has been determined. For example, defects (or whatever they are called in your organisation) are often put into a tool and communicated via a workflow. There is ‘little scope for the imagination‘ in that process. However, for every other piece of communication the question of How it is communicated is critical.

    For example:

    1. We want to convince a large group of people to follow a certain path and also solicit their feedback – personal presentations to small groups may be the most effective even if it is time consuming
    2. We want to demonstrate the superiority of one methodology over another – graphs and charts may be the most effective even though we may think the answer is obvious
    3. We want to tell everyone some good news – a newsletter or announcement via electronic communication may be best even if we want to tell people in person

    We have only really scratched the surface of types and possibilities here. There are thousands more.

    Final Blog of the Series: Communication in Testing – Message; Audience; and Transmission Method

    Next Blog Series: Testing Centre of Excellence

  • Communication in Testing and QA – What to Communicate

    Communication in Testing and QA may seem pointless in today’s over-communicated world. We can use so many methods of communication that the point may seem more like how to stop sending or receiving so much information rather than the reverse. That is missing the point of this particular topic. Communication is listed as the number one skill required in testers.

    The first question is what to communicate. Again, this may seem like an unimportant question when everyone has the ability to know everything. Actually it is more important than ever. With the rise in volume of communication (although not the quality) the need to filter out extraneous information and provide the relevant information and only the relevant information is more critical. It is trivially easy to incorporate lots of material into each communication and hit Reply All. The net end result is lots of information but little content.

    So the initial question that needs to be addressed is ‘What is the content of the message’. While many people know the content of their message, few take the time to think it through in detail. It is assumed that whatever content has been placed in the message (frequently without thought) is correct, sufficient and not too much.

    The content of the message is one of the three most important items:

    1. What does the person, with whom you are communicating, need to know?
    2. How should that information be presented?
    3. What will help them make a decision or act as we want them to based on what we send them?

    These are all pieces of the content that need to be considered just before hitting that Send button.

    Next Week: Communication in Testing – How
    Final Blog of the Series: Communication in Testing – Message; Audience; and Transmission Method

    Next Blog Series: Testing Centre of Excellence

  • Communication in Testing and QA

    Communication in Testing and QA may seem pointless in today’s over-communicated world. We can use so many methods of communication that the point may seem more like how to stop sending or receiving so much information rather than the reverse. That is missing the point of this particular topic. Communication is listed as the number one skill required in testers and only yesterday employers were lamenting an inability to find personnel with the following three characteristics:

    1. Experience
    2. Soft Skills (including communication)
    3. Technical skills

    We cannot necessarily do much directly about items 1 and 3 above but we can certainly look at the second one in a general context.

    Obviously we are trying to convey information and that information is intended to allow people to make decisions as a result of that information. In the case of testers:

    1. It may be a Go/No Go decision on whether to promote a release to production
    2. It may be a priority decision on fixing a defect
    3. It may be a decision on continuing testing a particular release or set of code
    4. It may be a decision on whether to include or exclude a certain feature
    • We need to communicate.
    • We need to make sure the message reaches the right person or people.
    • We need to make sure the message is provided in the correct format.
    • We need to make sure that the message leads to the correct decision.

    Of those four points, the last one is the most important.

    Regardless of decision being made as a result of the information, there are several important questions that are even more critical in today’s over-communicated world and these will be the discussions for the next few weeks.

    Next Week: Communication in Testing – What
    Following Week: Communication in Testing – How
    Final Blog of the Series: Communication in Testing – Message; Audience; and Transmission Method

    Next Blog Series: Testing Centre of Excellence

  • Malthus on Testing – Rapid Testing

    Malthus on testing is not something that you hear often. Thomas Malthus was an English cleric and scholar, who said “The power of population is indefinitely greater than the power in the earth to produce subsistence for man”.

    Last week we discussed how Automated Testing has met or is going to meet its Malthusian Catastrophe fairly soon. While there is no doubt that automation has added greatly to the volume of testing that can be completed, it can be argued that the exponential increases in functionality that are easily programmed but not see easily (fully) tested will eventually overwhelm the scripts.

    Some people will advocate other methods of testing under one heading or another without explicitly mentioning the fact that everything is Risk Based. If the time or resources or both are limited, then people will use their knowledge to get as much done as possible within the available time and with the available resources. They will assess the risk and make an informed decision about what can be completed in the available time. They will assess the context in which they are working and determine what needs to be done. They will use their knowledge and experience to determine what to do. We have done this for years and there is nothing new about it. There are various techniques that can be followed to make sure that risk is reasonable. There are work processes and methodologies that will help.

    We can apply the above techniques to both are manual and automated testing and buy ourselves some more time. However, it is only a step along the way; not a solution

    Final Series Week: Malthus on Testing – New Paradigm. We will propose a new method or paradigm for testing that will address some of the problems.

    Next series: Communication in Testing,

  • Malthus on Testing – Automated

    Malthus on testing is not something that you hear often. Thomas Malthus was an English cleric and scholar, who said “The power of population is indefinitely greater than the power in the earth to produce subsistence for man”.

    Last week we discussed how Manual Testing met its Malthusian Catastrophe a long time ago. One of the proposed solutions to this issue was to Automate the testing using a variety of tools and processes. Certainly that allowed multitasking on the part of the tester. Automated tests could run on one machine ‘unattended’ while the tester concentrated on items that either could or should not be automated and new functionality that it was too early to automate. Coverage was maintained and sometimes increased.

    However, unless a large effort was made to maintain the automated tests, keep them current with the changing code and conditions, and add new scripts as new functionality was added to the system the coverage either was reduced in real terms or at least relative to complete functionality of the system. There are some organizations that actually claim to have all the automation they need to properly test yet have no idea of what is in the automated suite or what it covers. There are even those for whom the possession of the automated base, whether used or not is sufficient.

    We improved over manual testing. We did not solve the problem.

    It is quite safe to say that Automated Testing met its Malthusian Catastrophe a while ago. Unless a very large effort is made (usually beyond the efforts of most organizations), Automated Testing is not going to cover sufficient of the code either.

    Following week: Malthus on Testing – Rapid Testing
    Final Series Week: Malthus on Testing – New Paradigm. We will propose a new method or paradigm for testing that will address some of the problems.

  • Malthus on Testing – Manual

    Malthus on testing is not something that you hear often. Thomas Malthus was an English cleric and scholar, who said “The power of population is indefinitely greater than the power in the earth to produce subsistence for man”.

    How does this relate to software testing and in particular, for this week, manual testing? Well if we paraphrase the Mathus’ statement a little bit we could say that the ability of people to add applications is far greater than the ability of people to keep up via testing. Add to that the necessity for regression testing of the existing applications and then the interconnections with other applications that is occurring at large speed and one can see that the possibility of the application functionality and complexity far outstripping the ability of manual testers to keep up.

    A lot of people recognized this very early and proposed a variety of solutions to the problem. We will discuss those in the coming weeks with particular emphasis on Automation and Rapid Testing. Others have recognized the impossibility of keeping up and have resorted to Risk Based Testing. With very few exceptions, all testing these days is Risk Based. We accept the fact that we cannot anticipate completing everything and as a result we make a risk judgement on what is most critical to be completed. The Risk Assessment is based on a lot of assumptions and some of the assumptions are not validated thoroughly.

    It is quite safe to say that Manual Testing met its Malthusian Catastrophe a long time ago. We no longer anticipate covering even a majority of the code.

    Next week: Malthus on Testing – Automated
    Following week: Malthus on Testing – Rapid Testing
    Final Series Week: Malthus on Testing – New Paradigm. We will propose a new method or paradigm for testing that will address some of the problems.

  • Quality Assurance for Startups – Part 2

    In the last blog we discussed why Quality Assurance for Startups was appropriate despite it not being the first thing on startup leaders’ minds. This is understandable given the amount of other work that needs to be done just to get going as a new business.

    It would be pointless to introduce a full Starting-Quality-Assurance process in the beginning stages. The effort involved would detract from the other to-dos and could interfere with growth. With that said, we can introduce a limited Quality Assurance program during the startup stage that will benefit all without adversely impacting the growth of the organisation as follows:

    1. At the end of each week, take 15 minutes and review what has been done and how it is being done.
    2. At the end of each month, take 1 hour and review what has been done and how it is being done.
    3. In both cases, take brief notes and file them.
    4. At the completion of the one month meeting, consolidate the notes and divide them into groupings. For example: Development; Quality Control; Process; Customer Feedback: Recurrent Issues
    5. Look for items that might be costing you money; that are easy to correct and can be implemented immediately.
    6. Look for items that have a medium term to correct and may still be worthwhile
    7. The biggest items to look for are those that may not be easy or fast to correct but may have a big impact in the future if left unchanged.

    If the items fall into the easy category; make the changes now and implement going forward.

    If the items fall into the medium category; try to subdivide them into things that can be done immediately and implement some of those.

    If the items fall into the long-term or hard category; there may be a need to assess how much effort it will require to implement a change.

    We are going to tackle how to implement next week.

  • Quality Assurance – Implementing Right the First Time

    The last three NVP Blogs have discussed Doing it Right the First Time. The last one addresses the issue of Implementing Right the First Time. This is the part that usually trips up most people. They know they want to implement this in their organization. They know how or they can refer to explanations that will suggest how. The problem comes when we try to actually implement the process.

    As is usual with almost any new initiative, we want to follow three precepts:

    1. Start small.
    2. Pick off the easy items first.
    3. Publish the successes.

    Taking these in order:

    Start small
    Start with something over which we have full control or a limited number of stakeholders. Do not start with a mission critical project with numerous stakeholders; that will not work.

    Pick off the easy items first
    A quick analysis will reveal some small and easy to fix items that can be corrected. Sometimes it can be as small as adding a field to a defect report that avoids an extra step further down in the process or removing a step like having Quality Control test a defect as it arrives from the customer before passing it to development and then testing it on the way back out. The second example might have had use at one point but no longer makes sense. A third and frequently easy place to look for improvements is in items that have been made redundant by technology changes. These can include printing items that are now easily stored online or even still testing installation disks for a hosted system.

    Publish the successes
    Even though this is third, it requires some upfront thought. We need to know the current situation and statistics before we can determine whether improvement has occurred. So even though this is the ‘last’ step it must be considered early.

    Rule 3: Take a step back; look objectively at your process; pick off a few items that can be improved; check the current situation; make the change and measure again.

    This is the first step to implementing Right the First Time or Quality Improvement in your organization. Next week; an anonymous example of How Not to be Right the First Time.