The earlier you find out about problems in your code, the less impact they have and the less it costs to remediate them. Therefore, it's helpful to move testing activities earlier in the software development lifecycle—shifting it left in the process timeline. This article explores the shift-left methodology and how you can approach shifting left in your organization.
“Shift left” is one of the latest buzz terms in software testing. Movements like agile and DevOps recommend that testers shift left, but what does that mean, exactly? Here's how one tester became a believer in the shift-left movement; how he got his team's developers, analysts, designers, and managers on board; and how his entire organization has benefited from the shift.
Many teams have existing automated test suites that are not included in a continuous integration program. Maybe the tests take too long to execute, or they are not reliable enough to give accurate results. Here’s how to assess your test suites in terms of value added and time to execute, along with five proven strategies to optimize those suites for CI.
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.
Risk-based testing is essential to focus our testing, but it is not always easy to apply to our projects. Risk management tends to focus more on project and process risks (i.e., Will we make the deadline? Do we follow our processes?) and less on the product risks that can act as a foundation for a risk-based approach to test. Including this aspect of risk in your test coverage will give you a solid foundation for defining a test strategy that implements and executes the right tests with the right intensity to mitigate the most critical product risks. In this presentation, Gitte Ottosen walks you through approaches to lightweight product risk analysis that can be applied whether you are working in a traditional or agile context. The approaches focus on the conversation around identifying and classifying product risks as a team effort, as well as how to use product risk analysis to support test specification and execution.
The internet of things (IoT) continues to proliferate as connected smart devices become critical for individuals and businesses. Even with test automation, performing comprehensive testing can be quite a challenge.
You may feel you don't have time to write unit tests, but you really don't have time not to. Steve Poling makes the case that writing tests first not only will yield better code, but will help you get that code working right sooner. Here's how using a test-first approach changes your thinking about coding, lets you see mistakes immediately, and helps you create more testable code.
Today’s IT systems communicate with customers through multiple points of engagement and various interfaces, ranging from web, mobile, and voice to BOTs and apps like Alexa and Siri. Sanil Pillai says these systems need to provide seamless handoffs between different points of interaction—while at the same time providing relevant and contextual information quickly. To accomplish this, a team must be able to successfully pair device hardware capabilities and intelligent software technologies such as location intelligence, biometric sensing, and Bluetooth. Testing these systems and interfaces is becoming an increasingly more complex task, and traditional testing and automation processes simply don’t apply to new-generation digital interaction services. Join Sanil as he discusses the testing and automation challenges in new-generation digital interactions using hyperconnected BOTs.