What skills a team needs to succeed with automation in testing
Original Post: share-what-skills-a-team-needs-to-succeed-with-automation-in-testingDear reader,
With regards to success in automation, teams succeed when each of the players knows their role. As it pertains to QA Engineers, there are definite skills that help, as listed below:
Technical Skills
- Fundamental Knowledge in the SDLC - knowing what it takes to plan, develop and deploy. Also knowing the concepts of TDD vs BDD.
- Requirements Gathering - while not necessarily technical, there are some technical aspects in terms of understanding the best script language to choose and why, how to work with the CI, and so on.
- Programming Language - as has been stated, familiarity of a computer language is key. It also helps to work in the language of the developers so as to become part of the build process.
- Knowing the basic differences between Unit and Integration tests, as well as Front-End vs Back-End testing.
- Page Object Modeling
- Object-Oriented Programming
- Continuous Integration - understanding how to deploy to a CI and maintain the scripts as the project grows.
- GIT - I can't stress this enough that all QA Engineers need to have even the most basic of knowledge of the GIT workflow.
I can honestly tell you a lot of team success also relies on the inter-personal dynamics and non-technical aspects; the intangibles that make or break team unity:
Non-Technical Skills
- Be Adaptable - as a QA Engineer, it is paramount that you are adaptable and willing to work outside of your comfort zone. Sure you know Python, but does that help the Devs if everyone is working in JS? Also, there must be the willingness to learn a new framework if the one you have experience with doesn't work for your current project.
- Be A Leader / Mentor - as a subject-matter expert, you must be willing to flex your "coach" muscles and pass on what you have learned. Its good that the junior members of the team can write page objects, but its on you to be able to coach them on why IDs are better than XPATH or how to better compose a test case.
A good leader motivates the rest of the team and raise any flags that impede success.
A good leader can also advocate for automation if it doesn't exist, and can evangelize a particular framework or script language if the current one is not working. It takes the right manner of communication and tenacity to express your beliefs and what you honestly feel will work for the team. Have proof of concept if necessary. - Be Creative - as someone who was tasked to work with proprietary test framework last year, an application that required knowing JASMINE (_something I've never been exposed to_) it took a minute to gain a foothold. When I did, I found myself working with the team Automation Engineer who built the framework to create the kind of tests that were versatile and resilient to change. The end result was a fluid test harness that was tremendously advantageous as the project grew in size.
The lesson learned: creativity goes a long way when it comes to writing the kind of tests you want in a way to make it easier to maintain.
Example: if you know you have many tests relying on test data, find a way to map the test to a data-source and structure your test in a way that uses variables rather than hardcoded data. Simple, right?! But now imagine this is on a platform you've never seen before. What are you to do? - Be Positive - the hardest part of automation is the loop of **write test -> run -> fix** especially as project requirements change. It can be frustrating when the environment goes down causing you setbacks, or when page structure is updated and tests that once were passing are now failing.
Overall, there are 1,000 different things that can impede your progress. But what you cannot do is get negative about it. The challenge is to persevere when things are tough. This is key in a team situation when your progress is contingent on the success of others. - Be Passionate - As the saying goes, _a chain is only as strong as its weakest link_; everyone on the project has their part to play. You may be called upon to test manually or give a demo on work performed. Whatever the case, be committed to the craft. Give 100% in everything you do.
No comments:
Post a Comment