Suggest various types of testing.


Teaching Note:

The crucial importance of testing at all stages of implementation should be emphasized, with the stages clearly defined.

Types of testing can include: user acceptance testing, debugging, beta testing.

Students should be aware that there are programs that can test other programs, thereby automating parts of the testing process and reducing costs.

S/E Inadequate testing can reduce employee productivity and lead to end-user dissatisfaction.

Sample Question (former curriculum):

Identify three different types of data that should be included as part of a testing strategy. [3 marks]


Sample Question (former curriculum):

Outline a method that can be used to test a program. [2 marks]

JSR Notes:

Firstly keep on remembering that we are dealing with Systems here throughout, so it's testing of systems, not necessarily software testing, but that's a good place to start; one of the general stages of testing is software testing and you are familiar with it. But various stages of software testing are just subsets of overall system testing.


Types of Testing:

Debugging (removing the bugs, i.e. the errors) - this is a software only kind of testing.

There are three general kinds of errors you need to check for, and debug.

- Syntax Error, i.e. the "grammar" of the programming language (Netbeans does that for you with red squigglies)

- Semantic (Logical) Error - This is an error in logic. Netbeans will not catch these, i.e. no red squigglies. A simple example of a logic error is where, for the calculation of an average, you add up 6 numbers and divide by 5 - no syntax error in your code, but it's logically wrong.

- Runtime Errors - These only occur when you run the program, and it freezes or doesn't function properly. (There is no need to understand the kinds of runtime errors they are, but they are the kinds of things we use Java exception handling to try to catch, like IOExceptions, and NullPointerExceptions, or NullPointerExceptions, when a String is attempted to be handled as an int.)

--> Software Testing Considerations/Strategies:

- Test that all of the outputs are as expected

- Test for completeness, and check against the criteria for success

- Assure the actual intended users to test it (not just the developer who knows the program and how to use it inside and out.)

- Test for normal (eg: 90%), abnormal (way out of range and wrong data type, eg: 110% or -10%), border cases (eg: 0%, 100%, passing grade), extremes (eg: no percentage example.)

- Netbeans and other more sophisticated software development suites have automatic ways to test and debug software applications. You can imagine that these applications are able to come up with appropriate data sets, and run that data through the program with the click of a button. This can reduce costs, particularly of big projects where there may be entire departments of people whose sole job it is to test software. (Note that this is referred to in the teaching note.)

In the case of the hardware components of the system, there are analogous considerations and strategies that must be followed for thorough testing before the system is rolled out for real. We don't usually talk about "bugs" in hardware, but there are many, many potential issues and limits which must be dealt with.

User Acceptance Testing
- This is the kind of testing you are in the middle of right now with your IA programs - does the user like your program, can they use it without your help, is it what they wanted? i.e. do they accept the software (or system) that has been developed.

Going through an agreed upon contract, or in our case, list of expectations is involved in such testing. Lawyers are regularly involved when there are disagreements, as you can imagine.

In the case of the hardware components, the user must also accept their quality, quantity, and functioning for the IT system to be considered properly implemented.


Beta testing - This is releasing a trial version into the real world. It is not a finished product, and you therefore expect errors, but so should the people who choose to try the beta version. Beta testing works best when there is immediate or regular feedback when errors occur. This is one of those situations where your program freezes and you are prompted to send a report about the error.

Hardware is obviously harder to test in a "beta" way, but certainly this happens. A good example recently is the various 3d printers, and various incarnations of them, which version by version get better and better, but the newest is alway bound to have a "glitch" or "bug" or two. Never-the-less, the consumers of the latest "beta" are happy to risk potential problems, by having the latest technology at their fingertips. (Mr. Peters and our 3d printer is a good example of this.)


Examples of various software and hardware in the proposed Hospital Database system:

- Testing the network systems by overloading the servers

- Testing the id cards - does overuse cause damage, what happens if they are cut in half or damaged in come way

- Thorough testing of all IT equipment in the ambulances and other first responder vehicles

- Testing of the various database system applications

This is just a small sample of the kinds and varieties of testing which would have to be carried out. Referring to the teaching note above, recognize that a major project of an IT company would be the planing and scheduling and assigning of the thousands of tests that would be required to make sure this system worked in all sorts of conditions. You can imagine charts and tables of all the various stages of testing needed to be carried out, the people and teams and indeed companies responsible for the various testing, the dates the testing needs to be completed by, and the next steps upon failed tests. In this case, the consequences of the system not being absolutely thoroughly tested is the difference between life and death for the patients served by the system.



CompSci2014.wikispaces.com x

WikiBooks.org **

Jamie: Unit testing vs. integration (i.e. with the other compenents to test interactions)