NVP Software Solutions

Category: Quality Assurance Consulting

  • A better way to test – 3

    A better way to Test – 3

    In our last blog we discussed the determination of risk. The question is what to do with it when we have completed that work. While there is a temptation to write a testcase for every risk; that is not always possible. A testcase or testcases will not (directly) address any of the following issues:

    1. Schedule issues
    2. Budget issues
    3. Poor design
    4. Poor coding practices
    5. Incomplete requirements
    6. etc.

    Testing can easily identify, highlight, and quantify some of the above issues. It may bring other issues and risks to light but it will not necessarily resolve or reduce them. The activities to reduce risk need to long precede testing. It is far too late in the project to address risk by traditional testing. Early involvement of Quality Assurance with the emphasis on Process Improvement will go much further to addressing Risk than a few hundred testcases.

    All of the above 5 risks which are possible in every project with at least 1,2 and 5 being quite common are all amenable to Process Improvement. Schedule and Budget issues need process work to address the possibilities and see what can be done early. Incomplete Requirements are easily addressed by using a variety of techniques in Requirement Elicitation. We cannot allow ourselves to fall into the trap of assuming a standard method of elicitation (same trap as using standard testing techniques) but we can use a process adapted to the project. The upper levels of Process Maturity are aimed at Innovation not set processes.

    Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Testing can be better.
    Contact us for further information.

  • A better way to Test – 2

    A better way to Test – 2

    The second item to determine is the Risk. We always guess that, if you gather three people from the project together and ask them what the risk is, you will end up with 4 answers: Three from the people at the meeting and the right one that no-one mentions. Levity aside, we do need to figure out the real Risk and it is not always obvious.
    Some questions you can ask (and elicit the three answers as a result):

    1. What is the worst thing that could happen?
    2. Who can be hurt the most if something goes wrong?
    3. What is going to cost the most if it goes wrong?

    Regardless of the answer or answers to the above questions, Quality Control is aimed at Risk Reduction. Everything we do needs to be aimed at reducing the risk in the project. Doing that can mean a lot of things that are far beyond traditional testing. We might want to ask what could be done now (before the end of the project) to reduce the risk. We might want to go outside the standard boundaries of the SDLC to consider solutions. This comes back to the need for early involvement. When the project is too far along, it is difficult to suggest radical solutions that might be beneficial. People are too set in their ways and the project is careening to an end that no one likes.

    This is why people who advocate a standard methodology or approach to testing for every project are locked into something that may not work. The same solution does not always work twice!

    Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Testing can be better.
    Contact us for further information.

  • A better way to Test – 1

    A better way to Test – 1

    The first thing to determine is the type of project, type of methodology being used to build it and the people involved (All of them) in building the project. This is not new by any means and seems obvious information to gather, but in the rush to get at testing when you have been recruited late in the project, this is often either skipped or compressed (usually with dire results later on). A few leading questions or a template that needs to be filled in for the Project Test Plan can often help in ensuring that you get all the information that is available. Frequently we find that this also helps the other people in the project get a better understanding of what they are dealing with and some of the expectations.

    We started into this process at a recent project and elicited the ‘surprising’ information that the design was wrong. The vendor’s exact words were ‘That is not the way our product works’. The project ran a lot longer than was expected and required a lot more testing since the design was revamped at great cost late in the project and the changes had to ripple throughout the software and hardware.

    The above is simply preliminary information that needs to be gathered before we even consider what we are going to do with it and how it impacts our testing.

    Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Testing can be better.
    Contact us for further information.

  • Isn’t there a better way to Test?

    Isn’t there a better way to Test?

    This is a question that gets asked very frequently especially at the end of projects that have not gone well. Testing is often left to the end of the project and by the time people get to it they are tired of the project, tired of the project team and generally looking for something new. Even when projects do go well; people ask the same question.

    The answer of course is “YES”. Testing can go better. But it requires a shift in the way it is done. Some people have a set methodology they use for all testing projects. Others rely on specific tools that are supposed to aid them in testing properly. Others work out what they are going to do when they get to the project. If every project was identical and things had been successful in the past then these approaches will work. However, no two projects are alike and the requirements for testing or Quality Assurance differ from project to project.

    Sometimes the differences are minor and techniques and processes used in the past can be reused with slight modifications. However, even with minor differences, testing needs to evolve over time to take into account new technologies and new methodologies. With major differences in projects and expectations much more than just a slight evolution must be undertaken. This will be the subject of the next few blogs.

    Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Testing can be better.
    Contact us for further information.

  • Selling QA

    In the last couple of blogs we talked about Early Involvement and the ROI of Quality Assurance. A list of a few places where Quality Assurance pays was also provided.

    However, Selling Quality Assurance can still be a challenge.

      • Some organisations see the benefit and buy in to the concept permanently.
      • Others never make the move towards a Quality Culture and cannot see the need.
      • The most common scenario is a cyclical one:

    Someone in an organisation embraces Quality and either are in the correct position to make it happen or have great timing where there has been a move towards Quality Assurance and it just needed someone
    to ‘ride the wave’ to completion.

    • There is, of couse, always the last scenario where there has been a crisis and everyone comes to the conclusion “If we only had had Quality Assurance the ‘problem/crisis/disaster’ would never have occurred”.

    Be very careful of the last one; it is not likely a deep commitment. Once the crisis is over, there will be a reversion to the earlier behaviour. It is very tempting to go to an organisation that has just had a crisis and try to convince them to change but it is not likely to occur and will be a struggle.

    So, how do we sell QA:

    1. We need to know the state of the organisation. Is there an underlying need or wish; or just a superficial desire?
    2. Who are the decision makers and what do they want?
    3. Where can be we get a reasonable return in a short period – we have to show something fairly quickly.

    Remember a culture change takes years. We need a set of successes that are directly attributable to Quality Assurance to start making the case for the wholesale introduction and embedding of the concept.

    Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Quality Assurance is exceedingly Cost-Efficient.

    Contact us for further information.

  • Quality Assurance ROI

    One of the items which comes up in most Quality Assurance discussions is the determination of what Return on Investment Quality Assurance provides. It can be hard to justify and obviously depends on the Costing Model used in your organisation. The factors in the Costing Model may differ but the overall trend is always the same. Early Quality Assurance (see last blog) alway pays.

    Here are some of the places where and how Quality Assurance pays:

    1. An error found at Requirements time will be much cheaper to fix there rather than later in the lifecycle. Estimates range from 10% of the later cost down to far less than 0.1% for even moderately complex systems.
    2. Similarly an error found at Design time has a ratio that is slightly less than Requirements but still substantial.
    3. Inclusion of Quality Assurance at an early stage will lead to root cause analysis of repeated errors saving thousands of dollars in testing and repetition of test cases.
    4. Inclusion of Quality Assurance at an early stage allows the definition and construction of an environment suitable for testing when the code becomes available. Environments may be able to be shared leading to cost savings or, at the very least, they can be designed with all the testing considerations included up front.

    The above are only a few of the places where Quality Assurance can save many thousands of dollars on the project. There are many more which could be defined and calculated.
    Our next blog will look at how Quality Assurance can provide valuable input and how that is made clear to the users.

    Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Quality Assurance is exceedingly Cost-Efficient.

    Contact us for further information.

  • Early Involvement of Quality Assurance

    One of the items which comes up in most Quality Assurance discussions is the determination of when to involve Quality Assurance in the project. Those with the traditional view of Quality Assurance as simply Software Testing (Quality Control) delay the arrival of the Qaulity Assurance Professional until the last possible moment and are then disappointed when the testing is not done correctly or with due regard for risk. People (including some Quality Assurance personnel) believe there is nothing to be done until the software is ready and ‘complete’.

    These people are missing the value that can be contributed by Quality Assurance early in the project including the following:

    1. Assessment of Risk from a Quality Assurance point of view.
    2. Review of Requirements and Design from a Quality Assurance point of view.
    3. Proper design of the test environment and the processes surrounding it.
    4. Proper and complete design of the testcases that address the most important risks while minimising the efforts.
    5. The chance to have feedback from other project members over the course of the test design and preparation.

    Of the above items the last is probably the most important. Feedback can help find and correct deficiencies earlier rather than later.

    Our next two blogs will provide concrete examples of how and where Quality Assurance can provide valuable input.

    Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Design review is very cost-effective.

    Contact us for further information.

  • Review Design (by Writing Testcases)

    One of the easier methods of review, for a Software Tester, is to write test conditions, test objectives, or complete testcases for the design. We define Test Conditions or Test Objectives as being statements of what is to be tested without the details usually found in testcases.

    For example the following might be a few High Level Test Objectives for a design:

    1. Test that the system continues to function in the event that the link to the Postal Code database is not working.
    2. Test that the system switches to the backup node when the primary node is taken offline.
    3. Test that the database is updated with the full CDR at the end of the call.

    There is a lot of detail under these Test Objectives and potentially they could generate many, many testcases but they are all real examples and they are all necessary. They key is to look for the following while you are writing the test objectives:

    1. Two, or more, test conditions that contradict each other.
    2. Places where we find it difficult to write any objectives at all – this may be related to a lack of knowledge or the design may be incomplete. Either are issues.
    3. Places where we are guessing at the expected behaviour for our Objective. We do not expect details here but a feeling that we don’t know what the result will be or how to prove it.

    Brainstorming with other people, talking to the System Architect, looking at other similar designs and looking up technical information are all good sources for building these objectives.

    Once you have completed your personnel review, you may be asked to join a group review bringing in your comments and hearing from everyone else. There are several methods of review depending on Risk including Desk Checking, Walkthroughs, Reviews, and finally Inspections. These vary from informal to very formal. However, they are all aimed at finding the errors in the design sooner rather than later. They also all assume on previous individual work.

    Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Design review is very cost-effective.

    Contact us for further information.