NVP Software Solutions

Tag: QA

  • Software Testing Centre of Excellence

    A Software Testing Centre of Excellence seems to mean different things to different people and organizations. Over the past year, NVP Software Solutions has talked to a lot of Testing Centres of Excellence to have found that one year later these Centres have complete disappeared or have   shrunk so far down that they are now irrelevant. Because the Software Testing Centre of Excellence can mean so many different things, we wanted to define the various types we have come across. These different types of Testing Centres don’t even appear to have defined names, so here are the descriptions we’ve come up with:

    1. A research group that looks for best practices inside and outside the organization in order to become widely accepted within the organization and important to be used.
    2. A group that supplies support to testing endeavours. This type of group does not do testing; they supply expertise or a repository of information that supports other groups in their testing efforts. Sometimes they also have templates and guidelines that support the required documentation.
    3. A team that supports one or more test tools in the organization. This group may hold the administration rights to the tool; be responsible for the initial configuration; set up projects within the tool (if applicable) and generally provide support.
    4. A group that supplies resources to projects as required. This group has a pool of testers who are seconded to projects on an as needed basis and then return to the Testing Centre of Excellence when the project winds down.
    5. A team that actually delivers testing. This is like a centralized testing department through which all projects have to go in order to be certified ready for production.

    The gradations here are fairly obvious, we are moving from a purely theoretical group to a highly practical group. Many of them still do not last for an extended period of time and some are managed by people with no background (and sometimes no interest) in testing.

    Next Week: Further discussions of TCoEs.

  • Communication in Testing and QA – Message, Audience, Transmission Method

    With all of the ‘communicating’ we do in today’s world, Communication in Testing and QA may seem like a redundant addition. The methods of communication available are endless, to the point, where the pendulum might start to swing the other way, towards a world that reduces the amount of communication we have in our lives. However, when it comes to software testing, quality assurance and quality control strong COMMUNICATION is the number one skill looked for in for software testers.

    We have already discussed WHY, HOW and WHAT to communicate in other blogs within this series and the final components to tackle are Message, Audience and Transmission. When sharing information and data, it is essential that you consider your specific message, who the intended audience is and the way in which you wish to transmit that information based on the previous criteria. Those who carefully consider and plan these components of communication get their views and insights heard and acted upon much more constructively than their counterparts who do not consider these three things.

    Start by thinking about the message you are trying to send? Is it advice, a warning, a compliment or technical information that increases the efficiency and success of your department? Whatever the message, clarify it and exactly what you are intending to convey. If you can do this in a few short sentences, you’re off to a good start. Your message should be short, concise and to the point. If there’s no point, there’s no point in wasting your time or the time of your audience.

    Speaking of audience, who exactly is your audience? You need to figure that out, because your audience may be the most critical piece to consider. Who are you trying to reach and under what conditions? There are many recipients for every message and specific knowledge of who those recipients and how they react is a determining factor in how successful your message will actually be.  People speak differently to their boss then they do to a peer, subordinate or close work-friend. You speak differently to your neighbour than you would to your spouse, children or relatives. Fully understanding your audience allows to you craft the content of your message in a way in which you think they would best receive the information being shared.

    When you have identified the message you are trying to send and the audience in which you are sending to, you can determine exactly how your piece of communication should be transmitted. How is it best to attract the attention of the intended Audience and get the Message we want across. We covered a number of these in an earlier blog.

    We also need to keep Marshall McLuhan in mind when considering this. ‘The medium is the message.‘

    Next Blog Series: Testing Centre of Excellence

  • 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 – A New Paradigm

    Last week we completed our discussion of how the proposed solutions to the Malthusian Catastrophe are only postponing the inevitable. Unlike development which can always go forward and create new code, testing always has a regression component for any code that integrates with existing applications. This adds  to the testing effort but doesn’t necessarily add value.

    The proposal we outline here is not entirely new although we are carrying it to another level. Portions of this are being done and have been done for years. However, we are suggesting a more intense and more rigorous application.

    Today, we find many people integrating applications to build something. They can borrow code or entire applications and make something new from it. The statement “there is an app for that” has never been more mainstream. However, everything that is borrowed or utilized may (not always) need to be tested to some level so we can trust that it does what it says it does and operates the way we need it to in our new configuration. Add to that Security concerns dealing with applications that are not under our control and may not have been built to the same level as we need and the chance of our new application failing increases substantially.

    We are recommending that a library of code pieces are created that have the following characteristics:

    1. They carry out a known function under known conditions.
    2. They have been tested thoroughly by an independent entity to prove number 1.
    3. They are secure from being compromised.

    Number 2 above may have levels of testing just like there are levels of code today depending on the risk of the application for which they are being used but the same process applies.

    People developing applications would be able to use this library secure in the knowledge that the three points above are guaranteed.

    Next series: Communication in Testing,

  • Starting Quality Assurance – Part 4

    Starting Quality Assurance can be difficult when there are existing projects already on the go, new projects starting up and operations running at full speed. There never seems to be a good time to say “We are going to launch into Quality Assurance activities and start improving our processes”.  There will always be a more important operation or project related activity that needs to be solved and that takes precedence.

    Last week we discussed How we would want to start Quality Assurance. This week we want to look at a few examples.

    It would be nice to implement a complete Quality Assurance program using a Big Bang approach. We would decide all that needed to be done; implement all the changes and move forward. That rarely works (especially in an existing organization) and is often followed by a gnab gib (which is a Big Bang in reverse) also known as the Big Crunch. Or else we end up like the day Sweden switched the driving side.

    Since we are not dealing on a universe or country level, we can pick and choose what to do first.

    Some obvious examples include the following Quality Control Processes;

    1. Centralize defect reporting for a single project in a tool.
    2. Centralize test case management for a single project in a tool.
    3. Create standards for defect priorities and severities appropriate to your organization.
    4. Add a checkbox identifying test cases that might be needed for regression and start designating the test cases as they are being executed.
    5. Set priorities on test cases so we know which ones are important.
    6. Carry out a minimal informal Lessons Learned on a small project. No formal report is required at this stage; just people’s opinions.
    7. See what reporting could be made available without impact on the people who are testing.

    In all cases we are looking for small easy to implement changes that people can do with minimal adverse time impact.

    Next Week: Malthus on Testing

  • Starting Quality Assurance – Part 3

    Starting Quality Assurance can be difficult when there are existing projects already on the go, new projects starting up and operations running at full speed. There never seems to be a good  time to say “We are going to launch into Quality Assurance activities and start improving our processes”.  There will always be a more important operation or project related activity that needs to be solved that takes precedence.

    So, the third question we want to answer is How. Last week we discussed When we would want to start Quality Assurance and the next step is to decide How.

    The quick answer is with a minimal effort and hopefully a positive Return on Our Investment. We already discussed a somewhat similar question in our blog on Quality Assurance for Startups. The argument is similar; we need something we can do alongside everything else and yet improves our ongoing processes. The only real difference is that a Startup usually lacks any processes at all while an existing organization may have lots of processes; some of which may conflict with the new processes we want to introduce. As a matter of fact that will be the biggest impediment to this process.

    So the process differs a little:

    1. Identify the process that we want to implement.
    2. Identify the small steps needed to implement the change.
    3. Identify the impacted processes already in existence. This is the important difference.
    4. Plan around the existing processes or identify the small (again!) steps that are needed to change that process.
    5. Implement the dependent steps.
    6. Implement the new process steps.
    7. Measure the result.

    Obviously the key concern is that we may end up with too many dependent steps that stop the new process from moving forward. We could end up changing all the other processes and never get to our desired end result. That is why it is critical to have clear measurable goals in view for all the processes that are being changed.

    Next Week: Examples