Abstract
Today, I’ll jot down my experience in test automation. It’s about 4 years ago when I began my career as a test automation engineer. I’ll try to make it simple, but I’m sorry, it is likely become an awkward story.
This is a story written to answer https://docs.google.com/forms/d/e/1FAIpQLSfAvujc8HN23SqJ6IEkP9xd4grOOfN4GecjO8g3PXL10oUEEQ/formResponse
The first job as a test automation engineer
4 years ago, I switched my career to a test automation engineer. The reason may be long, so I just say I wanted to automate tests.
After switching to test engineer, I started working on E2E test automation at a client’s office. The application under test(AUT) is sort of safety confirmation system. The main test scenario is that first you manipulate the AUT, then you check if an email are sent to expected group of people(i.e. email address).
I had a great predecessor who had worked on implementing core logic and one of main test scenarios, and configuring CI environment we needed. Based on my predecessor’s work, my 2 colleagues and I started working to scale automated tests. scale means like increasing test patterns. All test scenarios had a common pattern(e.g. manipulating the web page and receiving e-mails from the web page).
The end of chapter
The project became to the end of one chapter. One of my colleagues, a young potentially brilliant engineer, went out due to lack of client’s budget. The other one of my colleagues, also a brilliant veteran engineer, went out because he tended to be absent. I kept working there. I was responsible for operating(kicking) the automated tests and implementing new automated tests.
Inside the project
Let me explain about some detail of the project. The main goal is to achieve shorter time to market by automating regression tests. The client works in water fall process. The client employs software developers and outsources software testing to us. We choose Selenium WebDriver, Spock, Groovy etc, and automated around 150 test scenarios. As a CI environment we selected Jenkins so that everyone can kick automated tests. I kicked the automated tests on the need basis only before releasing. It’s at weekdays night or weekends. It’s about once every 3 or 4 months. When we started running the entire automated tests, it would take from 40 to 50 hours. As long as I know(I spent 1.5 years with the client), we found 2 or 3 faults by the automated tests.
Good things
- For the first time it’s really stimulating to see automated test. It’s like you’re hacking browsers.
- Effectiveness of test automation had been described clearly(It certainly shorten time to market).
- As one of man-month projects, there was a beautiful switch from a senior engineer to young engineers.
Problems I left
1. Hard to practice CI
40 hours is too long for automated tests. Although it depends on companies what test you automate, it makes difficult to run every night. This is what you call ice corn pattern.
2. Huge impact when all automated tests fails at night.
I had kicked automated tests at the end of day and checked the result at the following day. What if all the automated tests failed? It likely happen for example when the test environment has a problem and all the test fails due to the same cause. It’s a sort of critical hit to me when we were on a tight schedule. I had to check in advance if the test environment was rightly provisioned.
3. Flakiness in IE.
I had to injected retry logic. MS has announced that IE is deprecated. I wonder how they are doing.
Summary
As I expected, it’s like an awkward story, but I really appreciate all of my stakeholders. I hope this would help you to know what test automation engineer is like. But I think the number of this role will decrease because there has been some companies that provide test automation tools for non-programmers. I couldn’t imagine that at that moment. I might be lucky to experience this role.