Testing

A Quick Guide to testing for our Koha project

What is testing?

Testing: The process consisting of all life cycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specific requirements, to demonstrate that they are fit for purpose and to detect defects.

Interpretation:

In other words testing is a procedure conducted throughout the life cycle of a project to determine if the work being produced meets the requirements and the requirements being produced meets the needs of the business.

The V Model



Unit testing:

There are different levels of testing what we hope to achieve is module testing. Module testing also known as unit or component testing phase, module testing is concerned with the testing of the smallest piece of software for which a separate specification exists.

A quick word on black/white box testing:

Testing processes can be placed into two categories white box and black box testing.

Black box testing: where the tester who is testing the application, program, toy, car, etc cannot see what is going on underneath, In the memory, code, electronics, in the engine and gearbox. The tester enters inputs and watches the output. Do the outputs conform to requirements given the inputs the tester has entered?

White box testing: Is the opposite of black box testing the tester can see what is fully going on in memory and see is the code, gearing, electronics doing what they should be doing.

Definitions:

Quality : The degree to which a component, system or process meets specified requirements and/or user/customer needs and expectations

Test Plan: A document describing the scope approach, resources and schedule of intended test activities. It identifies amongst others, test items, the features to be tested, the testing tasks. Who will do each task, etc...

Test Objective: A reason or purpose for designing and executing a test

Test Case: A set of input values, execution preconditions, expected results abd execution post conditions, developed for a particular objectiveor test condition, such as to exercise a particular program pathor to verify compliance with a specific requirement

Some thoughts:

Koha probably gets a lot of black box testing from the users and probably not so much white box testing. If there are any bugs/ to be found it is most likely to be found be low level testing of component testing and if not then we get some practice with component testing.

Some program paths/algorithms/areas of code might not get run very often when the software is being used, meaning bugs could go unnoticed.

Some quick points when looking at modules to test:

-what does the module do?

- is it at a level you understand?

-can the code be written more efficiently/better/clearer?

-does this code need better commenting?

-can this module be fully tested by blackbox testing?

-is this module difficult to test on its own?

(does it rely heavily on other modules, is it possable to create a test frame?)

Aim: What do we want to achieve in terms of testing?

Want to go through a few example perl modules, and different type of testing methods

Once everyone has more or less developed an understanding of Perl it would be good if everyone could work on testing some Perl modules either on their own or in collaboration with someone else.

Does anyone else have any other Ideas suggestions or questions?

Do we want a test plan/How do we want to create our test plan?