NVP Software Solutions

Category: Uncategorized

  • Quality Assurance Centre of Excellence – Part 3

    This blog series will on the Quality Assurance Centre of Excellence. Last week we covered the proactive aspect of a QA CofE. This week we want to focus on the analytic component.

    Analytics – The analytical aspect of quality assurance looks at data and analyzes what went right and what went wrong. Information comes from statistics and Post Implementation Reviews. The Quality Assurance Centre of Excellence gathers the data, collates it, and then provides information based on that data. They may act on the data, or they may simply pass the information along assuming that someone else will act on it within a specific project.

    Gathering analytics is probably the most traditional role for a Quality Assurance Specialist. They gather statistics from current processes and analyze them to determine what is working well, what can be used elsewhere, and what needs to be fixed.

    There are two challenges that the Quality Assurance Specialist usually faces:

    1. Data is gathered because it always has been and information continues being gathered whether or not there is any current use or anyone even viewing it.
    2. The Quality Assurance analyst carries out all sorts of detailed analysis and then nothing is done with the results. This can be very discouraging and isn’t a great use of time and work efforts.

    There are ways of addressing the above two above challenge:

    First, there should be a yearly review of all the statistics gathered with insight given as to if, how and where they are being used. This is not a review of the value of the information, it is simply a statement of whether they are being used somewhere in the organization. More extensive reviews might ask the deeper question of the value of any use of the results.

    The second challenge above is a little harder to deal with. Part of it can be addressed by ensuring that any new requests for results do have value (being Proactive) and then look at why the existing items are not being used. If they do not demonstrate some value to the organization, then they are not going to be used. Again, we want to ensure the initial request for the analysis has value attached; ongoing value is being demonstrated, and the yearly review incorporates this component to make sure it is still of value.

    Now that we have all the information, we can start using it proactively to help make our current work and initiatives more efficient.

    Next week Root Cause Focus

  • Quality Assurance Centre of Excellence – Part 2

    This blog series will be focusing on the Quality Assurance Centre of Excellence. Last week we covered the different concentrations of the QA CofE. This week we want to specifically focus on the proactive component.

    Be Proactive – In this scenario the Quality Assurance CoE would be looking ahead and seeing what can be anticipated. They could be looking at coming projects; coming changes in organization direction; new technologies that might impact the organization; and the entire environment in which the organization operates in an effort to anticipate the impact on technology. Big data and security come immediately to mind for many organizations. There is almost no end to what could be considered.

    So where do we start? The answer is we start with what we are currently doing in terms of projects, technology, and reacting to the environment. This is sometimes called Setting a Baseline although we may need something more general than that. We may also need to go into the past a little to get understand overall trends. While some things can change  overnight, a lot of the major trends are obvious many years in advance; just not recognized at the time. We can use the quote from George Santayana here. Once we know where we have been and where we are now, then it is time to look at the competition to see where they may be ahead of us or where they appear to be going.

    Now that we have all the information, we can start anticipating what might impact our organization.

    1. Is the environment going to change? If it is a government driven change, it is rarely a surprise and can be anticipated. We start to position ourselves to be ready for the change so it is a non-event for us when it occurs.
    2. Is technology going to change? YES – that’s inevitable. But, what impact will it have on my particular business and how fast will it happen are the more important, harder-to-answer questions. We need to look at our customers (How quickly do they start using new technology?); our own organization (What is the history of technology adoption?) and our competitors (Are they using technology to get ahead of us). We start to position our development and Quality Assurance groups to be ready for this new technology.
    3. What are the coming projects? This means that we need to be involved in the planning processes at the highest level. Only in that way can we anticipate what might be coming. We schedule incremental changes to ensure that the departments can tackle the new projects with a minimum of disruption

    As was said: “It is difficult to make predictions, especially about the future.”

    It is recommended that you put this on your daily reminder list: What is the potential impact of today’s discussions?

    Next week Being Analytic

  • Quality Assurance Centre of Excellence – Part 1

    You may recall from some of our earlier discussions that Quality Assurance was defined as one or more of the following:

    1. Proactive
    2. Analytical
    3. Focused on Root Causes
    4. Focused on Process

    So, given the above list, what can a Quality Assurance Centre of Excellence concentrate on in order to provide value to the organization:

    Proactive –  In this scenario the Quality Assurance CoE would be looking ahead and seeing what can be anticipated. They could be looking at coming projects; coming changes in organization direction; new technologies that might impact the organization; and the entire environment in which the organization operates in an effort to anticipate the impact on technology. Big data and security come immediately to mind for many organizations. There is almost no end to what could be considered here.

    Analytical – As opposed to the previous section, this is looking at data and analyzing what went right and what went wrong. Information comes from statistics and Post Implementation Reviews. The Quality Assurance CoE is gathers the data, collates it, and then provides information based on that data. They may act on the data or they may simply provide the data with the assumption that someone else will act on it within the specific project.

    Focused on Root Causes – This can be applied to both of the above sections. In the Proactive section, the Quality Assurance CoE could look at Root Causes of potential issues and plan around them or else they could look at Root Causes from their analysis and work to understand and solve them. Regardless of which way this is dealt with, the problem could be dealt with at different levels. We could be looking at Root Causes for software development and deployment or we could be looking at root causes that impact the entire organisation (structure, culture, management).

    Focused on Process – This also applies to all of the above and again can be applied at any level. The Quality Assurance CoE could be looking at very general processes for the entire organisation or very specific processes to resolve a specific problem.

    Next week Being Proactive

  • Quality Assurance Centre of Excellence

    Last week we discussed a misconception about Quality Assurance. Judging from some of the feedback we received, the post struck a nerve. Many people talked about the how they had encountered a similar misconception and what could be done about it. Although education seems to be the answer, it is ongoing and can be frustrating from time-to-time. Does one just leave it alone when people make these comments (even if the one I heard was probably not entirely serious)? Does one attempt to correct the misconception? That usually means starting a long dialogue (monologue?) with sometimes frustrating results. Either people start to glaze over, have something pressing to do somewhere else, or else simply misunderstand what was said (wilfully at times).

    So with all that in mind, we are going to start into a series on what is a Quality Assurance Centre of Excellence. This is more ambitious than a Testing Centre of Excellence which we discussed late last year. One of the criteria that came out of talk I attended last year, was that a Testing Centre of Excellence had to have a delivery component. A delivery component for a Quality Assurance Centre of Excellence is going to be a little harder. This means that this is going to be slightly more of a challenge. We will work through the same hierarchy insofar as it applies to this situation but obviously the emphasis will be different.

    So, having started the plan for the plan which always reminds me of The Siphonaptera next week we will start into the real classifications.

  • Quality Assurance

    Toward the end of last year we encountered a situation where our presence in a project was there to “Assure Quality” or that “Quality was Assured” simply by us being there. Although the comment was made somewhat in jest, it showed a misunderstanding of Quality Assurance that can lead to dire consequences. Quality Assurance is not a standard although it includes standards. It is a process and a journey (and not a destination).

    Quality Assurance looks at the processes that are being used and tries to find places for improvement so that everything can be smoother. It looks for root causes of existing problems and eliminates or reduces their impact so that they no longer impact the process further along. Sometimes this is referred to as “Removing the Rocks in the Stream” so that the flow of the project is smoother. Quality Assurance also tries to anticipate other items that might impede smooth project completion and eliminate those as well. This is why it is never complete. There is likely to be improvements that will still occur and we can continue to identify those opportunitiess. Even if we can’t identify opportunities for improvement it is likely that someone in the organization can see something that can be changed. Every project is slightly different and the opportunities for improvement or to change processes are also different. If the projects are not different, then they can be turned into a standard process and there is no need for any individual improvements. That will still leave process improvement as a possibility.

    It is suspected that the initial comment at the beginning of this blog was really related to Software Testing and not Quality Assurance at all. However the misconception exists.

    Next Week: Quality Assurance Centre of Excellence

  • Testing for System Integrators – Part 5

    Last week our blog discussed the remaining answers to the questions and promised that we would look in detail at two of the answers (which are somewhat similar so we will concentrate on one only).

    There is nothing in the contract (contract is signed) and there is no intention of putting anything in the contract about Quality Assurance.
    Now you have a challenge. Clearly the process is mostly done and there is absolutely no buy-in to Quality Assurance. The next question that needs to be asked is “Why have you brought Quality Assurance in if there is no interest?”

    The key steps here are to determine your position and map out your strategy. There is any number of answers to the question of “Why have you brought Quality Assurance in if there is no interest”.

    1. The final client has belatedly required it. I.e. they have realised it is an omission from the contract and now feel it is incumbent on the System Integrator to provide this as part of the deliverables. You need to determine the final clients needs and work towards those.
    2. The solution is more complex than the System Integrator thought and now they feel a need for Quality Assurance. I.e. like the client above they have realised the value provided by Quality Assurance and now want to implement it even though they were trying to avoid it earlier. There is probably still little buy-in from most of the group. You need to look at each of the Stakeholders and determine their status vis-a-vis Quality Assurance and plan to convert them all to supporters. This is a crucial piece of your strategy in order to be successful.
    3. The System Integrator’s management is becoming nervous and wants Quality Assurance there as a check. While you have management support the team may feel they have an extra burden and possibly someone who is watching them. As in the above, you will need to look at the Stakeholders and see how to convert them to supporters. Otherwise you will get no information at all.
    4. The last possibility is they want someone to blame. This is a tricky one. No matter what you do (either proactively or reactively) they may blame you. You need to plan carefully in order to make sure that your work is recognised as contributing to the success of the project. You need to be very proactive in stating what needs to be done; why it needs to be done and the benefits accruing from having it done. And make sure that everything is documented!

      Happy New year

  • Testing for System Integrators – Part 4

    Over the next few weeks, the NVP blog will focus on Software Testing for System Integrators. From NVP’s point of view, a System Integrator is someone who brings together a number of applications (from vendors), adds some glue and ends up with a solution for the organization they are working with. This seems to agree with the Wikipedia definition fairly closely. So where does Quality Assurance come into this? One would like to think early or very early in the process but that’s not always the case.

    Last week we looked at responses to the first 4 questions. This week we are continuing with the remainder:

    1. The contract states the following specifically about Quality Assurance and everyone is in agreement
    2. The contract says nothing about Quality Assurance but it’s noted as a topic and the contract will not be finalized without this discussion
    3. The contract says nothing about Quality Assurance so far, but now that you have brought it up we will add it.
    4. There is something in the contract about Quality Assurance and we can look it up for you (contracts are signed).
    5. There is nothing in the contract (contract is signed) and there is no intention of putting anything in the contract about Quality Assurance
      Now you have a challenge. Clearly the process is mostly done and there is absolutely no Buy-in to Quality Assurance. The next question that needs to be asked is “Why have you brought Quality Assurance in if there is no interest?” The answers to this and the response will be next week’s blog
    6. We don’t know (but that is a good question)
      There is some hope here and you are in a position to influence the content and results. It may be late in the process but we can try.
    7. We don’t know (and we don’t care)
      This is a similar situation to the answer to number 5. There is a challenge for Quality Assurance and that challenge must be tackled.

    Suffice to say the items in the above list have an obvious gradation from very manageable to a real challenge in the order they are presented. If you get the first answer, you’re well on your way. If you get some of the middle answers you have some work to do, but there’s still time to make change. If you get the last few answers, you are in trouble but not defeated!

    Next Week: What to do with Number 5 and 7.

  • Testing for System Integrators – Part 3

    Over the next few weeks, the NVP blog will focus on Software Testing for System Integrators. From NVP’s point of view, a System Integrator is someone who brings together a number of applications (from vendors), adds some glue and ends up with a solution for the organization they are working with. This seems to agree with the Wikipedia definition fairly closely. So where does Quality Assurance come into this? One would like to think early or very early in the process but that’s not always the case.

    Last week we provided several possible answers to our original

    1. The contract states the following specifically about Quality Assurance and everyone is in agreement
      This means that you simply have to “bridge the gap” between what is expected from the vendors and what is promised to the final client. The only problem may be that you do not agree with the contracted items.
    2. The contract says nothing about Quality Assurance but it’s noted as a topic and the contract will not be finalized without this discussion
      This is almost the best situation. While it may be a little late in the process, the willingness to add Quality Assurance exists and people are behind it.
    3. The contract says nothing about Quality Assurance so far, but now that you have brought it up we will add it.
      The same comment as above is applicable except that there is not quite the backing we might have had earlier.
    4. There is something in the contract about Quality Assurance and we can look it up for you (contracts are signed).
      Well at least they considered it; it may not be correct or complete but it was not entirely ignored. Once you find out what is in the contract you may (or may not) have concerns to handle.
    5. There is nothing in the contract (contract is signed) and there is no intention of putting anything in the contract about Quality Assurance
    6. We don’t know (but that is a good question)
    7. We don’t know (and we don’t care)

    Suffice to say the items in the above list have an obvious gradation from very manageable to a real challenge in the order they are presented. If you get the first answer, you’re well on your way. If you get some of the middle answers you have some work to do, but there’s still time to make change. If you get the last few answers, you are in trouble but not defeated!

    Next Week: What to do with the answers (remainder).