TDD is a software development approach in which a test is written before writing the code. When TDD is properly set up, it can bring numerous advantages and become a cost-saver, providing true value to the business. When TDD is not properly set up or without understanding how it should be used, it can be a waste of time and money. Quality comes not from inspection but from the improvement of the production process
One of my mentors, whom I admire, once told me, "Quality is not only QA's responsibility; everyone- from development engineers to technical architects, to product managers need to share the responsibilities. In a QA role, if you want to be successful, you have to know the right amount of information from everyone and always ask questions." I took my mentor's advice very seriously.
Risk-based testing is an approach to testing that helps us handle our limited resources. It’s also a valid model for years to come because it focuses testing resources where they can have the most impact—regardless of whether limitations are due to budget, tight schedules, or even the uncertainty of an unexpected situation like COVID-19. Here are some practical tips, examples, and steps you can use to adopt risk-based testing.
After finding and reporting a bug, a tester may get this response from a developer: "Please rerun the test on the latest version of the code and check if the bug still reproduces." This seems like a rational request; just as a change can cause a bug to appear, it can also fix a bug. But is following up the responsibility of the tester or the developer? And if the bug is no longer there, how do you classify and close it?
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.
Greg Paskal, evangelist in testing sciences and lead author for RealWorldTestAutomation.com, chats with TechWell community manager Owen Gotimer about testing as a craft, choosing the right test automation tools, and current testing trends around the world.
Shachar Schiff, founder and principal consultant at BadTesting, chats with TechWell community manager Owen Gotimer about the recent rebrand of BadTesting, the four archetypes he uses to help customers, and the universal importance of communication.
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.
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.
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.