The advantages of shifting left and testing as early as possible are obvious. But as you automate more testing, the test suite grows larger and larger, and it takes longer and longer to run. Instead, just automate the process of finding the right set of tests to run. The key to that is machine learning. This isn't AI bots finding bugs autonomously without creating tests; this is a different way to use machine learning, and it’s far simpler.
Continuous operation tests find important bugs, partly as a result of their long operation and partly by increasing the probability of finding statistical bugs. However, CO tests have their own downsides. Mandating a periodic reset or reboot can work around these issues, as well as save time and cost for testing, reproduction, debugging, and fix verification.
Shifting your testing either left or right can meet different needs and improve different aspects. How do you know whether to make a change? Let your test cycles be your guide. Just like when driving a car with a manual transmission, if the engine starts to whine or you’re afraid you’re about to stall out, switching gears may be just what you need.
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.
QA testers often take on more of a role than just testing software code. When the team needs help, QA should lend a hand in assisting with business analysis, customer communication, user experience, and user advocacy.
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.
Because enterprise applications are highly interconnected, development in stages puts a strain on the implementation and execution of automated testing. Service virtualization can be introduced to validate work in progress while reducing the dependencies on components and third-party technologies still under development.
In this interview, Melissa Tondi, senior QA strategist at Rainforest, discusses the foundation you need in order to have a positive introduction for new tools and technologies. She explains why the team leader has to understand what motivates each individual and how to get them excited about their job. Melissa says team members also have to realize that if they are in any way involved in testing software, they are a technologist, so they have to embrace the tools and technology that will continuously improve and streamline repetitive tasks.
In this interview, Bob Galen, principal agile coach at Vaco Agile, talks about the importance of getting rid of silos by breaking down the barriers of “them and us” and becoming “we.” He also discusses the need for agile managers to steer away from a tactical management view toward a more strategic leadership view. That means leading their teams by setting expectations and guidelines and being available to help if needed, but ultimately just trusting their teams to get the job done.
Technologist and evangelist Peter Varhol and Gerie Owens, a test architect and certified ScrumMaster, discuss their STARWEST presentation, “What Aircrews Can Teach Testers about Testing.” They talk about how testers can apply airline safety practices to their teams’ delivery of high-quality applications through complementary expertise, collaboration, and decision-making. They also explain how blind deference to authority and automation can be detrimental to a testing team, and how to use everyone’s skills to achieve success.
Rob Sabourin, the program chair for STARWEST 2018, discusses the selection process for conference speakers, his favorite aspect of the conference, and the interactive Test Lab. He also details his “Testing in the Dark” talk, which gives strategies to use when you’re required to test software without any requirements, design, or product knowledge.
Are you a leader with a quality problem? Every organization struggles with quality at some point in their product lifecycle. Knowing what to measure and how to build a culture of quality with specific and actionable methods is key.
We are often reminded by those experienced in writing test automation that code is code. The sentiment being conveyed is that test code should be written with the same care and rigor that production code is written with.