NVP Software Solutions

Tag: Software Testing Strategy

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

  • Review Requirements (by Writing Testcases)

    This is the second in the series about reviewing requirements. This week we are considering the method of using Testcases to review the requirements. Some people would feel that this is too early in the process to be considering testcases but we do not have to write complete testcases. Test conditions or objectives will be enough at the start and the payback is substantial.

    As we mentioned in the last blog, reviewing requirements can be surprisingly difficult for some people. The following problems may arise:

    • You don’t know anything about the system under review
    • The requirements are disorganised
    • It is difficult to maintain concentration for an extended period of time

    The act of writing testcases (conditions or objectives) and attaching them to the requirement for which they were written (Traceability) has the impact of clarifying thoughts on what the requirement really means. Most requirements generate multiple testcases. In order to write even the start of the testcases, we need to be able to decompose the requirement into its component parts and understand each one. The process of doing this will highlight the deficiencies in the requirements.

    1. If our test conditions contradict each other then the requirements are probably inconsistent.
    2. If our test conditions don’t seem to cover everything, then the requirements are probably incomplete.
    3. If our test conditions expect to test items that are clearly wrong then the underlying requirements are probably wrong.
    4. If our test conditions seem unclear when completed, then the requirements are probably just as unclear.
    5. We could draw other conclusions but these are the main ones for requirements.

    The process here is used to clarify the thought processes.

    Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Requirements review is very cost-effective.

    Contact us for further information.

  • Quality Assurance for Contracted Software

    Quality Assurance for Contracted Software is a little different from our last two blogs on somewhat similar topics (Downloaded and Contracts). Obviously there is overlap with the QA for Contracts but here we are assuming that, rather than contracting for an already built product that might be modified for our use, we are specifying exactly what will be built. We are contracting out the development (and maybe testing) of something where we know exactly what we want.

    One would think that this would be a great opportunity to put Quality Assurance requirements into the contract and provide exact criteria for what will be received. The problem is that people have trouble specifying quality. Ask a group (I have) for a definition of Quality and you will get as many answers as there are group members (maybe more).

    The following are pretty common answers:

      1. The product shall be Fit for Use. By whom and with what training not being defined
      2. The product will adhere to the Requirements as stated. Quality Requirements not always being well defined or defined at all

    And the same three from our last similar blog

    1. The product shall be of a Quality nature. Quality nature not being defined
    2. Testing will be completed. By whom and when, how or where is not considered
    3. Test results will be supplied. Format, detail, and how left to the discretion of the supplier

    it is worth some time to put Quality Requirements into a Contract for Software. The time taken to add the clauses is minimal. The payback is huge.

    Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Considering the Quality Assurance and testing aspects early in the contract can save you a lot of effort, time and funds later on.

    Contact us for further information.

  • Still time to Enrol for Fall 2017

    Enrolment for Fall 2017 courses on the following topics is still open:

    1. Test Leadership
    2. Manager’s Test Planning
    3. Effective Software Testing
    4. Boot Camp for Testers
    5. CSTE Certification Training
    6. CSQA Certification Training
    7. CAST Certification Training
    8. Other courses on request

    Courses are continuing from September to November of 2017.

    Take your opportunity to get training created by experts in the field. Make 2018 your best Quality Assurance year by being prepared and ready for whatever might come your way in terms of Software Testing or Quality Assurance. Waiting to next year puts you behind when a problem does occur.

    Quality Assurance is not just a solution to a technical software problem. It is a consideration for the entire business. Software Quality Assurance failures impact the entire business and can lead to large problems if not addressed.

    Training testers using NVP supplied courses provides testers with the techniques, tools, and knowledge to select the best method for testing – not the one that has been used for the last 15 years that’s falling short!

    When you work with an experienced software testing trainer you benefit by:

    • Creating more valuable employees that pays back more than investments
      in any test tool!
    • Getting real value from testing
    • Enhancing speed, accuracy and results from your testing processes
    • Seeing larger profits

    Quality assurance training is a great way to help ensure your systems are working for you while supporting and contributing to the growth of your company.

    Let us know if we can help!

  • Struggling with Software Testing?

    Businesses, organizations and corporations purchase software in hopes of bettering existing processes, but sometimes the data is suspect and manual processes have to be put in place to fix errors caused by the new software tools. If software was implemented to help you operate more efficiently and grow as an organization, why is your new software slowing you down? Perhaps it’s time to look to your software testing team! (more…)

  • Reduce Business Risk with QA

    The software your business relies on to operate successfully is crutial to the success of your company. Software RISK (a potential problem that may occur due to lack of information, control or time) is something that should be minimized wherever possible when it comes to your daily business operations.
    (more…)

  • So you want to be a software test automator?

    So you want to be a software test automator and don’t know how to start.

    There are plenty of ways to become a software test automator and we’ve talked to a number of people curious about how to break into the field. If you ask current test automators what their background is here are some answers you may get: (more…)

  • Volume Testing

    Volume Testing

    Volume testing confirms that any values that may become large over time (such as accumulated counts, logs, and data files) can be accommodated by the program and won’t cause the program to stop working or degrade its operation in any manner.
    Risk if not completed – It may not be possible to operate the complete system with all data in place if the volume of expected records is not checked during testing and verified to work correctly and completely. (more…)