Fernando chaves - Teste técnico para vaga júnior de QA

[FernandoLauChaves]

No description provided.

[campofernando]

Hello @FernandoLauChaves! Thanks for your submission. Just letting you know that we got your pull request and are in the process of reviewing it. We will soon provide you with our considerations.

[campofernando]

Hey @FernandoLauChaves your project shows a solid foundation in Cypress and good software engineering practices. The repository is well-organized with a clear Page Object pattern, descriptive test names, proper use of cy.intercept for API validation, and a well-written README with setup instructions. The use of cypress/grep for tag-based filtering also demonstrates familiarity with the Cypress ecosystem. Code readability is one of the strongest aspects of your submission.

That said, there are areas to improve. First, the project did not run out of the box — the cypress/grep v6 package changed its API: the plugin setup in cypress.config.js should use const { plugin } = require('@cypress/grep/plugin') instead of require('@cypress/grep/src/plugin'), and the support file cypress/support/e2e.js should use import { register } from '@cypress/grep' instead of a default import. These are named exports in v6, not default exports. Additionally, the allowCypressEnv: false property in cypress.config.js generates a misleading warning and is unnecessary. Second, the test for the header metadata does not account for case-sensitivity (uppercase vs. lowercase), which means visual discrepancies between the prototype and the actual UI could go undetected. Third, while you validate that three charts exist, there are no tests checking their titles or legends ("RMS Acceleration", "RMS Velocity", "Temperature"), which is a gap in coverage. Fourth, the tooltip test only asserts existence and opacity but never verifies the actual data values displayed — the requirement explicitly asks for data to be shown on hover. Similarly, the error-handling test (cy.get('body').should('be.visible')) is too generic to catch any meaningful behavior. Finally, the REPORT.md raises valid usability concerns, but a more structured bug report with screenshots, steps to reproduce, expected vs. actual behavior, and severity classification would better demonstrate your reporting skills.

Overall, your organizational skills and code quality are commendable. The main opportunity for growth lies in writing more assertive test validations — moving beyond "does this element exist?" to "does it display the correct content?" — and in ensuring your deliverable runs without intervention.