NVP Software Solutions

Tag: QA

  • 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).

  • Testing for System Integrators – Part 2

    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 asked two $10,000 dollar questions and this week we promised the possible answers. Unlike the questions, which are specific to the final client and the suppliers, the answers are more general and apply to both.

    1. The contracts state the following specifically about Quality Assurance and everyone is in agreement
    2. The contracts says nothing about it so far but we have Quality Assurance as a topic and the contract will not be finalised without this discussion
    3. The contracts 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 contracts about Quality Assurance and we can look it up for you (contracts are signed).
    5. There is nothing in the contracts (contracts are signed) and there is no intention of putting anything in the contracts 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 good to terrible 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 you may be in time to effect some change. If you get the last few answers, you are in trouble!

    Next Week: What to do with the answers.

  • Testing for System Integrators – Part 1

    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.

    The $10,000 Quality Assurance question.

    Last week we promised the $10,000 Quality Assurance question. But in fact, there are actually two questions with several variants and here they are:

    1. What did you request from your vendors in terms of Quality Assurance?
    2. What did you promise your final client in terms of Quality Assurance?

    Taking the first question into consideration, here are other things to consider:

    • What does the contract state about Quality Assurance or Software Testing?
    • Are the expectations documented?
    • What can we demand in terms of proof?
    • What are the System Integrator’s deliverables to the vendors?

    Now take the second question about promises to the final client, and the above becomes reversed.

    • What does the contract state about Quality Assurance or Software Testing?
    • Are there expectations documented?
    • What is expected in terms of proof?
    • What are the System Integrator’s deliverables to the final client?

    A System Integrator often acts a bridge with some support provided, but if the one requiring the testing cannot answer the above two questions and the subsidiary questions as outlined, then more research has to be done before the project starts. Without answers to these two questions, it will be very difficult to get started on Quality Assurance activities and be successful in the process.

    Next Week: Answers to those questions…

  • Testing for System Integrators

    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, 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.

    This week we will take up the component parts before launching into a discussion of the Quality Assurance aspects in the next few weeks

    Suppliers

    A Systems Integrator brings together products from suppliers. Frequently these products already exist or they will be built upon a platform. They are not likely to fit the final customer needs 100% since anything that is generic and not custom built (and even custom built products sometimes) will not have been originally designed with the customer in mind.

    Final Client

    The final client is looking for a custom built solution (made from components) that will suit their needs and will work the way they need it to. It must be fit for their use when installed. It may be a new install of something; it may be an upgrade of something that already exists or it may simply be replacing a component. Whichever it is, the final client is paying the System Integrator to make the components fit together and integrate with their existing systems in the prescribed manner.

    System Integrator

    Integrators are the ones providing the glue between the various components and making sure the final solution works. They need to know what the specific APIs for the bought products; the way it is going to fit into the final client and a myriad of other details that go alongside. They must also convey these back and forth between the Final Client and the Suppliers.

    Next Week: The $10000 Quality Assurance question.

  • Software Testing Centre of Excellence – Part 6

    As we mentioned throughout this blog series Software Testing Centre of Excellence can mean different things to different companies, groups and organizations. Because the meaning os a Software Testing Centre of Excellence is so vast, we have defined the various types we have come across in our work. Last week we talked about a Centralized Resourcing Group in Software Testing Centre of Excellence – Part 5. This week we want to focus on:

    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.

    This is not at all new. Centralized software testing departments through which all projects in the organization are funnelled have been around for years. As a matter of fact, I started my career in that type of department. This type organization can have all the benefits listed for the other types as well as some of the problems. For example, in a dedicated department, there is probably some room for research on techniques and tools. They can probably justify the best testing tools for the organization and will be able to keep them up-to-date. They will also probably make full use of the functionality rather than just a subset. They may also be able to leverage the tool and tests across several projects. Resources can also be moved and allocated according to the highest priority and their particular skill sets and strengths.

    However, there can be a couple of major concerns that need to be addressed:

    1. There can be conflicting priorities as projects arrive according to a Poisson Distribution.. This can make planning difficult.
    2. As a result of number 1, project managers may decide to try and avoid the testing department with creative excuses like my project is too small or on too short a schedule.
    3. The last concern may be to justify the value which is being provided by the testing department, particularly if they are viewed as a bottleneck or lack management support.

    If we can overcome those objections we are in good shape.

    Next week: Software Testing for System Integrators

  • Software Testing Centre of Excellence – Part 5

    As we mentioned in our first blog, a Software Testing Centre of Excellence can mean different things to different organizations. Because the Software Testing Centre of Excellence can mean so many different things, we have been defining the various types we have come across over the past few years. Last week we talked about a Testing Tool Support Group in Software Testing Centre of Excellence – Part 4. This week we want to focus on:

    A group that supplies resources to projects as required. This group has a pool of software testers who are seconded to projects on an as needed basis and then returns to the Testing Centre of Excellence when the project winds down.

    This group is a centralized resource provider within an organization. The members of this group are experts in testing and frequently have to be, or become, experts in the Line of Business of the groups they support. Depending on how testing is viewed in the organization (and we have seen both), the resources who are going to the group are either welcomed as valuable assets on the project helping to improve results or they are perceived as a nuisance causing project delays and missed deadlines.

    This type of group requires a lot of coordination within the organization. Projects and resource requirements need to be determined well in advance since many projects may have similar schedules and require the testing resources all at the same time. There will also be competition for the ‘good’ resources (however good is defined) and people may avoid the “not-so-valuable” resources since they don’t help the project.

    This group is much more focused on delivery (which some people consider critical for a Centre of Excellence) and will definitely be involved in project successes and failures. Our last discussion (next week) will be on the centralized testing group.