You are a good developer, and you understand that your quality assurance team wants to help you find issues in the code. Help your friend out by doing a few simple things.
Involve QA early.
Your QA have experience understanding how systems behave and misbehave. They also have the skills to make the applications break. Use these skills and ask them to review designs before much coding work is done. I guarantee you they will be receptive, and you will get some valuable feedback on the code. The earlier you catch an issue, the easier it will be to resolve.
Be there to answer questions.
Your QA has one primary responsibility, to make sure the program does what it's supposed to do. Sounds simple, but how can the QA know the expected behavior? In a perfect world, there will be specifications, but maybe those aren't quite complete. Be available to answer their questions, even be proactive and help them out by stepping through the application with them once. This will answer the majority of the questions they have, speed up the release process, and help you each understand assumptions in the program.
Write down assumptions.
You can also help your QA by writing down those assumptions you made during the coding. Maybe you decided on some pattern because you think it will save time in the future. Maybe you exposed a value in a configuration. It's all good, your QA should value your opinion, but please write those down. It'll help save time in the long run.
Tactical things to do.
There are lots of little actions you can take to make your QA's life easier.
- For your SDETs using Selenium or similar, include a unique identifier on your html actionable elements. Put on your button, on each input box, on the container for your list, on the navigation section. This allows web automation to be written more quickly and clearer.
- For your SDETs using Selenium or similar, avoid animations if possible. You can ask them about their different strategies for waiting for an element if you want to know why.
- For your database testers, help them with sample data for testing, or at least the domain knowledge you have when generating your data.
- For your API testers, provide some way to browse the API and structures; add Swagger, Apiary, or other api generation tool
- Share the code. Black box testing is silly.
- Visualize it. Draw some circles and arrows on the whiteboard, describe the flow of data.
These tips will help you speed up the QA process, and get better results. Everybody wants to write good code that gets the job done. Your QA will appreciate the time you've taken.
This is my first post. Thanks you for reading. If you noticed any error, omissions, tone problems, good ideas, etc. please let me know. I want these posts to be useful. Any help is appreciated.
Top comments (0)