Tyler and Jess won't know if they can make it until the end of the week.
Review tssg.tech classic and webflow site changes
Tyler
Tyler will check with the QA group on these changes before these are done to the webflow and classic sites.
webflow - should say qa study group instead of team. Quality Assurance Study Group
remove 'Discussion' whether classic or webflow
technologies for QA (webflow and classic) - No Azure, AWS, VirtualBox.replace with 'Docker and other approaches to virtualization'
Also remove Cucumber, Geb, Spock from QA tech list.
Update releases in Jira
Team
We spent time trying to update releases etc. in Jira.
2.0 (1) and 3.2.1 (4) releases in Jira have outstanding tickets (not done; in progress)
2.0 tws-39 is in progress. We set this to done along with some associated tests that were failing. I added a comment to this saying that the tests should be applied to our latest code and that we might want to re-write the stories for bugs that we are still seeing in v3.3.0 or later.
For 3.3.0 we need to complete testing now that it's deployed.
For multipage/classic changes we need to come up with more development stories.
Review open/closed Epics
Team
Drew - TWS-111 continue reviewing other CMS ?
TWS-115 setup test automation tools this epic is probably done. might need some more comments/documentation.
TWS-119 Deploy code to tssg.tech - is this epic really done? Label it done? Or is this an on-going task that we need to add more stories to as we continue deploying with Jenkins projects?
General Questions for Ralph
Team
For a given release, can we just set status of an issue to DONE to close an issue (even when there is a series of inner tests (test case executions) that have FAILED)? Just comment on the existing failed tests as related to 'old' code and move on to a more current issue/release? Ralph A. Navarro Jr. response:
If the failed tests are not going to be addressed, then mark them as Done and indicate the reason in the comment.
Do the same for the parent issue.
However, if the failed test will be worked on in a new release, then add the release to the Fixed Version field values and mark the issue as In Progress. You can also add a comment to indicate which release the issue was not resolved in, and specify the release that the issue will be resolved in.
How do we keep the number of tests down within a single issue? There appears to be a huge number of test executions within a story/bug. Story -> each single test -> multiple test executions (each contain an individual tws-###) Ralph A. Navarro Jr. response:
If an issue requires a large number of tests, then leave them in. Same with the test executions. Make sure to set the test executions to the correct version that it is tested in.
Jira Test case reuse question. Do we keep stories and their tests that work across versions? (2.0, 3.2.1, 3.3.0...). If so, what's the cleanest way to do this? As an example - the variations of the hamburger/menu problems on a phone that seem to come up with every release. Ralph A. Navarro Jr. response:
For a test that will be reused across versions (probably most if not all tests),
Start to organize by creating Test Sets and drop the tests into them (e.g. UI, Regression, BackEnd, etc.)
Create a Test Plan for a given release by adding the Tests or Test Sets into it. Note the Tests within a Test Set will get added to the plan, not the Test Set itself. This means that if you add any Tests to a Test Set after the Test Set was added to a Test Plan, you will need to either a.) re-add the test Test Set to the Test Plan (Tests won't get duplicated) or b.) add the individual Tests to the Test Plan directly.
Ensure that you have a story linking the bug as "blocked by". In other words, the story is blocked by the bug. This will ensure that the bug gets fixed (i.e. marked as Done) in order to set the story as complete (Done).
Action items
For 3.3.0 we need to complete testing now that it's deployed.
For multipage/classic changes we need to come up with more development stories.
Questions for Ralph. See Ralph's response in Notes.