I’d be interested in some feedback please on a change we are implementing.
I firmly believe in testers having good all round skills - technical, analytical and soft skills (in fact I’m doing a talk on this at TestExpo on 31st October), but am wondering whether something I want to implement is going to work as well as I hope.
We are looking at a new role in the team as a Software Developer in Test, and I have been conscious of the fact that a role with this title may lead to finding someone with all the right tech skills but none of the test skills that I need them to have. The problem is that I have manual testers in the team and we need to develop our automation framework to run smoke tests on build and overnight regression tests. The role supports the test function, but cannot just be a coding only role.
I discussed this within the management team, and we felt that rather than looking for a tester with coding skills, the gap could be filled by someone with more of a developer background. It does make a lot of sense, but I need someone who can define the tests, not just code what someone else has already told them to do.
Has anyone been on this journey? I’d be interested in your thoughts on this, and your experiences. Does it work in your team? Have you tried and found that it failed?
My company, ThoughtWorks, hires people into the role of ‘QA’ who are good at creating tests. These are people who have the skillset that a good tester would have. They may or may not know how to program and do automation.
We hire people into the ‘Developer’ role who are going at programming and software development. A developer can then pair with a QA to write automated tests. The QA knows what testing is needed. The developer knows how to write maintainable code to automate it. Additionally, if the code isn’t self-documenting, a QA who cannot program will know it and encourage the developer to write self-documenting code.
Essentially, developers pair program. This helps two developers become better developers. Having a developer pair with a QA helps the developer to be a better tester and the QA to be a better programmer.
Another model I have done, when the QA to developer ratio favours the developers, is have one QA who will review all the lower level, automated tests (unit, contract, service, etc.) and kick a story back to development if it hasn’t been done to their satisfaction. Actually, one step back… story (requirement) is kicked off by a BA, QA, UX and Dev. The BA and UX worked together to create the story. So they present it. They present it and the QA and Dev roles ask clarifying questions and help improve the story. The Dev implements the tests and requirements to satisfy the tests. When they are done they have a Desk Check. At this point, the developer should have enough automation and data to present a fully working story in a matter of seconds. If there is anything the BA, QA or UX wants demonstrated that the developer cannot do easily, via automation, then there isn’t enough automation. In this model, there might be one QA, one BA and one UX to every six Dev. So what to test is the QA’s responsibility but actually writing the automation is the Dev’s responsibility.
My experience has been that if everyone asks the right questions (at kick off and desk check), it doesn’t cycle back and forth. It might need a second desk check but usually not more. The full suite of automated regression tests can be run locally. So before a Dev calls for a Desk Check, they would have run all the automated regression tests and ensured they didn’t break any old requirements.
An SDET is a test code writing programmer. An expert software tester may or may not be able to write test code, but knows their testing. To me SDET is a step away from reality towards convenience. Also I’d keep in mind that testing is one of the most mentally taxing, complex and nuanced jobs in the industry and to say “oh, while you’re at it, I need to you to be able to write well-formed checks that serve a realistic and useful test strategy in production-quality, readable, and maintainable code in a language of my choosing” is a big ask.
Then again, maybe it doesn’t matter and it’s a business decision, not a testing or moral one.
My last paragraph usually contains some useful, positive and actionable suggestions, but it’s just after lunch and I need a nap first.
Thanks for the reply. You raise an interesting point about dev/test ratio’s, as it’s all about utilising the skills you have as best you can.
We have a team with a tester who does a great job manually testing the stories, but we also want to bring in the skills to help us write automates regression and smoke tests (checks!) to give us confidence that what we built previously still works, and what we deploy is working. Doing this work manually is too time consuming, so we want this to complement the manual testing that we do.
I guess the role title is not important, its the skills I want to bring in - but I think changing the name means that people in a role called SDET and looking for a similar role, may not look for ‘Tester’ in their search, so it means our role has a greater chance of being found if we are also using SDET as a title.
At the end of the day, I want a good tester (someone who can definitely ask questions) - who just happens to have the skills to write automated tests. How hard can it be??
Good point - its a complementary role to work alongside a tester and developers, hopefully bridging a gap. I think it can work, and we will probably need to do some refining along the way. I think it’s good to try something different to what we have always done before.
If you are worried about the right candidates finding and applying for the job, make sure the job posting finds the people with the right mindset.
How a tester or QA think about things and how they look at a piece of software is what makes them different from many software developers. Someone who will make a good QA is someone who is good at hunting things down. Trust that they will find many job ads, you don’t have to worry about that, you just have to make sure they apply for the job after they find your ad.
Realistically, it is REALLY hard to teach someone to think like a good QA. It is easier to teach a good QA how to program. Additionally, if you have to do all the work to find a good QA… how good are they? A good QA will find you.
However it is much easier to find a cs grad or junior developer than it is to find a decent tester. I suspect what will happen is that companies will recruit junior devs or recent CS grads, for whom Selenium Webdriver etc. would not be very difficult to learn, and get testing coaches in to train them.
Two of the previous companies I worked with tried this experiment with the existing testers.
Automation was tried at these levels: unit/integration testing, desktop ui app testing, api testing.
The languages used: C/C++, vbscript, python, Java, + some batch, C#, and other tester prefered languages.
Some people learned it fast and were able to contribute. Others were weaker in a particular language, creating useless code or taking ages to write a very good piece of code.
The time consumed compared to the benefits was really high. Bug finding decreased, new features weren’t tested that well - due to more than 50% of the time of all testers in average being spent on automation repair/maintenance/building.
All automation died, was stopped, thrown away, forgotten in the end anyway.
