CS 7314/5314 (Spring 2024): Course Project

Prof. Jeff Tian (tian@smu.edu)

Assignment

Your course project is an integral and the most important part of your CS 7314/5314, an opportunity for you to apply the knowledge learned in your class, particularly software testing (and possibly other QA/quality modeling) techniques, in a realistic setting, and to report related experience, findings, and lessons learned. It will consist of three parts or stages: Some general information:

The details are given below.

Acceptable testing projects

Your course project will focus on testing, which may also include on other QA techniques or quality modeling (see next section below). For an individual project, it should include an application of at least 2 specific formal/systematic testing techniques/models to some programs/products/applications/services you are developing/testing/maintaining/supporting/using/considering. For example, you may choose to: and the list goes on...

It is generally a good idea to consider multiple formal/systematic testing techniques, preferably from different categories (e.g., both flat models and FSM-based models) and perspectives (e.g., BBT, WBT, and UBST), and then select and actually use at least 2 of them in your project to get a hands-on experience of how different techniques work in practical applications. Here is the rule regarding what can be counted as a formal/systematic testing technique for your course project:

Pay special attention to the evaluation of your testing/analysis results, especially the collective/overall analysis (e.g., defect/effort/etc. comparison across multiple testing techniques), in addition to individual test result analysis. Be prepared to answer the following questions:

Your answer can be based on either the practical evidence (executing several types of testing cases, observing the results, and analyzing the relevant measurement data) or based on logical arguments (suitability of certain testing technique on certain types of products), or both.

QA/SQE beyond testing in your project

Your project may also include other QA techniques or quality modeling (part of the SQE process), as described below:

Where to Find Something to Test or to Perform QA on?

Project proposal

Your project proposal should be around 3-4 double spaced pages in length, and should include the following information: In case of a group project, please also pay attention to the following:

Please keep in mind that by the time you submit your project proposal, we have only covered less than half of the class material, although an overview of the whole course is given at the beginning of the semester. Therefore, you may make certain modifications to the things you propose, but the basic framework should be in your proposal and remain relatively stable.

Once I have reviewed your proposal and provided my feedback, you need to address the issues I raised, in your final project report. However, in most cases, you do not need to submit a revised proposal. In the rare case that your proposal is marked as "unacceptable" or received 0 grade, I'll explicitly ask you to re-do/re-submit your proposal via e-mail.

Progress report

All the students are required to submit a progress report, if you are not doing a full presentation (see below) in class. Your progress report should focus on project progress you made so far, i.e., the main activities and results from your project after the proposal submission/review/feedback cycle. Here are some specifics about the progress report: I'll give you written feedback for all the progress reports submitted, which should be incorporated into your final project report.

Project presentation

You may choose to do a (full) project presentation. In that case, you don't need to submit the progress report. Each presentation should last about 10-15 minutes, with an appropriate number of slides. You need to highlight the problem/solution-strategy/results/analysis for us to get the basic picture, but not necessarily all the details, which would require much more than 15 minutes. One common mistake in the past is too much background information but not enough testing/QA-specific technical information. Also, avoid detailed description of the test cases and activities performed.

For distance students interested in making a presentation: I'd encourage you to make an effort to come to the campus to give your presentation to provide the opportunity for interactive discussions. However, if you have difficulty with it, pre-recorded presentation can also be acceptable.

I'll give you verbal feedback during your presentation, which should be incorporated into your final project report.

Project report

The project report should be treated as a term paper of your own, around 15 double-spaced pages in length, but no longer than 20 pages, for graduate students. The report should clearly and comprehensively states the background, problem, strategy, activities, models, test cases, results, result analysis, lessons learned, followup actions, and a high level summary (and an abstract at the beginning). Additional material, such as graphs, models, test cases, etc. produced, information sources and raw data, customer surveys, etc., can be included in the appendix and clearly marked as such (so it will not be counted towards your 20 page quota). However, graphs/models/tables/etc. central to the report should be included int the report itself, not in the appendix.

For undergraduate students, you report should be similar, except the analysis part (see information in the "Proposal" section above). As a result, your report is expected to be around 10-12 pages. But, if you choose to, you can follow the instruction for graduate students as well.

The format/sequence should be similar to what I listed for the project proposal, but, of course, with more results (what you did, including models and test cases produced, test results, result analysis, etc., and what you discovered/learned, not just what you proposed to do). Meaningful/descriptive headings/titles for individual numbered sections should be used to organize the report.

If you are not familiar with technical reports or papers, please consult technical/professional journals and conferences proceedings published by ACM, IEEE (particularly its Computer Society), and/or other reputable organizations.

Several common mistakes to avoid:


Prepared by Jeff Tian (tian@smu.edu).
Initially posted: Jan. 31, 2024. Last update: Feb. 2, 2024.

Back to CS 5314/7314 Webpage