NVP Software Solutions

Tag: QA

  • Review of the Year – Automation

    Review of the Year – Automation
    Automation of software testing is something that seems to be on the minds of many Quality Assurance Managers and Test Leads. It has been a popular topic for many years.

    Currently we get requests for particular tools and knowledge of their attributes in particular environments; these are usually serviceable. Current status seems to be a separate tool for every need and environment and sometimes every organisation. Based on past experience, in a few years, someone will consolidate all the disparate technologies under one umbrella tool. Then the cycle will start again with people inventing new tools for specific niches and products.

    We also receive requests for people to “automate our testing” with no decision on the tool attached. This is a completely different question and requires some discussion to occur before the attempt to automate even starts. We need to know the what; when and Why the company wants to automate their testing. The thing we want to avoid are the actions below.

    1. Purchase Automated Test Tool.
    2. Install Tool.
    3. Wait for successful automation to save all the cost of the tool and cost of manual testing.
    4. Become disillusioned.
    5. Go to 1; Repeat ad infinitum.

    This has occurred over and over in different organisations. A lot of money gets used up with no progress and eventually the organisation gives up on the cycle and continues manual testing (see last week’s blog).

    Our best recommendations are as follows:

    Look up where you are on the technology maturity level with your current technology.

    Decide what you need (criteria are available) in terms of automation and what you are capable of handling based on maturity level.

    Then do a Plan to implement your automation. Never assume it will just occur. It won’t.

    Want to discuss how to automate effectively? Contact us.

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

  • A Better Way – Case Study 5 – Distributed with Poor Testing

    A Better Way – Case Study 5 – Distributed with Poor Testing

    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 fifth case study might be called “Distributed with Poor Testing”.

    In this case the developers were geographically remote, the Quality Assurance (such as it was) was local and the clients were geographically remote. This was a somewhat unusual situation since it is frequently the Quality Assurance that is remote and the other two local. However, some of the considerations had to be the same. We needed a way of communicating things without losing anything in transit.

    Two solutions came to mind immediately:

    1. Make sure there are stated expectations regarding the flow of information. This applies to any artifact like a test case, a requirement, a defect, or a design document. We did this via some flow charts we placed in the Master Test Plan although there are certainly other places they could have been recorded.
    2. Acquire some tools that will support this information store. There are many free or very cheap cloud-based tools that support these processes.

    Once we had the framework in place, we set up the appropriate loops and feedback mechanisms to ensure information flow and good quality. As time went on we expanded the groups who had access to the systems ensuring that the information flowed in the correct way and with sufficient security to the concerned parties. The two way flow of information allowed us to eliminate a backlog of defects that had accumulated and start addressing customer concerns in a timely manner.

    The investment was not large when compared to the improvements realised.

    If you want to discuss this further contact us.

  • A Better Way – Case Study 4 – Caught Between Vendor and Client!

    A Better Way – Case Study 3 – Test Plan in a Hurry!

    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 fourth case study might be called “Caught between Vendor and Client”.

    Although one could argue that Quality Assurance has always been caught between a Vendor or Vendors (developers) and possibly multiple clients (users), it has become a little more obvious and formal with the purchase of software from outside groups. This is not something that is going to go away. Assembly of a solution rather than building it has been around for quite a while and will probably become more frequent rather than less. The question is what Quality Assurance does to “Bridge the Gap” between what the client wants (‘perfection!’) and what the vendors are willing to supply in terms of proof given competitive secrets and possibly some Non-disclosure requirements.

    In our case (as discussed here) we built a plan that provided the final client with what they wanted. We then mapped what was supplied by the vendors against what was required and filled in the rest. Not surprisingly, the main items that were missing were Integration testing between what the various suppliers had provided and the type of testing that needed the entire system to be there including Performance, Security and Usability (to name a few).

    Bridging the gap in this fashion satisfied everyone and made use of everything that was already in place. That saved us a lot of time and allowed us to concentrate the tests that were critical to the client.

    If you want to discuss this further contact us.

  • A Better Way – Case Study 3 – Test Plan in a Hurry!

    A Better Way – Case Study 3 – Test Plan in a Hurry!

    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 third case study might be called “Test Plan in a Hurry!”.

    This issue came up from an organisation that was part way through (as usual!) an engagement and suddenly required a test plan to satisfy the client. The request came from the Project Manager on Friday with a deadline of Monday afternoon. There was no prior exposure to the project; no knowledge that the request was coming; and very little in the way of Project Documentation (with certainly no time to review it). There was a temptation to ignore the request and had they not been an existing client, we might have been tempted to point out that this was not really an effective use of time. However, given the nature of the request and the people from whom it came, we went ahead with the attempt.

    Clearly, we were not going to get detailed testcases or test objectives based on what we had been given. So we opted for a process based Master Test Plan. In other words, we put together a statement of how the project would be tackled from a Quality Assurance point of view when the information became available. We put in processes for all the Quality Assurance items and highlighted the risks inherent in testing under these conditions (including the lack of any understanding of the project) and went forward with that. We put a strong emphasis on what was required now in order to make this work.

    If you want to discuss this further contact us.

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

  • A better way to Test – 5

    A better way to Test – 5

    In our last blog we discussed how more testing or a higher percentage of test case coverage does not necessarily lead to better testing. We did not, however, provide a solution to the problem.

    One of the first items is to classify the testcases. In a project of any size, with numerous testcases, it is difficult to determine what each testcase is doing without classifying them. The Test Management tools allow for a lot of this and it is usually simply a matter of selecting the fields you want to use for classification; providing a limited list of choices for most of the fields (some can be freeform text entry but some need to have a limited number of choices so as to allow classification) and deciding where each testcase belongs. It will not be perfect the first time but can be refined over time. Some items that can be used for classification are as follows:

    1. Requirements (this comes out of Traceability).
    2. Function tested (may be a subset of the Requirements or it may be a separate mapping).
    3. Date of testcase creation (just so you know how old it is).
    4. Priority of the testcase.
    5. Some statistics generated from the testcase execution.
    6. The risk it tests – we have rarely seen this explicitly listed.

    The last item is the most important if you are testing against risk. It presupposes that you have the Risks listed, classified and numbered. Then it is a reasonably easy process to link the testcases.

    When your project is over, you can determine if the testcases addressed the risks (where appropriate) and whether they are useful for next time.

    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.