Development

  • 1.1.7 – Suggest various types of testing.
  • 1.2.2 – Describe the roles that a computer can take in a networked world.

Testing

The world of software testing covers numerous different technologies and methodologies, and as systems become more complex, so do the ways we test them. Below is a chart which we’ll use as a guide for the testing you may be asked about on an exam. Following this, you’ll run through some activities which give you an idea of how testing is carried out in the real world.  

Static vs. Dynamic

Static testing means that the code is not run on a computer, while dynamic means it is. We sometimes refer to static testing as dry-run testing, and it’s something which is done using pen and paper. On computer science exams it’s common that dry run testing will include a trace table that one will fill out as they go through the program. 

The benefit of static testing is it can allow a programmer to discover logic errors that might not be apparent with just looking at the result of a program. Of course, many programming environment have debuggers which will allow you to go through code step by step and create something like a trace table. 

Practical activity: Trace tables

This site is for A-Level Computer Science, but the pseudocode it uses should be easy enough to follow. Pick a few programs and attempt to work through them on your own before looking at the answers. You should be comfortable with this sort of problem, as you’re likely to see it on an exam. 

Black box

Black box testing is about testing the software without seeing the code. This is done within a company, but is also done by the users themselves during beta testing. You may have heard of a friend beta testing a video game, or you may have been part of a beta test yourself. At this stage the product is mostly finished, though there are still bugs that need to be worked out. The company usually doesn’t have enough staff to find these bugs on their own, and so allows a select number of users to trial the product and report errors they’ve found. Beta testing can also be used to test usability and features that go beyond just finding errors. 

An alternative form of black box testing is done prior to a beta test, and it’s called alpha testing. This is done by the staff at the company. The primary difference between these types of testing is that alpha is done by professionals who follow test cases while beta testing is regular users that don’t use test cases. Test cases are a set of directions for someone to follow, such as click this button, check the result in that table, then close the application. There is an expected result that the tester should get, otherwise the test has failed. 

If you’d like to learn more about both alpha and beta testing, see this article.

Practical activity: Black box testing

One of the best ways to understand what happens in black box testing is to try it out yourself. To conduct black box testing your goal should be to break the program or have it perform in an unexpected manner. This means it should freeze, crash entirely, give bad output, lose information, or other things that a program shouldn’t do. To try this out, see the programs you’ve been given, and play around with them and note what sort of results you get. 

White box

White box testing is also conducted using test cases, but is done by being able to see the code. This type of testing is also called glass-box testing or open-box testing, and is usually done by someone who is a developer or who has development experience. Often times this goes hand-in-hand with debugging, which is the process of finding a removing errors from code.

Practical activity: White box testing

This is a two part activity, where you will first look at the programs that were provided in the black box testing activity, and then move on to looking at some algorithms created by someone on Github. These can both be found on the IT drive (it$) 

Task 1: In looking at the programs created by former students, what sorts of errors do you notice are not being detected? How could they have prevented these?

Task 2: Now look at the algorithms that are provided in the white box testing folder and choose one to work with. Try and choose something that no one else is using. First, figure out generally what is does, but don’t worry much if you can’t figure out the details. Knowing that is uses 3 functions to sort is enough. Next, play with it a bit to try and get a working example. Lastly, break this example and make some notes on what you found.