Transitioning company to automated testing. How to transition my own role?

šŸ„ New to Testing
1

Iā€™m sole the QA tester embedded on 2 teams with 7 total devs. Over the last year Iā€™ve learned automated testing and have been writing all automation on nights and weekends, but my company is finally ready to bring automation to my day job.

Weā€™re just not sure how to do this. My devs barely test on their own and frequently send items to testing with blatant issues that even bare bones dev testing would have caught. When Iā€™m out, the do zero exploratory testing and I always return to missed issues that are now in the wild.

Ideas - 1) devs write automated test code. Con to this is I donā€™t think theyā€™ll write good coverage and I really enjoy coding myself and donā€™t want to give it up.
2) hire a contractor to help with manual testing so I can focus on automation. This seems doable but Iā€™m still super slow and Iā€™m just working on functionality that already exists, not what is in sprints now.
3) I write test outlines and devs complete the test cases and then pass to another dev to do manual testing. We let the bugs escape if they do low quality testing and then learn from their mistakes. The extra time I save is used for automated test writing.

Any other ideas that have worked in your own small companies as you made the transition?

2 Likes
2

When my company originally started automating our code we got the developers to do the automation, but because they were not the manual testers they didnā€™t do a great job of it and, to be honest, didnā€™t enjoy it. We now get the testers to do most of the automation. But we recognise that getting the developers to review the automation means they can add a best practise lens to that automation.
You absolutely need more help. Doing both manual and automated testing is doubling your workload and if the quality of the coding is not great then itā€™s even more important.
Would it make more sense to hire an experienced automation engineer to automate existing functionality and you focus on new features ? Getting developers to test code, even if it isnā€™t their own is never a great idea. You would do a much better job ! Also it sounds like itā€™s time to shift quality more to the left. Remind management that testing does not produce quality software - good development does.

3

Hey Jennifer , Iā€™d love to help you but at first you have to take down the core of the problem in your team.
Quality is built by whole team and your Job as a QA is to help team to take an ownership for quality aspect of the product.
Iā€™ll list you underneath bullet point what i would do in your situation.
But first i want to Describe you why it should look that way.
Your team should definte DEfinition of Ready and DEfinition of Done for every User Story (If you work in Scrum) or Feature if you work more of waterfall system.
This would help you in taking a breathe and thing where to put your focus first.
Writing Unit tests should be a standard in every software developing environment. Remind Devs that thatā€™s their job and they are obligated to do it and cover the code lets say in 70% at first.
Manual testing , manual Regression ,Automated regression, Exploration testing and Integration testing and API testing are nothing more tools in your toolbox as an engineer . you cant use everything at the same time .Thatā€™s why your team cant expect from you that you will build quality in every way in the same time. It takes plan a Roadmap of sort which should be your next step. Thatā€™s how you will show more transparency and let them know how much technical debt there is to patch and try to take that piece by piece , sprint by sprint or week by week.
Try to figure out which test cases that you have to repeat every time and try to tag them as ā€œAutomation candidatesā€ then verify with the devs which of them should be automated first as ,what gives them the most value in short time. Sooo lets do some bullet points:

  • Create Definition of Ready and Definition of Done
  • Create QA Roadmap and Test plan for the next 6 sprints
    -Be transparent to the team (Show them how much time it takes to assure quality of their code)
  • Force them to help you( Unit Test , integration tests)
    -Set up the pace in development, if you canā€™t keep up with the testing , you are the bottle neck . Itā€™s not your fault , they have to adjust and help you with the resources they got (know how , another tester , slower dev pace)
    -Start to introduce automation for test cases that are most crucial and you know that automating them will give you the best value
  • You are not alone , Whole team is responsible for quality of the product.
    I hope it will help you.
    Good luck
    Maciek
1 Like
4

Great feedback. We do have A definition of done. We do not have a quality is the whole team mentality however. This is definitely something we need to work on but very hard so far to achieve. I did speak with the team about starting with the happy path test that we run weekly as the beginning point for automation. It sounds like Iā€™m on the right track with that and just need to make plans for after.

1 Like
5

You mentioned getting the developers to look at automated code for best practices. That is a great idea. As new to coding and new to automation one thing I know is that I donā€™t know the best practices I should be using and so far donā€™t have anyone to look at the code to tell me if Iā€™m anywhere close. Iā€™m afraid someoneā€™s gonna come in in a few years, look at my code, and think what the heck was she doing?

6

Have you considered pairing with your devs? Personally, Iā€™d suggest pairing both on exploratory testing (which will help them learn to test better) and on automation.

1 Like
7

This is a very challenging situation that often management think is easy so tends to be fairly common.

Often the starting hypothesis of viewing automation as a testing role responsibility can cause the most problems. This then can get compounded by QA/testers getting also viewed as the original QA responsibility of whole process improvement responsibility.

