Week 11 [Mon, Oct 28th] - Project

tP: v1.5

  1. Alpha-test the product
  2. Fix alpha-test bugs, fine-tune features
  3. Update UG and DG
  4. Release v1.5 Thu, Nov 7th 23:59

tP: Release candidate → v1.5

Intro to tP Week 11

What's happening this week:

v1.5

  • Learning outcome: Able to apply internal quality control.
  • Product goal: Reach the release candidate (RC) version, ready for a public beta testing (i.e., the product quality should be sufficiently high e.g., no obvious bugs).
  • Strategy: Do an internally, and refine features as necessary. Improve tests, documentation, code quality.

This iteration focuses on applying internal quality control before the product is exposed to outsiders. 'Outsiders' here refer to other teams that will be testing your product during the practical exam dry run (PE-D).
In 1, you will do an alpha testing of your own product, and record bugs, which can then be fixed during 2.
Keeping in mind that this is your last chance to do any feature enhancements (due to the feature freeze in iteration v1.6), in task 3 you will decide which final touches you would want to implement, and proceed to implement them.
At the same time, the UG and the DG needs to be updated, as given in task 4.

Things to note:

This iteration is normally done in one week, but is spread over two weeks due to clashes with holidays. So, do the amount of work you would normally do if this was only one week long (i.e., no need to do more work because there is an extra week for this iteration).

The tP progress dashboard will stay in Week 11 for an extra week (i.e., even when we are in Week 12), to reflect that you can use Week 12 to do Week 11 tP tasks i.e., pending Week 11 tasks will not turn red until end of week 12.

Remind yourself of the project grading criteria:

Admin tP → Grading

1 Alpha-test the product

  1. Create a label alpha-bug in your issue tracker.
  2. Plan the alpha test:
    • Decide who will be testing which feature. Suggested: Assign two members (exclude the feature author) to test each feature.
    • Set a deadline (suggested: should be earlier in the iteration, as you need time to fix the reported bugs).
  3. Start testing as soon as the v1.4 jar file is ready.
    Test using the JAR file.
    Use the same steps we use in the PE, reproduced in the panel below.

Admin Practical Exam (Extract) → Steps for testing a tP JAR file

Steps for testing a tP JAR file (please follow closely)

  1. Put the JAR file in an empty folder in which the app is allowed to create files (i.e., do not use a write-protected folder).
    In rare cases, the team could have submitted a ZIP file instead of a JAR file. In that case, unzip that file into the target folder.
  2. Open a command window. Run the java -version command to ensure you are using Java 17.
    Do this again even if you did this before, as your OS might have auto-updated the default Java version to a newer version.
  3. Check the UG to see if there are extra things you need to do before launching the JAR file e.g., download another file from somewhere
    You may visit the team's releases page on GitHub if they have provided some extra files you need to download.
  4. Launch the jar file using the java -jar command rather than double-clicking (reason: to ensure the jar file is using the same java version that you verified above). Use double-clicking as a last resort.
    We strongly recommend surrounding the jar filename with double quotes, in case special characters in the filename causes the java -jar command to break.
    e.g., java -jar "[CS2103-F18-1][Task Pro].jar"
    Windows users: use the DOS prompt or the PowerShell (not the WSL terminal) to run the JAR file.
    Linux users: If the JAR fails with an error labelled Gdk-CRITICAL (happens in Wayland display servers), try running it using GDK_BACKEND=x11 java -jar jar_file_name.jar command instead.

  1. Report bugs you found, and even suggestions for improvements.
    • If in doubt, report anyway.
    • Apply the alpha-bug label to the bug report, as our grading scripts will look for it when assessing your contribution level for this task.
    • For this individual tP tasks to be marked as done, you need to submit at least 5 issues labelled alpha-bug.

If you want to smoke-test your JAR file on an OS not available within your team, you can post a request in the forum to see if anyone else in the class can help you smoke-test it on that OS.

The panel below contains guidelines your peers will use when determining bugs in the final product -- knowing them might be useful in preventing such bugs in your product in the first place. You may skip the 'General' section.

Some testing tips to get you started (not an exhaustive list)...

  • If your app references date/time of the computer it is running on (e.g., to calculate time elapsed), test if it can work if the computer date/time is configured to be in different formats -- different computers might use different date formats.
  • Test against all typical user mistakes e.g., typing two spaces instead of one

2 Fix alpha-test bugs, fine-tune features

  • Fix bugs found during alpha testing.
  • Fine-tune features, if needed.
    Here is another reminder about what you can and can't do during v1.6 feature freeze.

Ways to level up your tP game:

  • Consider increasing test coverage by adding more tests if it is lower than the level you would like it to be. Take note of our expectation on test code (given in the panel below).

  • After you have sufficient code coverage, fix remaining code quality problems and bring up the quality to your target level. Note that the quality of the code attributed to you accounts for a significant component of your final score, graded individually (based on the code attributed to you by the tP code dashboard).

FAQ Must we fix all bugs reported and all enhancements suggested by testers?

3 Update UG and DG

  • Update the User Guide to match the current version of the product. Reason: testers will need to refer to the UG during the practical exam dry run.
    • Remove mentions of any features not implemented yet, if any. As you are not allowed to change features during the iteration v1.6, there is no point keeping those in the UG.
      Alternatively, clearly indicate which features are not implemented yet e.g. tag those features with a Coming soon.
    • For those features already implemented, ensure their descriptions match the exact behavior of the product e.g. replace mockups with actual screenshots

  • Save the UG as a PDF file using this technique exactly. You'll need this file later when you create a product release. There is no specific file name convention for this version of the UG, but do use a reasonable file name: e.g., Contacts-Pro-User-Guide.pdf.

  • Similarly, update the Developer Guide (DG), and save it as PDF file.

  • Update the landing page (docs/index.md): Update to look like a real product (rather than a project for learning SE) if you haven't done so already. In particular, update the Ui.png to match the current product ( tips).

4 Release v1.5 Thu, Nov 7th 23:59

  • Do a as described in the Developer Guide. Do the release by the given deadline.
    Do a smoke-test to ensure the jar file works (if the released jar file is broken, it will be omitted from the PE-D).
    • Include the following files in the release (as separate assets):
      1. JAR file
      2. UG (PDF file) -- uploaded as an 'asset' (similar to the JAR file), not embedded in the release note.
      3. DG (PDF file) -- similar to the UG
    • You may choose any suitable filename, but recommended not to have spaces or special characters in the JAR file name.
    • It is optional to write detailed release notes for this version.
  • You can do an additional release before the PE dry run (PE-D) if you wish, as long as you do it before 10 am Friday. That additional release is still considered part of v1.5 and therefore, not subjected to the feature freeze. When doing this additional release, do not delete the previous release (reason: it is good to preserver the release history) -- testers are expected to test the latest release file anyway. You may use any suitable version number for this JAR file e.g., v1.5.1.
    Waiting till Friday 10am to release the v1.5 is strongly discouraged because if you miss that deadline, your team will not be able to benefit from the PE-D at all. It is better to have an earlier release to fall back on in case that happens.
  • The feature freeze will apply at the point you released the JAR file that was used in the PE-D i.e., the features submitted in the final v1.6 later should be the same as the features tested during PE-D, which is the rationale for the feature freeze anyway.
  • As before, wrap up the milestone (i.e., reschedule/close any remaining issues/PRs and close the milestone).