CS4218 Module Review – Software Testing 16/17 Sem 2

CS4218 Software Testing was the last CS module that I took in NUS, certainly a good way to (hopefully) end off my university life.

Summary

It is a relatively easy module in the bracket of 4000-level CS modules. Although the module is solely on the topic of software testing, the depth of the knowledge required is surprisingly low. This is probably because there are a lot more sub-topics to cover in software testing than most people know, and we can only cover the surface of each sub-topic.

Module Content

The content is pretty much everything that you need to know as a software engineer on the topic of testing and debugging, plus some knowledge that you will rarely use in the future.

To lay some foundation work, the module starts off with concepts like control-flow graph and def-use pairs. These were briefly introduced in CS3219 (Software Engineering Principles and Patterns). It goes one step further into different slicing methods in debugging and a little bit of symbolic execution.

Then it goes on to talk about everything on debugging, using the concepts learnt previously. After debugging is the bulk of the main content on software testing. Here we have different testing methodologies and approaches. Two main paradigms in testing, functional testing (testing from the perspective of requirements) and structural testing (testing from the perspective of code) are discussed in detail.

Other topics covered includes combinatorial testing, mutation testing, OOP testing, assertions, user interface testing, performance testing and distributed system testing.

Assessments and Exam

The module has one midterm exam, one final exam and one term-long project broken into several phases.

The exams are based on the concepts taught in lectures, most of the questions are on specific topics. Only one final exam question was a senario question, requiring an “essay-like” response integrating everything you learnt.

The project is about applying the different testing concepts to a toy Java application. Each team has 4 team members, the choice of teammates is not restricted. You will need to implement some features, write test cases following certain methodologies, and write short reports. Overall the load for the project is moderate, and should not take up a lot of time.

Tips and Advice

• Do not spend too much time on understanding difficult concepts, some of them are very abstract and fragile, only existing in academic papers. It is not worth it to drill down into details.
• Divide the workload of the project, but be ready to change. Some components seem to be easy but actually require more work, vice versa.
• Take it with friends who are competent in coding, or find such person for the project.