Room
Track 1
Audience
Test Managers,Test Engineers, Automation Engineer,Engineering Mangers, Product Owners, Scrum Masters
Key-Learnings
- how not to get intimidated with conversations which challenge the existence of QA
- Stakeholder management
- how to challenge the stereotype and break it
- what needs to be done on our end to set the correct expectations and demonstrate the value we bring
Problem Statement: Like it or not - there are still multiple organisations or part of the organisations which do not understand the role of QA and what value we bring. How and where the problem manifests - the problem doesn't generally occur where the system under test is UI intensive and fairly visible and obvious test flows are possible.
However, when SUT is api/databases/data streams intensive - the confusion about what value we add to the process starts appearing.
How does this affect us:
Of course, this is something that senior QA engineers and leads are more or less used to or know how to cater to them but for relatively newer folks or people with less multi project experience can have a tough time and feel pressurized, demotivated and start questioning their job security at some point.
What I want to cover in the presentation:
- Acknowledge the issue and share some examples to identify these situations (as this type of situation can be direct but also very subtle)
- Share (based on my experience ) whats going on in the head of the person raising the concern (I have managed both QA and dev teams at different points in my career and kind of relate to both side of the argument)
- Talk about possible ways to handle these situations/conversations including handling the situation behaviourally and action based (this will cover some aspects of up skilling and learning)
- And closing with a message on why QA should not be considered as another team which was added by upper management and just delays the process.