Skills of a QA Engineer
I’m currently a QA Engineer at ASOS. As a tester, I believe it is important to have a good technical ability in order to provide feedback to developers on concepts such as testability and code coverage. I want to discuss the ability of a tester to retain their value while also contributing on a technical level.
The inspiration to write this blog post came from what James Bach describes as ‘critical distance – how much difference there is between perspectives or ways of thinking...’. He goes on to state how ‘social distance’ could be one mechanism for achieving critical distance. An example of this could be how QA teams are structured in some organisations as separate entities and test in a black box way. For further information, watch James Bach explain when he came to speak at ASOS.
My journey over the past six months
The lack of knowledge I had in C# and .Net led me to take the evening course ‘Net Core, Web Applications for the Cloud’ at City University. This involved a lot of practical applications of MVC and .Net Entity Framework, that I have now been able to apply in our most recent project. Also on the back of this, I challenged myself to take the Microsoft certification, ‘Programming in C#’ (may be outdated and lacked real life application). Completing these gave me the confidence to offer advice to colleagues during group programming sessions and suggest improvements in code reviews. However, as a consequence, this meant I had reduced my critical distance of the current project being developed.
Other areas which have altered my perspective and have swayed me towards a developer mindset are the following:
- Testability — often a conversation we have in refinement related to test data or opening an API endpoint to be available for testing. On occasion, I have questioned testability at code review stage on unit tests. Testing a class or method may involve re-writing production code by adding an interface to a class in order to enable mocking or using visible internals, e.g. ‘internalsvisibleto’, to prevent untestable logic. This level of contribution to unit testing, where deep knowledge of the code base is required, could be said to bias my testing method because I have a deeper understanding of the code in question.
- Code coverage — I wanted to understand the intricacies around achieving a good level of coverage and challenging the ‘this code isn’t easy to test here’ or ‘this class can’t be easily mocked’, so I started writing unit tests focusing on the gaps. This then allowed me to interact with developers on the unit test level, improving my relationship by questioning and offering advice.
Conclusions
I have reduced my ‘social distance’ by improving my coding skills to communicate on a level with developers, whilst at the same time compromising my ‘critical distance’ to some degree.
Though, it could be said, as we operate as a cross-functional team, that the responsibility falls on other members of the team as well. The value of exploratory testing will always be prevalent on the integration environment and using ‘tours’ (a way of testing where you take a tour through the application on a themed path) helps to counteract any bias I may have when testing.
Operating in agile means we always aim to automate where possible and ‘shift left’ in testing processes, therefore the required critical distance between myself and developers thinking does reduce in this environment. Although, we have processes in place to mitigate similar risks, provided by the release QA team (they focus on testing the site’s core user journeys) and remain critically distant and cover business critical journeys.
