lab06 : Second Retrospective, Product Improvement, Higher-Level Testing

num	ready?	description	assigned	due
lab06	true	Second Retrospective, Product Improvement, Higher-Level Testing	Fri 02/16 01:00PM	Fri 02/23 11:59PM

Points

Lab06 points, overview:

Graded: (lab06-I) (20 pts) You earn these points for submitting feedback on overall team performance via a second CATME.org form survey that you will get email invitations for.

Graded: (lab06-T) (20 pts) You earn these team points based on the logged attendance/participation in your second retrospective; 20/n points per team member for teams of n participants.

Graded: (lab06-T) (10 pts) You earn these team points when the content in the team/retrospectives directory is updated per the instructions.

Graded: (lab06-T) (20 pts) You earn these team points for ensuring that each team member was again assigned at least one issue that was moved to the Done column of your Kanban board with tested acceptance criteria over the next week ending on 02/23/24, 23:59:00 PDT. After moving an issue to the Done column, assign (a) new issue(s) to everyone who was assigned to the completed issue and move the new issue(s) to the In Progress column.

Graded: (lab06-T) (30 pts) You earn these team points if your team integrated a higher-level (not just unit tests) testing framework with your project and implemented and demonstrated successful execution of at least one component test or other integration or end-to-end test (e.g. BDD) in your project. Document your testing approach by extending your team/TESTING.md document. In combination with last week’s requirements, list there at a minimum: 1) how you implemented the unit test requirement from the previous lab (which testing library, which part(s) of the code, etc.), 2) your plans regarding unit tests going forward (it’s ok to not go all in with unit tests, but document and reason your decision.), 3) how you satisfied the component/integration/end-to-end testing requirement from this lab (which testing library, which part(s) of the code, etc.), 4) your plans regarding higher-level testing going forward (it’s again ok to not commit to an integrated testing solution, but document and reason your decision).

Second Retrospective

Either today, or at a time you schedule by you as a team, you will hold your second retrospective

You already know the goal and procedure for Retrospectives from your previous Retrospective(s). This particular Retrospective allows you to discuss things that emerged from the MVP effort and feedback you received.

You’ll do a quick standup and then either do the retro in team groups or schedule it and work on other lab requirements.
When you are finished and still have time, discuss your team’s strategy towards the testing requirement in this lab.
Staff will be dropping in to observe.

Retro Deliverable

In your team’s repo, under team/retrospectives directory Add file RETRO_02.md (or whatever number you are at if you did other retros already)

Add the following content:

# Retrospective your-nr-goes-here, date-goes-here 

* Led by: name-goes-here
* Present: name1, name2, ... , nameN
* Absent: name1, name2, ...

## Action item

* a goal: identify something the team wants to get better at
* a change: identify one thing that the team will change about how it works together
* a measurement: identify at least one way to measure whether the change helped the team acheive the goal, or move closer to it.

## Optional

* Record anything else you think the team might want to remember from this retro

After the Retro

Retro leader: add Section to team/retrospectives/RETRO_0?.md (use the correct number of your Retro)

## Retro Assessment

* A brief description of what retro outline or process you used.
* A brief assessment of how it went.
* What advice would you give to the next person leading a retro
  based on what you learned today?

Experiment Outcome Documentation

The team gets 10 lab points (see above) for documenting the experiment in team/retrospectives/RETRO_0?.md. Describe the experiment/change soon after your retro, and fill in the outcome and decision for the future when you have the results (insights) from the experiment:
```
## Experiment/Change

* A brief description of what constitutes your change/experiment
* A brief assessment of how its results (did it improve things? move the needle at all?)
* A decision going forward: keep the change, revert to previous procedure, make a new change? 
```

Grading for new Development / Testing

Over the next week, please focus predominantly on new/improved functionality/robustness/user experience for your product, using your momentum and ideas from the MVP effort and discussion.

Again, every team member should be assigned (and complete at least one) new issue towards this goal. Make sure that your issues have clear acceptance criteria in Github Projects and that you have a process for completing and assigning issues (e.g. feature branches or your own “Continuous Delivery” rules). It should be possible at any point in time to deploy your product with new improvements over time!

So, while focus should be on your product growing/improving, we want you to experiment more with Test-Driven-Development (TDD). This could be a great week to fully embrace TDD, and we think you would get many benefits from it in the long term. It is, however, more work in the short term, so if you don’t think that you are ready to completely switch over to TDD, then at the very least you’ll have to select a tool for component testing (a type of integration or end-to-end testing) and implement at least one component test or other integration or end-to-end test in your source code. Use of a Behavior-Driven Development (BDD) framework would also check this box.

Teams working with React could use the React Testing Library or Enzyme or Playwright or Storybook. Python backends could for example be tested with TestProject. Any group could use BDD frameworks Behave or Lettuce. There are many more options!

Document your testing approach in your team/TESTING.md document. List there at a minimum: 1) how you implemented the unit test requirement from the previous lab (which testing library, which part(s) of the code, etc.), 2) your plans regarding unit tests going forward (it’s ok to not go all in with unit tests, but document and reason your decision.), 3) how you satisfied the component/integration/end-to-end testing requirement from this lab (which testing library, which part(s) of the code, etc.), 4) your plans regarding higher-level testing going forward (it’s again ok to not commit to an integrated testing solution, but document and reason your decision).