|
A Better Way of Reporting Performance Test Results Reporting the results of functional tests is relatively simple because these tests have a clear pass or fail outcome. Reporting the results of performance testing is much more nuanced, and there are many ways of displaying these values—but Michael Stahl felt none of these ways was particularly effective. He proposes a reporting method that makes performance test results easy to read at a glance.
|
|
|
Testing a Software Rewrite Suppose we’re looking at a system rewrite where the stakeholders have none of the original engineering documentation. (This isn't surprising; documentation becomes obsolete—or even misleading—as the system changes, and corresponding docs don't get updated.) What can we do? Here are some tactics to use—and risks to anticipate—when testing a system rewrite.
|
|
|
Keeping Accessibility in Mind: Cognition, Memory, and Attention Digital accessibility refers to assistive technologies as well as to accessibility of web and mobile applications and electronic documents. But there are crucial aspects to accessibility beyond syntactical correctness of the HTML code and supporting a range of browsers and devices. Software testers must have knowledge of accessibility patterns and use a variety of tools to understand the experiences of people with disabilities.
|
|
|
Using Equivalence Partitioning and Boundary Value Analysis in Black Box Testing Equivalence partitioning and boundary value analysis are two specification-based techniques that are useful in black box testing. This article defines each of these techniques and describes, with examples, how you can use them together to create better test cases. You can save time and reduce the number of test cases required to effectively test inputs, outputs, and values.
|
|
|
Getting Your New Web Test Automation Up and Running So you have the responsibility of a new team and getting an entirely new web automation test infrastructure up and running. Here are the hurdles, pitfalls, and successes one QA director encountered, along with the milestones the team defined to measure success, how they migrated their existing manual tests, and the path they took to establish the new web test automation initiative.
|
|
|
Teaching Acceptance Test-Driven Development Acceptance test-driven development is a whole-delivery cycle method that allows the entire team to define system behavior in specific terms before coding begins. These conversations align the expectations of the testers, developers, and product owners, forcing any silly arguments to happen before someone has to create the code twice. Here are some great beginner exercises for teaching ATDD.
|
|
|
Fault Injection Testing for an IoT Device If someone says a feature is not testable through the methods we use, it does not absolve us from the responsibility of testing; that's still our job. When this team was given a new connected device to test, they realized their existing functional testing skills wouldn't be sufficient to test the product's core algorithm. So the team got creative, learning the source code and introducing fault injection, figuring out new ways to test.
|
|
|
Shifting Testing Left Is a Team Effort There is a lot of talk in the testing world about shifting left. Basically, “shift left” refers to moving the test process to an earlier point in the development process, independent of the development approach. This article explores a case in which shift-left has been applied, and the lesson is that shifting left cannot be achieved by testers alone—it must result from a team effort.
|
|
|
Testing to the Usability Standards Our Customers Expect Allowing minor defects to be included in releases impacts our customers’ perspective on software professionalism. We’ll never catch every weird, obscure bug, but there are some design elements where they tend to lurk. By focusing our testing efforts on these areas—or at least not neglecting them—we can catch more issues before our customers do.
|
|
|
Lessons Learned in Testing CRM Software CRM systems manage a company’s business relationships, including customers’ data, information, and interactions, so there’s a lot that can—and should—be tested. Viktar Sachuk talks about his experience in testing CRMs to provide some tips for dealing with the trickiest parts of CRM testing, specifically focusing on some preparatory measures, functional testing, integration testing, and test automation.
|
|