Test plans are essential for communicating intent and requirements for testing efforts, but excessive documentation creates confusion—or just goes unread. Try the 5W2H method. The name comes from the seven questions you ask: why, what, where, when, who, how, and how much. That's all you need to provide valuable feedback and develop a sufficient plan of action.
The more you rely on feedback from your automated tests, the more you need to be able to rely on the quality and defect-detection power of these tests. Unfortunately, instead of being the stable and reliable guardians of application quality they should be, automated tests regularly are a source of deceit, frustration, and confusion. Here's how you can start trusting your automated tests again.
If you have a spotty test automation strategy, you may get lots of regression issues every time you have a new release for your mobile app. A mobile device lab to run regular regression tests could be the key. Here's a plan to get a mobile automation lab up and running, as well as some practices that can help reduce the number of regression issues and improve your overall app test strategy.
If you are unsure about the things you should be doing to control technical debt in your existing performance test suites, here are a few questions that should be considered. Asking yourself these questions regularly will go a long way toward keeping your tests fit and sustainable and helping control a few common factors that lead to technical debt in performance tests.
It's easy to see that style consistency is important when discussing the user interface. But there are other areas where being consistent is just as important, even though they are not as visible. Consistency is one of the quality attributes of a product—any product—even if it is not stated clearly in the requirements documents, and testers have a responsibility to check for it.
Many people equate 100 percent unit test coverage with high code quality, but that is not enough. Code coverage tools only measure whether the tests execute the code; they make no judgment on the effectiveness of the tests. Testers should review unit tests, even if they have high coverage levels, and either help improve the tests or supplement them with extra tests where necessary.
Automated testing of an application with many dependent services can be challenging. Achieving continuous deployment across these services can be even more so. Managing, coordinating, and scaling deployments of services can become overwhelming and error prone over time.
Do you want to know how real users are interacting with your product? Do you want to know which features they don’t use? Would you like to understand how your product works internally under real operational conditions? Then you need telemetry—the instrumentation of your product to record...
Are you a new, aspiring, or experienced manager tasked with building a team of stars? Do you manage a team that needs to be motivated or re-energized? Join Tanya Kravtsov as she shares stories, tips, and tricks on hiring, on-boarding, and managing test engineers and turning your group...
Test coverage is a strategy to help us spend scarce testing time on the right priorities. When things were tested last, how much automation coverage we have, how often the customers use the feature, and how critical the feature is to application are all factors to consider. Here are some ideas for keeping quality high when you're transitioning to continuous delivery.