NVP Software Solutions

Tag: Quality Control

  • Anticipate the worst and plan for the best

    Anticipate the worst and plan for the best

    The press has been full of the Mars probe crash over the past week. A sensor malfunction caused the onboard computer to think the probe was much closer to the surface than it actually was and triggered a series of actions that caused it to crash. It’s not easy to anticipate everything especially when it has to be planned out so far in advance and last minute changes are not possible. Mars probes have failed for a number of reasons over the years and knowledge of the red planet is still limited. How could quality assurance helped? (more…)

  • Getting Value From Quality Management

    Getting Value From Quality Management

    Two weeks ago we provided A How to on Quality Management?  This week we want to look how you get Value from Quality Management.

    We often hear people questioning the value of Quality Management, and rarely hear the same question on the value of Software Testing. Testing has a tangible and more immediate outcome. Quality Management, on the other hand, doesn’t always show its value and activity immediately even though it provides longer term and larger rewards. The key to getting value from Quality Management and Quality Assurance activities is that all findings must be acted upon. If they aren’t, value isn’t achieved and efforts will be wasted. (more…)

  • Upcoming Software Testing & Quality Assurance Events – October 2016

    NVP Software Solutions will be participating in the following two software testing and quality assurance events happening this October in Ontario, Canada. The events are located in Toronto, Kitchener-Waterloo and London in the coming two weeks. Check out the relevant websites for more information and to register. This is a great opportunity to connect with other software testing and quality assurance professionals. We hope to see you there! (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…)

  • Negative Testing

    Negative Testing

    In many software testing scenarios, testers can use positive testing and/ or negative testing methods. Positive testing means that the item being tested reacts as expected when the expected input is entered. Negative testing typically means that the system can handle invalid input or unexpected user behaviour. However, if the system responds by rejecting the data and providing an error message, that is what was actually expected, meaning that was positive testing rather than negative testing. (more…)

  • 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…)

  • Why Test Training

    Test training is something that should be a ‘given’ and not something that a blog series should be devoted to. However, we get a surprising number of questions about test training and plans, that we thought we’d address a few of them here. So why train testers? You may recall that we defined three broad categories a couple of weeks ago in the blog. (more…)

  • Scope of Testing

    The Scope of Testing may relate to how much testing we are going to do or it may relate to how much of the system we are planning to test. The amount of testing could be defined as doing multiple phases of testing with differing aims. The amount of the system we are planning to test and actually do test can be measured by a coverage tool. These two definitions are not independent of each other. Regardless of which definition you decide to use, Be Prepared for some arguing.

    The (not entirely rhetorical) questions you will get asked include the following:

    1. You are planning on how much testing? (too much or too little)
    2. What makes you think that is enough testing? (too little)
    3. You are planning on testing that? (should be included or should not be included)
    4. On what did you base that estimate or expectation?

    The questions can go on like that for ages. I have one client who does not want any errors in production. Their mantra is everything is in scope and test as much as you can. They are no more successful than any one else and sometimes less so.

    Whatever your policy; the following will guide the creation of the scope:

    1. What must be tested?
    2. What can be tested (within budget and time constraints)?
    3. What is the best use of the resources?

    Make sure to document the scope up front and get it signed off. That will reduce the problems later on and create a much more harmonious working relationship.

    Of course, once we have done the scope, then we need to define the Out of Scope. More arguments are on the way! Incidentally Out of Scope is not Everything not In Scope. It must be specified.

    Discussion Questions

    1. Do you define your Scope of Testing?
    2. Has it been disputed?
    3. What would you have done differently based on what you know now?

    Next Week: Training