Processes and Agile

Scrum, shift-left, releases

What ceremonies are there in Scrum and what is QA's role in them?

Planning: I estimate the testing scope and risks, so that testing fits in the sprint.
Grooming / Refinement: I ask questions about requirements, suggest acceptance criteria, look for edge cases.
Daily: status, blockers: no environment, a bug blocks testing.
Review / Demo: I show or help show the result.
Retrospective: what to improve in the quality process.

In an interview: At planning I estimate the testing scope and risks. At grooming I ask questions about requirements and suggest acceptance criteria, which is the most valuable ceremony for QA. At the daily I speak about blockers, at the demo I show the result, and at the retro I suggest process improvements.

What are Definition of Ready and Definition of Done?

DoR is when a task is ready for work: there are clear requirements, acceptance criteria, mockups, an estimate, known dependencies.

DoD is when a task is considered finished: the code is in main, code review is passed, tests are written and passed, critical-level bugs are closed, documentation is updated.

QA influences both: not accepting a task into the sprint without acceptance criteria and not closing it without verification.

In an interview: Definition of Ready is the criteria for when a task can be taken into work: clear requirements, acceptance criteria, mockups. Definition of Done is when it is finished: the code is merged, tested, and there are no critical bugs. As QA I watch both: without acceptance criteria we don't take a task into the sprint, and without verification we don't close it.

What is shift-left and how can QA give early feedback?

Shift-left is moving testing as early as possible in the process, because a defect in requirements is many times cheaper than a defect in production.

Review requirements and mockups before development starts.
Take part in grooming: edge cases, negative scenarios, contradictions.
Test cases before the feature is ready, so the developer sees what will be checked.
Testing the API when there is no UI yet.

In an interview: Shift-left is testing as early as possible. I review requirements and mockups before development, at grooming I ask about boundary and negative scenarios, I write test cases in advance so the developer sees what will be checked, and I test the API before the UI appears.

How do you support a release and the post-release check?

Before the release: regression, checking the release notes, confirmation that all the release's tasks are tested, a go/no-go decision together with the team.

During and after: a smoke of the critical scenarios in production (without real transactions, or on test accounts), checking migrations and configurations, monitoring errors and logs in the first hours, readiness for rollback.

In an interview: Before a release I run regression and give a go or no-go recommendation. After the deploy I do a smoke of the critical scenarios in production on test accounts, check the logs and monitoring, and together with the team I know under which conditions we roll back.

QA's role in Scrum ceremonies and the Definition of Done

At grooming and sprint planning QA analyses user stories from the point of view of testability, asks questions about edge cases and helps formulate acceptance criteria. QA also estimates the testing scope, so that the team's estimate includes it. This is where QA most effectively prevents defects, before any code is written.

At the daily QA briefly says what was tested and what is in progress, and voices blockers: an unstable environment, unclosed bugs, unclear requirements. At the sprint review QA can demonstrate functionality. At the retrospective QA suggests process improvements: for example, getting builds earlier or adding automated tests to the pipeline.

The Definition of Done is a team-wide checklist for when a task is considered fully finished. It usually includes: the code passed review, unit and automated tests are written and pass, manual testing against the acceptance criteria is done. Also: there are no open critical bugs, the documentation is updated, the changes are deployed to the test environment. Acceptance criteria are specific to a particular story, and the DoD is for all tasks.

Cypress in Jenkins or GitLab CI

The basis is running npx cypress run in the pipeline with the needed parameters: browser, config, specs, environment variables. The most convenient is to use the official Docker image cypress/included or cypress/browsers, where browsers and dependencies are already installed. In GitLab CI this is a separate job in .gitlab-ci.yml, in Jenkins a stage in the Jenkinsfile.

Secrets (logins, tokens, environment URLs) are passed through CI/CD variables or Jenkins credentials, not stored in the repository. Caching node_modules and the Cypress binary speeds up runs. Parallelisation is done with several jobs, each running its part of the specs: manually, through parallel: in GitLab, or through Cypress Cloud with the parameters --record --parallel.

Artifacts: screenshots and video from the cypress/screenshots and cypress/videos folders are kept only on failure, so as not to take up space. For reports Mochawesome or Allure are used, and the JUnit reporter gives integration with the tests tab in GitLab or Jenkins. Notifications in Slack or Teams with the result and a link to the report are also set up.

Which tests at which stage of the pipeline

The principle is fast feedback: the closer to the developer, the faster the tests must be. On every commit and merge request the linter, unit tests, API tests and an E2E smoke set run, a few minutes in total. A merge request can't be merged if this stage didn't pass: this is a quality gate.

After the merge into the main branch and the deploy to dev or stage a wider set runs: integration tests and critical E2E scenarios. The nightly run is a full E2E regression on several browsers, which may take long and doesn't block development. Heavy checks can also go there: visual regression, basic performance and security checks.

Before a release: full regression on staging, UAT and manual testing of new features. After the deploy to production: a short smoke to check that the main flows work. Unstable tests must not block the pipeline: they are isolated in quarantine and fixed separately.