Automation QA! You are derailed!
Well! Even you are not, when you opened this article, maybe you are the one who is afraid of that. It would be my honer if some of my experience could get you out from few hidden traps in QA Automation sectors.
In most cases, we are not lucky enough that there is always a whale statue can hold us as showed in above picture. Read more about the derailed subway in Netherlands happened in 2020. However, if you cannot find a “whale statue” for your QA Automation team, let’s try to avoid it then.
Revisit our roles and missions, amend solution iteratively
The QA automation team is very fragile when there is no defined roles and missions. By the market trending in QA Automation sector, we are trying to delegate more and more QA automation work to every engineer from different teams, through this transition, it brings up 2 topics generally:
- More work delegated into Dev
- What’s the next role for QA Automation team.
10 years ago in Beijing, when I worked in Baidu, I still can recalled that How do our QA team start to learn Watir (a similar tool like Selenium in Ruby, released at 2005), to understand what’s the modal automation testing in the world. It’s like I opened a fresh new window in my life. It impacted me until now.
5 years ago when I was in Alcatel-Lucent in Paris (which was bought by Nokia at 2016), people are start talking about Behaviour Driven Test (BDD test, which first been introduced at 2009 by most of people).
1 year ago when I was in Tommy Hilfiger in Amsterdam, we are trying to implement Contract driven test to check micro services and Frontend as a whole.(The idea of Contract driven test raised around 2016, 2017, but not sure).
Around same time, people start to talk about AI in testing. I know AI is super hot around the world.
I’m not a person who can lead this QA Automation development trend, I believe that most of us are same, but we use different technologies in our daily work with big pace in QA Automation sector. We are the person to push this development.
A tool you structured year ago maybe already cannot support new use case. Such as what discussed earlier, once we delegate automation testing to engineers, does your tool fit for the case? So what’s our role as a QA automation guy? New techs changes our role and our QA automation sector super fast, maybe a clear definition of our role and mission would bring more sense before we put our hands on keyboard to code.
I suggest following ways to keep tracking our roles and missions in QA Automation team. (why are we so special? We are QA, but also we are developer, and we are also the QA of our own developed tools).
Time to summarise our idea:
- Bring about the role and mission into work-able Epics or Labels in your Agile work
- Revisit our role and mission every sprint, not only mark it as a slogan, but link your day to day work, your Jira tickets with your role and mission.
- Adjust your role quarterly with team, the role and mission should 100% reflect what team were doing, if not, either we are wasting time, or the role need to update.
Rethink about our customer’s requirements, adjust our work iteratively
10 years ago the world is super rude in QA Automation sector, a test result sometimes is just a sentence.
I tested, passed. / No, there are several bugs.
Our customers only need to know your decision, they will release only when you said YES.
5 years ago, we provide a test report with pass/failed percentage. Guys were asking why it failed, we may said:
Flaky test / network issues
Our customers don’t ask more after, it’s not because they agree with what you said, it’s because they don’t care. Our QA and Product Owner hold the key to release. As a result, automation testing becomes a number with several excuses.
Now, none of them works, our customers will directly contribute to Automation testing, they need to know what has been tested, what can be improved, do we have duplicated tests, how can we test locally. Customers want to run test against their code to increase quality confidence and etc, customer want to have enough flexibility within the scope you defined.
What has been changed? The work interface has been changed between QA automation guys and developers, the requirements are fully different. The way to maintain the project has been changed.
Flaky test / network issue cannot be anymore excuses of QA Automation team. Our “shity” workaround/TODOs will be 100% transparent to our customers. It requires more skills in coding and planning.
Time to summarise our idea:
- Assess the requirements and work direction with our customers quarterly, but get feedback daily, sprintly.
- Use JIRA as the place to put and manage requirements, the work we will do should link to the requirements.
- Comparing to exhausted chase the new technology or new tools, we’d better to define and write down what do you really need in current stage. (Not just thinking, it won’t bring any value after you wake up tomorrow)
- A wrote-down customer requirement lead the team, instead of an idea in the fly. Try to review what you wrote down every sprint, and review them with your peers.
Build the momentum with our customers iteratively
If you or your boss decided to move to work closely with your customers, and your customer start to contribute to the automation testing, but no one talk about a predefined momentum in automation team, logically we cannot achieve what you expected at the end.
A great designed momentum in automation team can lead healthy cross team co-operation, a momentum is not a meeting QA automation and engineers sit together to talk what we should do or shouldn’t do. It’s part of automation team strategy to make the work become more valuable, and build up a smooth way to work and improve in long term.
Good Example time:
you wanna sell a “shity” sedan to your customer, you promise you gonna fix and improve this “shity” sedan, or even replace it by a new one, but your customer need to tell you the expectations and feedbacks of this shity sedan in the future. You fixed the shity sedan based on customer’s expectation, and your customers are quiet happy, he tells his friends also come to buy this sedan, the new customer tells something new, and our existed customer tells provide feedback to us, we amend our car by feedbacks, and add new features to our car. As result, the new customer will bring another new customers.
The momentum can build like this way with multiple players in 2 ways. However, let’s never guess or build momentum by your own team, such as single player inside of the momentum, this momentum will lead you be derailed soon.
Bad Example time:
You wanna sell this “shity” sedan again, when you develop this shity sedan, you think I need to change my gear box from 5 gears to 100 gears, to make it more scalable for our customers. After you finish it, you think it’s better to use big tires so our customer can drive this car in any road. Finally an internal momentum built up, we even also have requirements, and doable works, however, at the end, I think you built up a tractor instead of a sedan.
QA Automation team can be in different stages, there is no a common suggestions or standards about how to build the right momentum, and let’s try to find a place among all of those busy meetings to define our roles, missions, momentum. It’s not late even you are already derailed.
I’d like to thanks for your reading, as a result, I also wanna hear more feedback from my readers which would bring more ideas for my profession daily work, also can write more articles in the future for my readers.
