From the 13th of September I will be starting at ICTU as a QA test automation engineer, which will be my first contract as a freelancer and is expected to last for 1 to 1.5 years. ICTU was looking for a software developer, not specifically a test automation engineer. And hence, the experience I have acquired next to my normal software development tasks was enough. And as most of my colleagues will tell you: If I put on my functional tester hat on, I am a kick-ass functional tester, that will fill up the backlog with bug’s 🙂
From the moment I began my career in software development, I have been fascinated by TDD and BDD and tried to apply it in my daily work. Specification by example is something that I highly value as a software developer. When writing user stories/features, I always try to give examples of how it should work. In my opinion, this adds immense value when implementing a feature. It reduces the chance of miscommunication, radio-effect and ambiguity of naturel language.
I already had some experience with Gherkin, cucumber and several other BDD/automated testing frameworks, but it was always a “side-activity” to add these tests, mainly because the focus was on unit testing. Often we did not even have enough time to unit test it all, adding functional automated tests was a step further and a luxury that was not yet within reach.
I often applied the 80/20 principle, to write automated functional test cases for 20% of the processes and features, which are used 80% of the time. The so-called “high-exposure” and “high-usage” flows and processes. This way, we added value where it mattered, while being efficient with our time.
Most of the challenges in my new role will be to (statically) analyze/reverse engineer the current implementation to see what has been built and whether it matches the functional requirements while adding automated tests on the component, integration and API level.
I am very excited to start as a QA test automation engineer. I believe that every software developer should be working as a QA test automation engineer somewhere in their life. It broadens the horizon about what quality means, how it is measured and how to interpret user stories and acceptance criteria. For me, this is a new challenge and a new opportunity to become a more complete software developer. Additionally, it makes me complete as a professional by bringing tech and business closer together. In the end, tech only adds value if it does what it is supposed to do according to business 🙂
The coming months I will be posting mainly about automated testing. This can be a list of books that I have found and would like to read, a summary/comment on a book I have read or some other topic that will be on the edge of BDD, SpecFlow and QA test automation from a software developer’s perspective.
Subscribe to my newsletter to stay tuned! 🙂