Tag: software testing

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

  • Software Testing Centre of Excellence – Part 4

    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 Support Group in Software Testing Centre of Excellence – Part 3. This week we want to focus on:

    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.

    The endeavours of this group can range drastically. Some of them are simply a repository for the software testing tools within an organization. They are responsible for maintaining the licensing, keeping versions up-to-date and making copies available to project teams or departments as required. They may periodically survey the user community in the organization to see if the tools are being used and whether to keep them (which can lead to the interesting situation where the maintenance and licensing fees are paid by one department yet the benefit is shared by a lot more departments).

    A different and more active role can be very effective. In this situation the following are true of the team:

    1. They identify the most effective tools for their organisation.
    2. They acquire, configure, and administer the tools.
    3. They install or provide the tools to the relevant projects.
    4. They provide resources to the projects and make sure that the test tool is used effectively for the project.
    5. They resolve any issues.

    This group is more focused on delivery (which some people consider critical for a Centre of Excellence) although they may not have direct project responsibility. Discussion of that point will come in our next blog.

  • Software Testing Centre of Excellence – Part 3

    As we mentioned in our first blog, a Software Testing Centre of Excellence can mean different things to different organizations. Over the past year, NVP Software Solutions has talked to a number of Testing Centres of Excellence only to have found that one year later these Centres are now irrelevant or cease to exist. Because the Software Testing Centre of Excellence can mean so many different things, we have been defining the various types we have come across. Last week we talked about the Research Group in Software Testing Centre of Excellence – Part 2. This week we want to focus on:

    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.

    The endeavours of this group can range drastically depending on the mandate. Sometimes the manager of this group will seek to expand what the group does until they are taking a very active role in many projects. Other managers will simply hold back to a minimum and fulfil a limited mandate. Some possibilities for this group include the following:

    1. Create a repository of templates for use in all testing projects in the organization. This can be very well organized on a wiki or internal site. This process allows the user to identify what they need, download templates, fill them out and use the results. There is a level of effort required to set up and maintain this, but pays back for each project. After the initial set-up the group focuses on explaining and educating their stakeholders while providing updates for the project(s).
    2. Seconding personnel is assigned to the project and supports the testing effort. This person would know what templates were available and would be able to consult on best practices for each project. The TCoE would supply expertise as required on a project-by-project basis.

    This group is a little more focused on delivery (which some people consider critical for a Centre of Excellence) but not directly. Discussion of that point will come in our next blog.

  • Software Testing Centre of Excellence – Part 2

    As we mentioned in our last blog, a Software Testing Centre of Excellence can mean different things to different organizations. Over the past year, NVP Software Solutions has talked to a lot of Testing Centres of Excellence only to have found that one year later these Centres 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. The first one we want to focus on is:

    A research group that looks for best practices inside and outside the organization.

    This seems like the most impractical possibility although it can be a lot of fun for the involved personnel. Basically the group would look at any or all of the following with a view to incorporating them into the organisation.

    1. Appropriate Software Testing tools – obviously this can break into many categories of tools. However, having a group with no ties to any particular project can overcome one of the major problems associated with the acquisition of Software Testing tools – namely that many are selected for a particular project and have limited applicability to any other project. Having an independent group doing the selection overcomes that bias.
    2. Appropriate phases and depth of testing – an independent group can research best practices for testing the type and criticality of the software in the particular organisation and determine what the best people in the industry are doing. This can then be used as a standard to which the projects can aspire.
    3. Best processes – this one is clearly extensive. Somewhat along the lines of the point directly above but possibly spanning more than one phase and laying out the depth, this can create a self-perpetuating Quality Assurance Improvement process. Having an independent group helps provide more general processes that are applicable throughout the organisation.

    This group is clearly not focused on delivery (which some people consider critical for a Centre of Excellence). Discussion of that point will come in a future blog.

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