Home » Technology » Software Testing – Methods

Software Testing – Methods

Continuing along with the theme of testing, I wanted to explore the various methods used for software testing. I found that there are a variety of approaches when it comes to software testing. Both static and dynamic testing work to improve the quality of the final software product.

  • Static Testing includes reviews, walk-throughs, or inspections of the software (or sections of it). It can include proofreading or using programming tools (i.e. text editors or compilers) to check the source code structure or syntax and data flow. Static testing revolves around verification.
  • Dynamic Testing is well, dynamic. The program is actually executed or run with a test case (or a set of test cases), and oftentimes in a debugger environment. It may also include testing just small pieces of the program before the entire program has been completed. Dynamic testing involves validation.

The ‘box approach’ includes the white-box and black-box testing methods:

  • White-Box testing
  • Black-box testing

Other testing methods include:

  • Visual testing
  • Grey-box testing

White-Box testing looks at testing internal structures (different from what the end user experiences). This is also known as clear box testing, glass box testing, transparent box testing and structural testing. It would be similar to testing nodes in a circuit (in-circuit testing). There are different techniques used in white-box testing – API testing, code coverage, fault injection, mutation testing, function coverage, and statement coverage. Perhaps one day, I will explore these individually and write in greater detail. My goal with this series was really to just learn the basics about some official methods of testing, which I had not even realized existed up to this point. My approach to testing started out haphazardly (does it work? why not? try this.) and I wanted to try to standardize my approach.

Black-box testing looks at examining the software functionality without knowing any of the internal workings of the software. Testers are only looking at what the software is supposed to do, but not how it functions internally. There are many different methods available, including: equivalence partitioning, boundary value analysis, all-pairs testing, state transition tables, decision table testing, fuzz testing, model-based testing, use case testing, exploratory testing and specification-based testing. Thank you Wikipedia. A tester need not possess any programming knowledge because they are only looking at the external functionality. However, because they are only looking at the external functions, it may be possible to skip over testing some parts of the program.

Specification-based testing, as mentioned above, looks at testing in alignment with the software requirements. One simple example would be testing the addition function on a calculator. By entering 2 + 2 (and knowing that the expected answer would be 4), you could verify that the program functions as expected.

Visual testing involves video recording or observing the testing process in order to witness the point where the software performs unexpectedly. This allows developers to see exactly what the tester did (what button was pushed, what browser, the timing of clicks, etc) in order to create the failure, and eliminates or lowers the need for developers to replicate the failure, saving time and allowing them to focus on a solution. I experienced this myself last week when I was unable to replicate a bug that had been reported. After a conference call and a ‘GoToMeeting’ (in order to share the computer screen), I was able to witness the timing involved with our testing staff and see the error that I had been unable to replicate. Her timing was described as ‘regular’ on the bug tracking record (clicking from field to field), whereas I would describe her timing as ‘extremely slow’ based on watching the screen as she clicked through fields. That made a big difference for me to be able to replicate the error, and ultimately find the cause and develop a solution or fix.

Gray-box testing (or Grey, depending on which side of the pond you are on) is something I work with pretty often right now, although I never knew an official name for it previously. It includes having some knowledge of the background functions and structure, particularly the supporting database. A tester could perform a test on the software at the user interface level and execute SQL queries before and after the test to verify that the appropriate change took place at the database level. This type of testing may help the tester to design more accurate tests.

My sources:
Wikipedia provides a large amount of information on software testing. And, did you know there is even an Association for Software Testing? Microsoft provides some great information too. There is also a great website dedicated to software testing – Software Testing Fundamentals.

2 thoughts on “Software Testing – Methods

    • Hi David, Thanks so much for following and commenting. I think I just touched the tip of the iceberg with this topic – and it’s been interesting for me to learn some more official terms (instead of my typical “try this, does it work, no, try this, did that work” approach. The site needed a little color and I’m hoping to fine tune a couple of things with font and color soon too. Thanks again!

Thoughts?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s