• English

      • Definition of Done

      The Definition of Done (DoD) gathers the requirements a story or task meets before it counts as done. It is not a step-by-step sequence: the requirements must all be met regardless of order, although some depend on others — QA testing, for example, needs an already-deployed version. The flow is iterative: it goes back to earlier stages to fix errors or address code review suggestions.

      Code

      Writing the code is the first stage of value delivery and it meets the coding standards established by the team:

      • Code guidelines: the code follows the project's coding guidelines — format, structure, variable naming, documentation, and best practices — so it stays consistent, readable, and easy to maintain.
      • Peer review: another team member reviews the code to identify problems, errors, improvements, or violations of the coding guidelines.

      Testing

      This covers the tests done by whoever develops the change, not the QA team's: the code meets the minimum unit test coverage. Not every team defines a minimum code coverage and not every component has unit tests: there are legacy products where adding them would require too high an effort.

      QA

      Functional testing ensures every delivery meets a minimum set of test artifacts, aiming for safe releases with a minimal level of customer-reported incidents. The test cycle includes:

      • Exploratory testing: helps learn more about the product being delivered and get familiar with its context. Not always necessary, but in most cases it adds value to the process.
      • Test cases: end-to-end test schemes written in Gherkin or natural language. They live in QAlity, the tool integrated with Jira. New cases are not always created: they can be reused from the test repository.
      • Bug reporting: every detected error is reported in Jira — as a Sprint Bug issue, as a subtask of the main task with the list of errors, or as a comment on the main task.
      • Re-test: verifies that a reported defect was effectively fixed, by re-running the test cases that revealed it.
      • Regression testing: after reviewing the fix for the last reported error, an exhaustive scan of the component verifies that the fix did not introduce new bugs.
      • Integration testing: validates the functionality as a single unit — not backend and frontend separately, but the complete flow as users face it.
      • Security testing: validates the minimum security requirements defined and approved in the Definition of Ready (DoR), to protect the integrity, availability, and confidentiality of our customers' information.

      Platform validations

      • Internationalization: the product is validated in its three languages: English, Spanish, and Portuguese.
      • Responsive: the three dimensions defined for our products are validated — tablet (735), web browser (1240), and mobile (320). For now this applies to the collaborator profile, and later to the leader profile.
      • Staff users in Admin flows: every flow built for the Admin user is also verified with the Crehana staff user over any other organization, because client-facing staff teams (such as Customer Success) perform actions on customer accounts.
      • Custom domains: every implementation is checked both on the crehana.com domain and on the customer's custom domain, replicating on the second every test done on the main one. The list is in Clientes con dominio personalizado (Confluence). Reference organization for testing: app.crehana.com.
      • Corporations: a corporation-type organization controls one or more child organizations. Validate that a corporate Admin can perform the same actions on any of its child organizations. The flow is described in the corporations guide in Notion.
      • Full Suite organizations: organizations that connect both products, Learning and Talent (like Crehana). For initiatives that impact the Admin or Collaborator sidebar or footer — for example a new section like Catalog or Documents — validate that the change is also reflected in these organizations.
      • Mailings: every manual or automatic email the platform sends is validated with frontend, backend, product, and QA criteria, considering the first level of personalization that already exists in Learning organizations: sender address, logo, and CTA color. The full criteria are in the mailing test case guidelines (Confluence).

      UAT

      User Acceptance Testing (UAT) formalizes the delivery of the proposed functionality. It meets every acceptance criterion detailed in the Definition of Ready, with the participation of the Product Owner, the Product Manager, or members of sales or operations. It is mandatory only for new functionality or component modernizations that require the final customer's approval; running it is up to the QA Engineer.

      Deploy

      The deploy closes the DoD: without code deployed and visible to the team, functional validation is not possible. Its meaning varies by team:

      • Done: the version is deployed and available in the QA environment.
      • Beta: in the Apps team, the version was uploaded to each provider's store (iOS, Android) for their validation.