While some testers are unfamiliar with test execution automation, the growing trend into automation necessitates new skills for manual testers. Project test teams need to become aware of this trend, as automation represents not only business opportunities, but also increased quality and fewer risks in complex, safety-critical, and mission-dependent projects.
Pulling data from a source system and putting it into a data warehouse is a process commonly known as extract, transform, and load, or ETL. Testing the process can be a chore—you need to be sure all appropriate data is extracted, that it is transformed correctly to match the data warehouse schema, and that it's all imported. Instead of testing the ETL process as a black box, you can pull it apart, testing each piece in isolation.
In 2015, it was discovered that Volkswagen had equipped millions of its cars with software to cheat on diesel emissions tests. It was a team of independent testers that uncovered the fraud. Jon Hagar tells testers what they can take away from the scandal and gives some recommendations to consider in order to improve the test industry for IoT and embedded systems.
In the movie RoboCop, the cyborg law enforcement officer advised people to “Stay out of trouble.” This article focuses on ways to stay out of trouble when building a software product by following the stages of software testing, using the 1987 movie’s titular character as an example. Let’s examine each testing stage and see if we can build a better RoboCop.
Take a look at the critical systems in the world today and you’ll find software. From water, power, and utilities to nuclear plants, factories, and cars, pretty much everything has become integrated with digital devices and the internet. We need to do testing from a risk-based perspective and be accountable to the public by acknowledging what is tested and what is not.
With service virtualization (SV), technology stands in for the manual efforts of testers or the simulators companies used to write. SV solutions aren’t simple bits of code that stand in for manual testing processes. They’re surprisingly powerful software tools that are self-learning. Jon Spencer explains how they work.
Payson Hall learned some lessons from optimizing data system performance that could relate to human team management and leadership. For instance, if a system is overworked, it can't be any more productive beyond a certain point; the same is true for people. Both also can get more done by minimizing multitasking and prioritizing jobs. Read on to learn more from machines.
Robbie Bridgewater writes on the difficulty in finding bugs during testing since no single computer can run all of the major browsers—not to mention the added challenge of testing various mobile operating systems. In this article, Robbie compares four possible solutions to this dilemma.
There are two distinct roles in many software projects that are involved with testing: developers and testers. Should they take the same approach to testing, or are there some principles that apply to only one of the roles? What should they do to coordinate their work? Danny Faught went through an exercise to compare and contrast and found that the questions he couldn't answer were as interesting as the questions he could answers.