I actually recall the days when QA testers were cured almost as second-class people and developers ruled the software world. But since it recently occurred to me: we've testers now.
Much of this is driven by the shift-left strategy of testing as early as possible in the development process. This kind of helps your teams give attention to quality from day one of your project, alternatively than looking forward to defects to be uncovered late in the software development lifecycle.
With more and more companies making the move left in their development process, testing shall no longer be just QA activities--which means that the roles of developers and testers are starting to blur. Transformation is challenging, but there are some things your team can do to prepare for this change that can help for a much smoother transition.
Listed below are some of the steps that are helpful for shifting to the left:
1. Generate developers accountable for testing
With the current trends in software development practices, as well as the switch in focus towards customer-driven development models, test software is more important than ever before. Agile and DevOps require more automation, and conditions like continuous integration and delivery require automated testing that could be run quickly and reliably.
I would go so far to express that one couldn't be successful of these practices without a point of test software set up. In my experience, teams often have more developers than testers, where the developers need to take responsibility for at least some of the team's test automation attempts.
If testers are the only ones accountable for creating an automation framework and writing tests, it's heading to slow down your development process. Distributing assessment to developers helps facilitate your time and effort.
One way to induce your developers to begin creating tests--bridging the distance between developers and fewer technical testers--is to use behavior-driven development practices that help split the assessment into layers.
2. Code review quality checks
What I've seen happen at large corporations is that there's typically a test automation business lead beyond the sprint clubs involved with all the test automation code reviews. This kind of individual helps slowly move the teams with best practices for automation and testing.
Developers sprint teams submit their tests for code review. The key reviewer, a tester, can then be sure that the checks are accurate and that there are no other scenarios the developers could have missed that should also be examined.
It's rare to have testers who also own the skill sets to create recylable, maintainable code, so I recommend that your designers build out your software framework rather than your testers. Testers should be dedicated to finding bugs, not spending all their time creating a framework when you have software builders who are more proficient at programming.
3. Teach testers to code
While developers require on some testing responsibilities, testers also need to do some coding. In order to be effective at code reviews and as part of a race team, testers need to learn how to code.
I'm not naive enough to suggest that everyone on a sprint team be able to fill each role on the team completely, but testers need to be technically skillful enough to be able to read and change code at some level
4. Use the same tools
For anyone who is a specialist, one of the issues you might have experienced in past times is the inability to create automated tests using the same tools as your developers.
It was always a roadblock for testers creating automation frameworks from scratch using these tools, since it made it difficult to apply certain common, object-oriented design rules and discouraged developers from collaborating with testers on the automation code.
The good news is that it's now becoming more common for popular test tool vendors to back up coding languages such as Java and C#. If you're just beginning your test software efforts, you should use tools that fit into your developers' ecosystem.
5. Start with testability at heart
Regardless of your role on the team, development testing (and eventually delivering a feature) requires a total team efforts. software Testing shouldn't be an activity that is done only at the ending of a sprint with a designated tester.
Prior to single line of code is written for a new feature, the programmers should be planning their solution with automation in mind.
Only when an application is built with automation testing in brain from the beginning will a team be truly successful as they move left. Following these five steps should help get you there.
No comments:
Post a Comment