Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Scrum Teams often write automated tests for User Story's Acceptance Criteria. So every sprint the number of these tests increases. I suppose that many of these tests use browser testing frameworks like Selenium and, thus, are slow and heavy-weight.
Doesn't it break the concept of Test Pyramid (where we should have small nummber of high-level, slow tests)?
You're exactly right. It can be great to build a robust set of regression tests, but interface-dependent automated tests are more fragile than many other testing approaches. Ideally, you should only test UI-specific behavior through the UI (including automated selenium tests). So, for example, if you want to test if an error message is displayed, this sort of test is fine. However, functional behavior should not be tested through the UI if possible.
For example, if you are testing that passing a bill's due date puts the account into a suspended status, I don't want to test that through the UI. I'd rather test that directly against the objects in the code.
Where many teams struggle is if the testing skills are separated from the development skills - in different people that don't collaborate or worse - in a different team. Really implementing what's suggested in the test pyramid requires a lot of collaboration in the team so tests are happening as close as possible to the code under test.
