NVP Software Solutions

Tag: software testing

  • Malthus on Testing – Automated

    Malthus on testing is not something that you hear often. Thomas Malthus was an English cleric and scholar, who said “The power of population is indefinitely greater than the power in the earth to produce subsistence for man”.

    Last week we discussed how Manual Testing met its Malthusian Catastrophe a long time ago. One of the proposed solutions to this issue was to Automate the testing using a variety of tools and processes. Certainly that allowed multitasking on the part of the tester. Automated tests could run on one machine ‘unattended’ while the tester concentrated on items that either could or should not be automated and new functionality that it was too early to automate. Coverage was maintained and sometimes increased.

    However, unless a large effort was made to maintain the automated tests, keep them current with the changing code and conditions, and add new scripts as new functionality was added to the system the coverage either was reduced in real terms or at least relative to complete functionality of the system. There are some organizations that actually claim to have all the automation they need to properly test yet have no idea of what is in the automated suite or what it covers. There are even those for whom the possession of the automated base, whether used or not is sufficient.

    We improved over manual testing. We did not solve the problem.

    It is quite safe to say that Automated Testing met its Malthusian Catastrophe a while ago. Unless a very large effort is made (usually beyond the efforts of most organizations), Automated Testing is not going to cover sufficient of the code either.

    Following week: Malthus on Testing – Rapid Testing
    Final Series Week: Malthus on Testing – New Paradigm. We will propose a new method or paradigm for testing that will address some of the problems.

  • Malthus on Testing – Manual

    Malthus on testing is not something that you hear often. Thomas Malthus was an English cleric and scholar, who said “The power of population is indefinitely greater than the power in the earth to produce subsistence for man”.

    How does this relate to software testing and in particular, for this week, manual testing? Well if we paraphrase the Mathus’ statement a little bit we could say that the ability of people to add applications is far greater than the ability of people to keep up via testing. Add to that the necessity for regression testing of the existing applications and then the interconnections with other applications that is occurring at large speed and one can see that the possibility of the application functionality and complexity far outstripping the ability of manual testers to keep up.

    A lot of people recognized this very early and proposed a variety of solutions to the problem. We will discuss those in the coming weeks with particular emphasis on Automation and Rapid Testing. Others have recognized the impossibility of keeping up and have resorted to Risk Based Testing. With very few exceptions, all testing these days is Risk Based. We accept the fact that we cannot anticipate completing everything and as a result we make a risk judgement on what is most critical to be completed. The Risk Assessment is based on a lot of assumptions and some of the assumptions are not validated thoroughly.

    It is quite safe to say that Manual Testing met its Malthusian Catastrophe a long time ago. We no longer anticipate covering even a majority of the code.

    Next week: Malthus on Testing – Automated
    Following week: Malthus on Testing – Rapid Testing
    Final Series Week: Malthus on Testing – New Paradigm. We will propose a new method or paradigm for testing that will address some of the problems.

  • Quality Assurance for Startups – Part 4

    The last three posts have concentrated on Quality Assurance for Startups. Next week we will move into Starting Quality Assurance (for an already existing organization). However, we will finish off this week with some small examples of Quality Assurance Processes that a Startup can adopt for little or no cost.

    The first and easiest one is a Incident Tracking Process; definitions, and standards. You can easily  download a free Incident Tracker online or simply use an Excel Spreadsheet. The part that tends to get ignored is the process and standards. Generating a incident tracking flow chart can be done on paper and takes little time to create and post. Standards for the Priority and Severity for incidents can be downloaded from the Internet or generated. The resistance is usually because it is viewed as unnecessary at this stage. However, if it is created and posted at this stage, it becomes part of the culture.

    The second one is the code control and promotion process. Similar to the above, it is generally not viewed as worthwhile at the Startup stage since everyone knows where the code is and how it is to be treated. It is also likely that not all steps or stages are needed at this time. However, another flow chart showing the steps and the expectations at this stage can save a lot of concerns later. The diagram will need to be augmented as the company grows and becomes more complex but the initial diagram is quick to create and solves a lot of problems.

    The third one is testing processes. Again, it may look like too much effort for too little return at this stage but the creation of a testing process, standards, and definitions can be very effective in ensuring that everyone is working in the same way and can avoid a lot of repetition and redundancy.

    None of the above are intended to take more than a few minutes to create and set up. The payback is quite high and long term benefits are huge.

  • Quality Assurance for Startups

    Quality Assurance for Startups sounds like a bit of an oxymoron. Startup companies and leaders have enough on their mind without adding that ‘horribly slow and stodgy Quality Assurance Process’ to the mix.

    This concept is wrong for a number of reasons:

    1. Quality Assurance is never about being slow or bringing the process to a halt. It’s all about speeding up delivery of whatever you are supplying.
    2. Set up good processes at the start of your business and make improvements that have the biggest return, before bad or wasteful habits become entrenched.
    3. A startup needs to provide a product or service that ‘delights the final customer’. A product or service that falls short in some makes for a short-lived company.

    What does a startup need from Quality Assurance? Just enough to make the final deliverable delight the customer!

    So what should you have?:

    1. Processes that ensure feedback from the customers is received.
    2. Sufficient information about the way the deliverable was constructed so that feedback can be actioned.
    3. Assurance that the changes made will not impact existing functionality adversely.
    4. Consideration of how to implement future growth opportunities.

    Of the above list, the last two are the more important.

    We generally would consider the third point to be a form of regression testing and the earlier that is planned and implemented, the cheaper it is. However, it is often left (as we can personally testify) to a later release and the startup spends thousands of hours and a lot of funding retroactively forcing in regression testing. Minimal consideration of the possibility of needing this will SAVE A LOT later on.

    The fourth point above is slightly more difficult to apply since it requires some anticipation of future needs based on limited information. We will leave that one for next week.

  • Quality Assurance – Implementing Right the First Time

    The last three NVP Blogs have discussed Doing it Right the First Time. The last one addresses the issue of Implementing Right the First Time. This is the part that usually trips up most people. They know they want to implement this in their organization. They know how or they can refer to explanations that will suggest how. The problem comes when we try to actually implement the process.

    As is usual with almost any new initiative, we want to follow three precepts:

    1. Start small.
    2. Pick off the easy items first.
    3. Publish the successes.

    Taking these in order:

    Start small
    Start with something over which we have full control or a limited number of stakeholders. Do not start with a mission critical project with numerous stakeholders; that will not work.

    Pick off the easy items first
    A quick analysis will reveal some small and easy to fix items that can be corrected. Sometimes it can be as small as adding a field to a defect report that avoids an extra step further down in the process or removing a step like having Quality Control test a defect as it arrives from the customer before passing it to development and then testing it on the way back out. The second example might have had use at one point but no longer makes sense. A third and frequently easy place to look for improvements is in items that have been made redundant by technology changes. These can include printing items that are now easily stored online or even still testing installation disks for a hosted system.

    Publish the successes
    Even though this is third, it requires some upfront thought. We need to know the current situation and statistics before we can determine whether improvement has occurred. So even though this is the ‘last’ step it must be considered early.

    Rule 3: Take a step back; look objectively at your process; pick off a few items that can be improved; check the current situation; make the change and measure again.

    This is the first step to implementing Right the First Time or Quality Improvement in your organization. Next week; an anonymous example of How Not to be Right the First Time.

  • Quality Assurance – Benefits of Right the First Time

    In the last couple of weeks, we have been discussing the first two steps of Doing it Right the First Time. This week, we will take brief side trip to the Benefits of Right the First Time. A lot of groups stumble over this point because they cannot articulate this well. They seem to use Descartes (as sometimes translated) “I Think therefore I Am” to state that Quality Assurance is “Good because it is” and leave it at that. That argument, in the Quality Assurance case, is circular. One might argue that Descartes is also circular but that is not something we want to take up here.

    There is effort involved in “Getting it Right” and the question is whether it pays back later. We argue that is does using the following reasons:

    1. Having people actually concentrate on each step individually means that they will fully understand that particular piece.
    2. They can project all the possible consequences of that step.
    3. They can determine all the possible precursors that might impact that step.
    4. They can determine all the possible outcomes from that step.

    There are two major counter-arguments to the above. One we are already addressing here. The other can be addressed using the argument we have already stated.

    The first major counter-argument is the lack of time to do this type of analysis. Few people will deny the necessity of doing the analysis so this is only a question of timing and doing it earlier usually is beneficial in informing people.

    The second major counter-argument is that things will change before we are done so why spend the time on something that we will need to redo later. This argument misses the point of the process. The analysis carried out in this process identifies that possibility for change, anticipates what is going to happen, addresses it and moves to the solution.

    Step 3: Make sure we understand the benefits of this process so we can explain it at any time.

  • Quality Assurance – Right the First Time (Part Two)

    Last week we talked about getting it Right the First Time and started with Step 1. The next question many people ask is “How”. Usually they agree that this would be be a good thing for their project or organization and wish it could be done but stumble over How. There is a requirement for a cultural change if this is to occur throughout the organization but it is always possible to start small and implement this within a single project.

    The key points are as follows:

    1. Take the diagram created as part of Step 1 last week.
    2. Concentrate on each piece in turn.
    3. Determine the needs of that piece of the diagram in terms of who is involved; what their involvement is and what they are expected to complete by the end
    4. Look at the process or processes ahead of the one on which we just concentrated and determine what outputs are needed or can be anticipated.
    5. Revise (if necessary) our understanding of the current piece of the diagram based on what can be expected from the previous steps.
    6. Look at the pieces of the diagram that are recipients of the products of the current step and determine their needs.

    With all the above understanding in place, we are now in a position to get each step as close to perfect as we can. Get the relevant stakeholders together and with their undivided attention start deconstructing each step Combining the steps, while still considering any differences or modifications will give us something that is a lot closer to ‘Right the First Time’ than any process that sketches a diagram and starts development immediately based on incomplete knowledge.

    Step 2: Break the high level diagram into pieces and determine who is involved with each step; their involvement; the time and effort required and then get their time and commitment. Now we can launch the next step.

  • Acting on the Results – Redoing

    Last week we discussed how to measure the results of a Process Improvement initiative and how to successfully implement the process. This week we have assumed that the Process Improvement Initiative has been completed and we are now faced with Acting on the Results.

    There are two possible outcomes from the results and both lead to further action.

    1. The measurements and metrics indicate a successful process improvement and we have achieved the results we want.
    2. The measurements and metrics indicate an unsuccessful process improvement and we have to decide what to do next.

    In the beginning it is usually suggested that we review the measurements and derived metrics to ensure that we are measuring what we thought we were measuring. A false positive, (we think our program was successful but it was not) can be caused by either measuring the wrong item, deriving the wrong metrics or drawing the wrong conclusion. If the analysis indicates that the conclusion is correct then the following steps are recommended:

        1. Determine a new process improvement initiative.
        2. Determine if our existing metrics will properly measure the new initiative.
        3. Define new metrics as required.
        4. Implement and measure as before.

    If, after due analysis, we determine that our process improvement initiative did not lead to the correct result, then we have to decide between the following two possibilities:

        1. Undo the changes made and revert to the previous method of doing the process.
        2. Initiate another process improvement session to change the process to something better.

    For either of the above, we still need to measure and make sure we are accomplishing what is desired in terms of Process Improvement or maintenance of the status prior to the initial change.

    Note that none of this is based on supposition or guessing. No changes are made without supporting statistics.

    Next week: Quality Assurance – Doing it right the first time.