{"id":283,"date":"2022-11-29T21:37:22","date_gmt":"2022-11-29T21:37:22","guid":{"rendered":"http:\/\/learnlearn.uk\/ibcs\/?page_id=283"},"modified":"2023-06-03T22:26:14","modified_gmt":"2023-06-03T22:26:14","slug":"testing","status":"publish","type":"page","link":"https:\/\/learnlearn.uk\/ibcs\/testing\/","title":{"rendered":"Methods of Testing"},"content":{"rendered":"
\n

Dry-Run<\/h2>\n
\n\n

Dry Run Testing<\/h3>\n

\"\"<\/p>\n

This is where the programmer walks through the code, either on paper or on screen, to see if they can spot any errors. Usually this involves tracing the value of variables (either mentally or using a trace table) to see if they can find a particular bug. The process might also happen as a check before running the code, especially if the code is writing data to an external file or database.<\/p>\n

Dry run testing is performed throughout the software development process, as and when required, and is usually not specified within the testing plan.<\/p>\n

 <\/p>\n\n<\/div>

Walkthrough<\/h2>\n
\n\n

Walkthrough Testing<\/h3>\n

\"\"<\/p>\n

Walkthrough testing is a form of peer review in software within software engineering where the programmer guides others (e.g. managers, users, customers) through the documentation specifying the software being designed, so that any errors or improvements can be spotted and changes can be implemented.<\/p>\n

It is mainly done within the design phase of the software development process, before any code has been written, and usually involves any high level documentation, such as\u00a0 structure charts<\/a> or state transition diagrams<\/a>.<\/p>\n

 <\/p>\n

Example of what happens when you don’t do walk through testing…<\/a><\/p>\n

 <\/p>\n\n<\/div>

WhiteBox<\/h2>\n
\n\n

White Box Testing<\/h3>\n

\"\"<\/p>\n

White Box Testing is any software testing where the tester has access to the source code of the software under review. This type of testing is completed throughout the development process, especially the development and testing phases.<\/p>\n

Access to the source code allows the program to be inspected directly through the use of dry run testing and the use of trace tables.<\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n\n<\/div>

BlackBox<\/h2>\n
\n\n

Black Box Testing<\/h3>\n

\"\"<\/p>\n

This type of testing is where the person performing the test only has access the the compiled code, such as a beta version of the software, and they can only perform tests by running the code and analysing the results of the code, not the code itself. Beta testing involves black box testing.<\/p>\n

The user only knows the intent of the software, not the details of the implementation.<\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n\n<\/div>

Unit<\/h2>\n
\n\n

Unit Testing<\/h3>\n

This is where each component of a system is tested separately. Unit testing is often automated through the use of unit test<\/strong> modules or through external software.<\/p>\n

 <\/p>\n\n<\/div>

Integration<\/h2>\n
\n\n

Integration Testing<\/h3>\n

\"\"<\/p>\n

Integration testing is the process of testing how software components that have been developed independently work together. This can be done by combining individual components slowly together one at a time, or through the use of big bang testing<\/a>.<\/p>\n

Often when software components are developed independently by large teams the success of their interaction when part of a larger system cannot be guaranteed, especially when different practices and standards are used.<\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n\n<\/div>

Alpha<\/h2>\n
\n\n

Alpha Testing<\/h3>\n

\"\"<\/p>\n

Alpha testing is a formal method of testing which is usually performed during the testing phase of the software cycle. It is a whole system test where users outside the development team (but usually inside the development organisation itself) test the system by using the software in an attempt to find bugs or issues. This form of testing can include both white box and black box.<\/p>\n

The advantage of using technically proficient in-house testers is that potential security issues are not revealed to external parties and the reputation of the software\/brand is not jeopardized by exposing users to potentially incomplete or buggy software.<\/p>\n

Another advantage of Alpha testing is that testers can use their technical knowledge to try to break the software using abnormal and boundary use cases that might not be testing during Beta testing.<\/p>\n

Once Alpha testing is complete the program then moves onto the Beta testing phase.<\/p>\n\n<\/div>

Beta<\/h2>\n
\n\n

Beta Testing<\/h3>\n

\"\"<\/p>\n

Beta testing is whole system testing that is performed after Alpha testing. It is usually performed by a wide number of users outside of the software development organisation.<\/p>\n

The advantages of Beta testing include:<\/p>\n