There is a need to work as members of the team and to engage with others within the team, regardless of titles. If you see a task that needs doing and you have the skills to do that task, then just do it.
Agile processes mean testers are part of the delivery team and should try to be involved from the beginning of the project. Testers should have the ability to “switch hats” and be involved to support and assist the team.
The following are only a few examples of the vast number of roles you could be taking on.
Test Architect
One huge benefit of small slices of work, such as a story taking a few days to complete, is that design meetings happen all the time and can be a lot easier to get invited to. Testers can contribute to these meetings, asking “What if . . .” types of questions, such as “What if a user did this?” or “What if the server we call with the web services does not respond?”
During the design discussions, try to create a model of what you think the system will look like. If you find yourself being confused about the information being presented or you feel something does not seem right, this is the moment to ask questions to clarify. The answers you get could be useful for noting areas to explore at a later date. Offer suggestions about how it would be easier to test if development were completed in a certain way, and look for ways to make the system design testable.
If there are uncertain areas about how a feature could or will be implemented, this would be a great area for you to explore after development. Make a note and maybe create a test charter in your test plan, perhaps using a mind map.
Consider from the information provided what could require checking and make a note of possible automation tasks. You may find yourself contributing to what checks are automated as acceptance or unit tests.
Test Automator
Automating checks does not have to be your job; it might be something you do part time, as needed. You don’t always need to write code or be a skilled programmer to do automation. Many tools exist that simplify the process. Knowing how to write code might be a useful skill if you feel it will benefit the team. If you do not have an interest in learning to code, it would be a good idea to at least try to learn to read code.
Some of the frameworks used extensively for test automation use English words and phrases, such as the Cucumber, Gherkin, and FitNesse frameworks.
They follow similar approaches for creating automated checks. First, create scenarios in a very high-level language that loops a bit like English; then run a parser over the scenario to automatically create “stub” functions; finally, fill in the functions with actual code.
For Cucumber, step definitions can be written in many different programming languages, and the level required to write these types of definitions is not too intense.
For more information on learning to code from a testing perspective, I recommend the excellent book Java For Testers by Alan Richardson.
Comments
Post a Comment