NVP Software Solutions

Tag: Documentation

  • Review of the Year – Manual Testing

    Review of the Year – Manual Testing

    Manual Testing is something that seems to be on the minds of many Quality Assurance Managers and Test Leads. Usually they want out of the Manual Testing and view Automated Testing (Blog planned for next week) as the saviour of their budget and time constraints.

    However, judging by the vacant positions we get requests to fill, there is still no shortage of Manual Testing positions at least in our area. There are still a lot of requests for Manual Testers with business knowledge preferred and new software and startups still start with manual testing. We get requests for Automated Testing with specific tools usually requested and will discuss this next week.

    The part that seems to be missing from many of the requests and the subsequent position is any discussion of the How; What; Why; When; and If; of the manual testing.

    There seems to be limited thought given to How the testing is to be done apart from some vague request to build testcases and execute them.

    Little consideration is given to What to test and Why beyond the statement: “We need to test the software”.

    When and If are not such an issue: Yesterday and definitely are the one word answers to those questions.

    These answers certainly provide freedom for the tester to do what they want but that may not always align with all the stakeholder’s wishes and may be 180 degrees off in some cases.

    This leads to a poor ROI and a large waste of time and money.

    There will continue to be a market for manual testers for new changes and new applications that are not yet mainstream. We expect automation to take over many of the repetitive tasks (as has always been the case) The only open question at this stage might be what AI will do to the industry. That we cannot predict.

    Want to discuss the effectiveness of your Manual Testing further? Contact us.

  • Selecting Software to run your business – 3

    Implementation is by far the most interesting and challenging part of Selecting Software to run your business. This is where the details become major problems and resistance to change can derail the entire project.

    It is crucial to do the following:

    1. Get everyone on side.
    2. Get a champion (or champions).
    3. Anticipate the issues.
    4. Address the issues (before they become problems).
    5. Start small (if possible).
    6. Demonstrate successes.
    7. Roll out to the entire company

    Many solution packages look simple on the outside but turn out to be complex to implement and maintain. Others have hidden depths you will never use while others will disappoint you. The selection process is crucial to anticipate some of these issues and make provisions to address them.

    No matter what package is selected or what deployment process is used; at some point the implementation must go ahead or else it will never occur.

    A study from some years ago provided the following figures for software that was purchased to be implemented:

    1. Software Delivered but never successfully used – 47% of the total.
    2. Software paid for but not delivered – 29% of the total.
    3. Software used but extensively reworked or later abandoned – 19% of the total.
    4. Software that could be used after changes – 3% of the total.
    5. Software that could be used as delivered – 2% of the total.

    Implementations have to fall into that 2% to be fully succesful and within the 5% to be partially sucessful. These are not high odds and to be successful requires a correct deployment process throughout the organisation.

    If you have concerns about any of the three stages (Stage 1 and Stage 2 were described in earlier blogs) of acquiring and implementing software – call us at 1-800-811-4718 or contact us.

    We are here to help.

  • System Boundary Diagram

    System Boundary Diagrams sometimes come up in the context of a Use Case and sometimes in the context of Software Testing. Either way they are a useful in the effort expended when determining what to test. While the ‘normal’ System Boundary Diagram shows the boundaries of the system and thus the boundaries of the testing, we try to use it only as a starting point for other diagrams that may also aid in defining the testing effort and scope. (more…)

  • Testing Sources of Information

    Sources of information for testing tend to come from two extremes. In some cases you may have almost no information and find it difficult to start. In other cases you may have far too much information and not know what to do with it all or where to start or stop reading. The ‘happy medium’ or ‘just right’ amount is rarely the case when it comes to testing sources of information. (more…)