Results 1 to 8 of 8
  1. #1

    how many possibilities should i test?

    some certain function can be perform in many ways from the GUI.
    for example,exit notepad
    we can click the the x button
    right-click on taskbar->exit...

    copy a text
    highlight->right click->copy
    highlight->edit tab->copy

    should i include every possibilities in the automated script?
    then how about the failure cases?

  2. #2

    Re: how many possibilities should i test?

    Depends what the spec says. I'd test all the options, plus any ways of navigating by keyboard - e.g. hotkeys, tabs, F keys.

  3. #3

    Re: how many possibilities should i test?

    I agree with Myrtle.

    Ideally one should test all the possible options or paths that are possible to navigate through an application. Otherwise the application hasn't been properly tested.

    Of course time can be a limiting factor as to how much testing can take place and a risk-based approach has to sometimes be taken, but there is always the possiblity that bugs or errors can creep through.

    Automating the process and capturing user input and building up regression test packs will greatly increase the coverage.

    Inclusion of the failures should also be included in the regession pack, as this can be used as a baseline to compare against - ie if the actions failed or succeeded in the baseline the same actions should fail or succeed in the subsequent tests.

    Of course the amount of work involved in building up these test packs may well depend on the automated solution you are using.



  4. #4

    Re: how many possibilities should i test?

    Not to take the conversation off-track, but if your app is using the Windows built-in functionality for closing windows and the built-in Windows clipboard, I would verify that the clipboard works and I would verify that you can close the window but I wouldn't put too much effort into either one - I'm sure that your app has functionality that has not been tested by others, and that deserves the bulk of your attention.

  5. #5
    Senior Member
    Join Date
    Mar 2007
    Waterloo, Ontario, Canada

    Re: how many possibilities should i test?

    I would usually agree with Clint, but in this particular case I can't. I worked on an app once where the X-button and menu drop down didn't funciton the same. Reason being, they were calling a deprecated function on one of the buttons. If this is a straight system call (like Window.Close) then that's great! However, very often, we'll be calling sub routines to handle saving of an application, which need to be verified from each of these paths to ensure that it is called correctly. Afterall, this is just 3 or 4 different cases, right? I'm sure there are other areas with many more cases than that which could be cut down using something like equivalence class partitions.
    9 out of 10 people I prove wrong agree that I'm right. The other person is my wife.

  6. #6

    Re: how many possibilities should i test?

    The general rule here is to find out which differences matter, and which do not.

    Then, use that knowledge to create equivalence groups, and test each group.

    For example, let's assume you are trying to close the application. You might consider:
    - does the File, Exit menu pick do the same thing as the X-button, Alt-F4, select Close from the System Menu, etc?
    - what if I close the application by ending the program using the Task Manager?
    - does it matter if I close the application right after it has been started, or later after some work has been done?
    - does it matter if the application is maximized or minimized when I close?
    - if there are non-standard ways of closing the application, how are they different than the standard methods?
    - lather, rinse, repeat...

    I once worked on an application that had a non-standard button which closed the application. Even worse, it unexpectedly operated differently depending on exactly where within the button you clicked, or if you clicked the button by setting the focus to it and pressing Enter! (It was a design mistake to use this non-standard button in the first place...)

    You cannot test everything. In a GUI environment the possible combinations of events, timings, etc are almost limitless.

    So, do some preliminary investigation and testing work to find out what matters and what doesn't. Then test all the variations that matter.
    Joe Strazzere
    Visit my website: AllThingsQuality.com to learn more about quality, testing, and QA!

  7. #7

    Re: how many possibilities should i test?

    Also, consider how many sequences of possibilities you should test. A fault may not occur until the 'right' sequence of actions has been executed.

    To address this problem, you could try Model-based testing (MBT).

    The last url points to a Google video, in which Mark Utting makes a good presentation of MBT.

  8. #8

    Re: how many possibilities should i test?

    Ideally we should test everything that has a bug. Trouble is we don't know what has bugs until we test -- and even then we may not recognize a bug when we encounter it.

    If we knew what tests mattered, we wouldn't have to test. [img]/images/graemlins/smile.gif[/img]

    It is important to think of new things that should be tested based on what we learn as we test. Sometimes I will realize that planned tests are not likely to be worth the time. Often I realize that there are many things I should test that aren't in my original plans.



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
BetaSoft Inc.
All times are GMT -8. The time now is 04:01 PM.

Copyright BetaSoft Inc.