There were several things that i noticed/observed during the past few days:
- the task for QA Engineering team definitely has a flaws and has a disparity between the product team (designer, UX) and engineering team. The product and engineering have ‘weekly limits’, for example burning the 10 story points (of course, you can burned more than 10 story points if you had a carried over ticket from last week)
- However, this thing actually backfired to QA since we don’t have a maximum “story points” or “closed ticket” thing. Meaning: we are reluctantly testing all those tickets and ensuring by end of Thursday, that ticket must be completed or ready to deploy, no matter how big that ticket or how big that story point or which tickets are coming from (if you have 5 developers on the team and at tuesday/wednesday all those developers ticket is ready to test, well, good luck with that)
- Honestly, i don’t like this approach because our regression test will be shorter than before and it will increase the potential of causing a bug in production later on (which is actually already happening that in the past few days we have a lot of issues coming in).
- Why this happens? testing time is reduced. Of course, there is a technique to overcome this such as: cherry-picking, round-robin and re-testing based on priority, but all of this thing will introduce defect clustering since you weren’t testing thoroughly, and hardly managed to conduct E2E testing
- Existing automation testing (both for UI, API and such) is not very complementary because it’s lagging behind with the many new features being worked on simultaneously. I need to rethinking again about this situation