NVP Software Solutions

Tag: Startups

  • A Better Way – Case Study 1 – Thinking Outside the Box

    A Better Way – Case Study 1 – Thinking Outside the Box

    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 first one revolves around a junior QA, a very successful (small) company and a need to test effectively and quickly for a large final client. The issue that came up was the ability to “Think outside the box”.

    We received a call from the President of the company indicating that the new junior QA was having trouble considering things “Outside the box”. They were good with what was presented in the Use Cases or User Stories. Most people can generate testcases based on what is provided and the happy path from the Use Cases and User Stories. Experienced testers will apply other techniques and may specifically try Exploratory testing. However, you cannot explore or test what you don’t know or don’t think of at the time.

    Rather than dictating “Outside the box” which is a contradiction in itself, we decided to go with more of a checklist approach listing some of the areas that would be considered to be non-Happy Path and see if it could lead to further extensions. We did not dictate everything but started with more of a charter and guidance list to see what would come of it. The process had two advantages:

    1. We would have some coverage of everything “inside” and “outside” the box.
    2. We could use the results to evaluate the suitability of the junior QA for further roles and projects.

    The President came up with the basic list and ran it from there.

    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.

  • Selecting Software to run your business – 2

    As mentioned in the last blog, there is any number of packages that are available to do some or all of what you want the business to do. Whether that is to track Goods-in-Transit, Maintain Financial Records, Generate a Sales Catalogue, Create and send an email blast, Retain Customer Information, Track needed Repairs or Write a Document, there are many choices and all the choices have their advantages and disadvantages. Some are cheap, others expensive. Some provide functionality you will never use, others will leave you wishing the software did more.

    If you are facing this conundrum, there is a solution. There are methods to evaluate what you need, then to evaluate what is available and then to finally bring the two together to make a quantified decision about what to buy (or build).

    The high level process is:

      1. Survey all the areas in your organisation that will be affected by the new software.
      2. Document the stated requirements from each group and give them weights (example follows).
        • Must have = 5.

          • Note: Any technical requirements that cannot be changed are given a 5 or you can simply set them up as initial questions and remove anyone not matching them.

        • Should have = 4.
        • Nice to have = 3.
        • Minimal need = 2.
        • Unimportant = 1.
        • Not relevant = 0.
      3. Create a scorecard based on the above.
      4. Survey the existing tools (there are many sites on the internet).
      5. Select the top 4 and bring in the vendors for a demonstration.
      6. Fill in the scorecard.
      7. Bring in the two highest scorers for a more indepth presentation.
      8. Make your selection knowing with certainty that you have made the best choice.

      Now comes the more interesting part: Implementation. That is a subject for the next blog.

  • 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 – Part 3

    Last week we discussed When to implement Quality Assurance for Startups. This week we want to dive a little more into How without impacting everything else a Startup needs to do to make sales happen.

    Often Startups make the assumption that Quality Assurance is unnecessary or unnecessary at this stage of the product or service life-cycle. This means that they might never get to it, and that’s not a dangerous practice to follow. There is also the obstacle of How to implement QA into processes without having it negatively impact the other areas of the business.

    There are several questions we like to start with for implementing QA:

    1. What is currently a problem? If you cannot identify anything that is a problem then it is unlikely that an initiative will go anywhere.
    2. Is there a solution to the problem? If you cannot identity a solution to the problem reasonably quickly then you are in danger of expending more effort than the return.
    3. Can the solution be implemented with current resources and in a series of steps that are able to be done by those resources? If the solution requires extra resources then again the effort will likely exceed the return.

    If the answers to all the above questions are positive then we are well on our way to identifying How to implement the required process improvements.

    Look at the what has been identified as problems that fit the above criteria.

    1. Pick the most tractable one.
    2. Post it somewhere where you and everyone else can see it.
    3. Invite solutions for the problem.
    4. Hold a brainstorming session to pick the best solution.
    5. Create the list of steps that need to be done to implement the best solution.
    6. Determine what constitutes overall success and success for each step.
    7. Implement the measurement or metric that will measure whether that result has been realised.
    8. Measure the current status.
    9. Implement the steps.
    10. Measure the results.

    None of this will be immediate but it will improve over time.

    Next week: Examples.

  • Quality Assurance for Startups – Part 2

    In the last blog we discussed why Quality Assurance for Startups was appropriate despite it not being the first thing on startup leaders’ minds. This is understandable given the amount of other work that needs to be done just to get going as a new business.

    It would be pointless to introduce a full Starting-Quality-Assurance process in the beginning stages. The effort involved would detract from the other to-dos and could interfere with growth. With that said, we can introduce a limited Quality Assurance program during the startup stage that will benefit all without adversely impacting the growth of the organisation as follows:

    1. At the end of each week, take 15 minutes and review what has been done and how it is being done.
    2. At the end of each month, take 1 hour and review what has been done and how it is being done.
    3. In both cases, take brief notes and file them.
    4. At the completion of the one month meeting, consolidate the notes and divide them into groupings. For example: Development; Quality Control; Process; Customer Feedback: Recurrent Issues
    5. Look for items that might be costing you money; that are easy to correct and can be implemented immediately.
    6. Look for items that have a medium term to correct and may still be worthwhile
    7. The biggest items to look for are those that may not be easy or fast to correct but may have a big impact in the future if left unchanged.

    If the items fall into the easy category; make the changes now and implement going forward.

    If the items fall into the medium category; try to subdivide them into things that can be done immediately and implement some of those.

    If the items fall into the long-term or hard category; there may be a need to assess how much effort it will require to implement a change.

    We are going to tackle how to implement next week.

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