NVP Software Solutions

Tag: Centre of Excellence

  • Quality Assurance 2019 Review

    Quality Assurance is, as usual, up and down. Some organisations are buying in to Process Improvement, looking long term, and many are realizing that the solutions are not necessarily more testing or another test tool. They understand that the problems lie in how things are done rather than the tools used.

    However, many organizations are still adding test tools or adding test phases and layers without adding value to the Software or the Product.

    We completed several assessments over the past year and provided seminars aimed at process improvement. We are now up to the stage of implementing the process improvements identified. These organizations are moving ahead and planning for the long term. They can see the value of improvement.

    However, on the other hand, some of the people we are dealing with are struggling to complete the necessary testing without considering the long term improvement. They are challenged by the necessity of getting testing done for clients and do not think they have the time for process improvement.

    So will this change in the 2020? It seems unlikely in view of the above unless we consider the following:

    1. Calculate the real benefit of implementation of process improvement over multiple projects. This is the long term, high level, view of how process improvement benefits multiple projects.
    2. Define and gather the appropriate measurements and metrics to determine whether the process improvement is having the desired effect and also to identify further process improvement opportunities.
    3. Select and acquire the appropriate technology to support the process improvement effort. Talk to us about a well tested methodology for QA technology acquisition.

    Photo by Bekir Dönmez on Unsplash

  • Automated Testing

    Judging from what we have heard, AI seems to be the favourite flavour for Automated Testing in 2019. Many of the tools are stating that they are AI enabled or AI enhanced and claiming massive productivity gains as a result.

    We are still seeing tools that require a lot of technical knowledge and other ones that have hidden the actual scripting from the users.

    One other major change is that most tools are now automatically offering either a cloud based or an on-premise solution to suit every client’s wishes and, more importantly, their security needs.

    Tools go through a cycle every few years. For a while we get a different test tool for every possible situation, then someone comes and consolidates a large number of tools into one tool that addresses most situations. Then the cycle starts again. Obviously this cycle is driven by the technology used to build applications and what level of testing is needed.

    In addition to the technology that is used to build any particular product, the methodology also impacts the way automation is applied. Any iterative methodology has vastly different needs from a standard Waterfall methodology.

    What we are not seeing, is much initial analysis to select the best test tool for an organisation. We are still seeing selection based on features and not necessarily on functionality that is applicable throughout the organisation. We are seeing some ROI for individual automation efforts but that is after the tool is selected and implemented. However, as discussed last week, that calculation is not over the entire organisation or over an extended time period. This means we are losing out on some automation opportunities and completing some based on a false calculation.

    So will this change in the 2020? It seems unlikely in view of the above unless we consider the following:

    1. Calculate the real benefit of implementation of automation over multiple projects and years.
    2. Find an automation tool that suits your situation. There are many good ones around; you just need to find the appropriate one. Talk to us about a well tested methodology for test tool acquisition.

    Photo by Franck V. on Unsplash

  • Manual Testing

    This year is the n’th time we have heard about the demise of Manual testing and the n+1’st time it has not occurred.To paraphrase Mark Twain “Rumours of the death of Manual Testing have been greatly exaggerated”.

    Why does this keep coming up year after year:

    1. We keep inventing new items that are not amenable to being automated.
    2. New startups have neither the time or the budget to worry about automating testing. Their emphasis is on getting the product out the door and into the hands of their customers.
    3. Some organisations have a great deal invested in an old automated tool. They are not maintaining the existing scripts or adding new but no one is willing to throw them out.
    4. Some testing tools have not lived up to their promises and people are unwilling to try again with a new test tool.
    5. Most project managers do not have budget for automation of testing and since they do not benefit from it (the next project benefits) they see little reason to add it to their project.
    6. If it becomes a corporate or central responsibility to automate, then the question of funding it becomes awkward. Who is responsible for the cost fo the tool and the automation effort? How is that cost amortized and apportioned?
    7. It appears cheaper to get Manual Testers.

    So will this change in the 2020? It seems unlikely in view of the above unless we consider the following:

    1. Calculate the real cost of repeatedly executing the same testcases manually.
    2. Calculate the real benefit of implementation of automation over multiple projects and years.
    3. See whether the automation will pay for itself using the above two figures.
    4. Find an automation tool that suits your situation. There are many good ones around; you just need to find the appropriate one. Talk to us about a well tested methodology for test tool acquisition.

    Photo by Hunter Haley on Unsplash

  • A Better Way – Case Study 2 – Thinking Like the Client

    A Better Way – Case Study 2 – Thinking Like the Client

    In our last several blogs we have discussed ‘A Better Way to Test”.

    The issue is to apply this to actual situations. We have 5 Case Studies we plan to use over the next several weeks to address this. The second case study might be called “Thinking Like the Client”.

    Even though many in IT have embraced Agile in some form or another and with some level of success, not all clients are so willing. We find this particularly the case with larger, older and more safety or image conscious clients. They are not willing to take the risk of everything not coming together at the correct time. They are not willing to live with constant change. In addition, they often have milestones that need to be fulfilled and quite frequently they have stated contract deliverables that need to be fulfilled so that payments can be made.

    We received a call from the President of a development company with a large contract with probably the oldest, largest and most image conscious client you could get – the federal government. Even though the company had delivered projects successfully before and had a good record of coming through with what was required, the client still wanted a formal Test Plan completed.

    In our experience, the client is normally okay with a High Level Master Test Plan provided it contains the following (this is not an exhaustive list by any means):

    1. High Level Objectives
    2. A listing of the types of testing needed and the risk around each type
    3. Processes for Test Creation and signoff
    4. Processes for Defect tracking and resolution
    5. Methodologies for executing the testcases

    This reassures them that the developers have an understanding of what needs to be done.

    If you want to discuss this further contact us.

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

  • A better way to test – 6

    A better way to Test – 6

    In our last blog we discussed, as the last point in our list, testing to risk.

    If you have the risks listed, explained, classified, calculated, ordered and entered into a database, it may be easy to attach testcases to them and determine when you have addressed the risk with testing. Not all risks can be efficiently addressed by testing, it is simply one of the possible techniques to be used.

    However, people rarely agree on the risks and, as mentioned above, not all risks can be addressed by testing. So this needs to be flexible.

    If you don’t have your risk recorded then the testcases may still be built to address perceived risks but they may be difficult to justify. Having both sides of the need (the risk and the testcase) can make each justify the other.

    Once we have this for one release of the software, the only question is whether we can continue using the same testcases from release to release. Risks will change, some will disappear or be downgraded, new ones will appear or the ones we missed last time will be included for future releases. Like all project requirements, nothing is ever perfect and we progress (sometimes unevenly) to an end result of coverage that is sufficient for the project. Of course something will always surprise us.

    The key consideration is not to become inured to the other methods of addressing risk – testing is not the end solution for everything.

    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.

  • Review Design (by Reviewing)

    The title of this Blog may be considered to be a self-evident truth. How else would you review a design except by reviewing it? There are other ways which we will get to in a couple of weeks. However, our initial look will be by the standard method of reviewing them and what a Quality Assurance person might get out of the review.

    Reviewing a design can be difficult for some people. The following problems may arise:

    • You don’t know anything about the technical solution
    • The design is very technical
    • It is difficult to maintain concentration for an extended period of time

    There are ways around these problems. Some of them are personal and some relate to the methodology used to review the requirements.

    On the personal level:

    • Familiarise yourself with the system for which the design is being created. It will help! You cannot review in a vacuum.
    • Organise the design into sections so you can concentrate on a particular section at once.
    • Ask for a System Boundary Diagram (SBD).

    We emphasized one item above. The System Boundary Diagram can be created at many levels but the common idea is that it shows the system in a pictorial form and identifies the interfaces to external systems. The act of creating an SBD brings many problems to the surface and allows the Scope of testing to be set.

    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.

    For a different way to review the design, look for our next blog on this topic.

    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.