New job, new project, new team - sounds exciting and motivating, doesn't it?
I recently met my friend, Alice. You might know her: https://www.zuehlke.com/en/insights/alice-in-agile-land-a-testers-story. Alice started in a new project a few weeks ago, but it was going anything but motivating. Apart from the cumbersome and confusing processes to get the necessary applications and permissions, Alice's new team was under enormous pressure and had neither time nor human resources to take care of her onboarding.
To make matters worse, Alice, being an incorrigible perfectionist, always wants to know and be able to do everything within the first days. Not an ideal combination, as you can imagine. And so, Alice was quickly demotivated and began to doubt herself.
At this point I would like to state that not all new engagements start badly or bumpily, of course, but there are certain patterns and behaviours that, in my experience, tend to cluster around sub-optimal starts. "So how can I get Alice motivated again?", I asked myself.
And here's my attempt to put a smile on Alice's face, and yours, and my call to take things a little easier.
The hit list of the most demotivating things Alice has encountered as a QA specialist (a.k.a. QA, tester, test/QA engineer, QA specialist etc.) and a, not entirely serious, guide on how to get rid of the new QA person as quickly as possible.
No time for onboarding or training Training only costs time and human resources, worst case development resources! It is not possible to send someone from the team to train a new QA person. After all, the new person works in the quality area. He/she will find his/her own way around...that's the least we can expect. QAs always know what is right and wrong, so they will find out for themselves what they need to know in order to do their job.
Outdated and/or confusing documentation (preferably in various locations) QAs need to be able to find their own way around. If they want to be good at quality assurance, then finding out which documentation applies is an easy exercise and there is no need to send another team member for personal guidance.
Role descriptions are a) set in stone or b) pointless a) Testing and QA are the same and people in these roles have the same duties, namely to automate and execute tests. They are also responsible for quality and have to take ownership of it. b) Why should there be a role description for QA? Everyone knows that QA is the person responsible for quality.
Tasks and expectations are implicit It is best not to talk about the specific tasks and expectations of QA persons at all, and if we do, then preferably in the absence of the persons concerned. People in other roles or disciplines can also provide very good information about the tasks of a QA person. As mentioned above, the role is very clear and does not need any further discussion. If there is a discussion about the tasks, the views of the person concerned are negligible.
Micromanagement QA specialists, and all employees in general, must be micro-managed. Otherwise, either nothing works, it happens much too slowly, or it is completely wrong.
Pressure, pressure and more pressure (preferably with no reason). QAs are used to working under pressure. They need it to do their job properly. It is best to make them understand this directly.
Independent thinking is not welcome Your QA thinks for him/herself? That must be stopped very quickly. Otherwise, it may get to the point where he/she questions the status quo or, even worse, wants to change things.
This role does not exist in the team Agile/Scrum/SAFe...does not write anything about QAs in the team. This means that these people do not belong in the (dev)team. They are not developers and therefore not part of the team. Some QAs, the really annoying ones, then argue that everyone in the team develops a product together, i.e. everyone is a developer, and all skills should be represented... this is also stated in the Scrum Guide[1], by the way...blah, blah, blah...they should just do their tests at the end and set them to green. That can't be so difficult.
Automation is everything QAs who cannot automate are useless. You do not need someone like that. We are agile and fast. Manual testing is far too slow. The best thing to do is to give the person the choice of either acquiring the appropriate automation skills or looking for a different job.
The person behind the role is irrelevant Don't waste time trying to get to know the person behind the QA role! This will only bring disruption to the team. He/she could bring experience, opinions or skills that change existing processes.
QAs are like that! QA people are all the same and always will be. They like to badmouth other people's work, to point the finger at other people's mistakes. They like being gatekeepers and enjoy it when they can block something. Extremely unsympathetic people they are.
Development tests - we do not need QA Our developers write their own tests and automate them directly. So we don't need a separate person for QA. Such a person only stops the development and wants to write many unnecessary tests and execute them manually. We do not have time for this.
QAs give training, do administrative work and take care of other things (which other personnel are too valuable for). The QA team has nothing to do between releases anyway and can therefore easily take over the training of new employees or the post-documentation. They know the applications well, both technically and professionally, through testing. This means that no specialist has to be assigned to train the new employees. BA/PO can concentrate on future sprints and releases.
All the little things and non-verbal communication that make QAs feel like they're not a full team member (especially since they don't write code).
Wow, there are a few more points than I would have thought at the beginning. The list is not exhaustive at all.
But does Alice let this get her down? Obviously not, otherwise she would have found another job long ago. Luckily. Otherwise, she wouldn't have the experience of working with great people who not only take quality and quality assurance seriously, but also value Alice as a person with her valuable capabilities.
More about what these people do differently and why they won't be getting rid of Alice so quickly another time.
[1] «Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint…The specific skills needed by the Developers are often broad and will vary with the domain of work.» Scrum Guide 2020)