The start of a new year gives us the opportunity to look at what we can improve. It’s the perfect opportunity for setting new goals or adjusting current ones. Let’s take a look at a few goals we can set for those of us in Quality Assurance.
Test more, write less
Test cases, plans, checklists, bug reports are all integral parts of Quality Assurance. They give proof of testing, information for bugs, and roadmaps for improving a company’s own QA processes. Documentation can give teams a better view of what testers are doing. What are we testing? We can look at the test cases or test plan.
Though writing such documentation is important, it can steal time away from actual testing. A lot of teams tend to rely on the existence of test cases more than test execution. It’s important to remember that documentation can’t find bugs; they can only show proof of them.
Teams can balance out the amount of time that’s spent between testing and writing documentation. However, documentation shouldn’t be the only factor in determining appropriate test coverage.
Dedicate extra time to explore
Exploratory testing gives testers the freedom to increase that test coverage and isn’t tied to the specific steps of a case. Testers can miss bugs when they focus strictly on existing test cases. Exploratory testing reaches into those areas that test cases can miss.
Focus on the “right” automation
Just as documentation isn’t an accurate gauge for test coverage, hundreds of automated tests don’t always mean your application is stable and healthy. The push for more automation in projects misses the importance of planning. It’s simple to write an automated test as it saves time and money and gives the team more time to focus on testing new features. Yet, it also takes time and money to support an automated test suite.
If a team wanted to “create more automated tests” then they would likely end up spending more time in maintaining tests than writing new, valuable ones.
Use the right test framework for projects
What does “the right” automation look like? A good place to start is choosing the appropriate test framework for a project. For UI tests, QA engineers have the luxury of choosing any framework they want regardless of the technologies used for developing the application. They are not dependent on a project’s own languages and libraries. However, there are frameworks that are a better fit for a project and it’s necessary to consider that.
Some testing tools may be easier to pick up for testers new to automation. A QA team with little development experience may choose to pick a framework that requires very little configuration. Capybara requires little setup and has a well-documented API, making it easier for teams to start writing automated tests quickly. A more experienced team may choose to use WebdriverIO: a utility that allows greater flexibility, but requires more configuration up front.
There’s always room for improvement, and these are just a few goals for helping a team grow and enhance the quality of an application. Have you established some resolutions for your QA team?