Your first idea is correct, automation endeavors should really start with developers and at unit level. However most testers in reality have very little sway over developer practices and telling them how to do their job well puts you into a dysfunctional policing role.

I mentioned on another discussion last week, if my primary contribution is testing similar to your case I add value to multiple projects but if I focus on automation its usually full time on one project at least initially. Iā€™m super slow too at automation so my value drops straight away.

I wear both tester and quality consultant hats and with the latter I would approach it as a whole team perspective but for testers without the consultancy experience as mentioned the policing risk is too high in my experience. Other comments here have made good suggestions but also they may be in a position of whole team influence.

Consider what are your influence levels and maybe take a first step having a quality discussion with the team, perhaps you can coach the team as a whole to have their own ideas on improvement without the policing aspect.

If it is just on you, perhaps have a small first goal of happy path smoke tests. Just build and run these locally until you are comfortable with them and are confident they add value. If you get to the stage to add them to CI then the discussion can get bigger as others may see the value and buy into expansion or adopting at different layers.

Adding more people also runs a risk that developers become even more detached from quality responsibility and in the long run this in itself can do more harm than the value automation brings to the team.

Have a look at the free videos on Test automation university. ā€œsetting a foundation for successful test automationā€ in particular is where Iā€™d suggest starting, ideally with developers involved alongside you.

1 Like
8

Hi there @teamofone and @qofd . Welcome to the most awesome Software quality community in the world. No, in the universe. Most of us have not been in your position, but itā€™s so good to see that bigger teams starting out have the same issues or worries. Hope we can encourage you this week.

OK Iā€™m trying to find out what it is you are testing, and far too often I wonder why it is that online forums never list peoples place of employ so we can approximately work out if they are testing a cloud-service, web, embedded-app, aerospace/automotive mission-critical or entertainment/gambling app. Because with that little bit of shape or context a person can point to more specific resources. Iā€™m looking at your questions Jenny, and thinking broadly.

  1. the tests that the developers have coded up, where, how and when do those tests execute? If the answer is manually, then I have an idea for you to build a sandbox that will help.
  2. itā€™s tempting to hire a contractor, I used to contract, they work hard and help, but once they go, the problems will most likely return, because it sounds like the issue today is endemic. Contractors are a tool, not a solution, they cannot ā€œfixā€ anything, they can only help build things.
  3. itā€™s normal for bugs to escape, and you are finding yourself in a situation where the team is trying to prevent them, trust me the devs donā€™t want escapees either. Bug-fixing is not fun, slows them down, and is tiring and demoralizing. Automating, however wont plug that gap that quickly.

Sherilyn is right, you want to get a Continuous Integration (CI) system going. I would start with a wiki page to plan your moves. I start with a page of what I have in the way of tools I could use and do use already. You might be using a script language, a cloud platform of some tool like fiddler and a variety of other tools. capture these on your wiki (we have a tools wiki here actually Ninja training for software testers | Ministry of Testing). Write down all of it.

Next, you want to build a test environment, a sandbox if you like with instructions how to set up a computer to run a test, this is where knowing what your product is would help, but for now gather the steps or guides to run those tests onto the same wiki page below your tools list. Work out how much it costs to set this up in terms of time and work out if you need to buy a new computer or a bit more VM runtime in a cloud somewhere. Work out if networks and security make running your existing automated and manual tests hard.

Next, before you stat to brag about your new way to prevent bugs escaping, try set up a script which you want to be triggerable from your automated build system, and work out how to grab all the test run artefacts, every last log, especially logs from external systems, into one place, and how to push those logs back into the build log/artefacts in Teamcity/Jenkins/whatever. Keep it broad though. Once you can manually trigger your Frankenstein test suite, little questions like, ā€œCan I get it to test a branchā€, ā€œCan I get it to test an different configuration of the productā€, or a different environment, and so on will emerge. Give yourself plenty of time to work out which problems you do and donā€™t want to solve. At this point I like to get the team lead and management on board to work out what priorities they have. They may want you to automatically trigger this to run every night now, take your time, look at security-workarounds and hacks you had to make, look at your test fixtures, and environment cleanness. These will take a while to bed down. Be prepared to fix your Frankenstein every morning, be prepared even to start over from scratch, and defend against that if needed.

Oh, and get the devs to help by getting them to do peripheral things like reporting and email integrations, they love that kind of thing. I hope my ramble, and it is a ramble; is useful to you Jenny. I hope the encouragement from Sherilyn has buoyed you up today too.

9

^^ Good stuff there from Andrew, just want to amplify his notes.
Here is the TAU linky https://testautomationu.applitools.com/ No, itā€™s not at all an appium focused thing, and is the most fun way to learn that should have existed 20 years ago already.