You have to assess the risks and the benefits of every decision you make in software testing and quality assurance. In this article, Sandra Parker explains how to minimize the risks of outsourcing your software QA activities.
Continuous testing, continuous delivery, DevOps – these are all terms very popular in the last couple of years, and they all involve a shift in the way we deliver products, software testing included! So who is responsible for the quality assurance nowadays?
There are many books about software testing, but Quality Code is among the best that I have read. It presents a philosophy about software testing that has been mine in my previous life as a software developer: the programmer is the main person responsible for the quality of its code.
When the software quality assurance people and the software developers are member of two different teams, bug discovery and reporting could often be a source of conflict caused by misunderstanding. This article explains how the quality of a bug report’s attachments can help to improve the communication between software testers and developers.
After having worked as a software tester, an agile coach and a programmer, I have seen and experienced software development from different perspectives. One of the things that has stuck with me the most is how limited our view of software quality is. While we struggle with our unit tests or test cases, we are missing out on some fundamental factors which affect software quality.
Software testing metrics can be very difficult: there are thousands of them out there, it is hard to know which ones are important, many are hard to collect, its often difficult to extract meaning from the metrics, and everyone has an opinion on the usefulness of any metric that you might choose. So, what is one person to do?
Software quality or the quality of software is a topic that generates many debates within the software development community. Is it about user satisfaction? Does it deliver value to the organization? Do we consider the quality of the code or its capability to change in the future, maybe with some automated tests to make sure nothing breaks? How good is “good enough”? In his book “What Drives Quality” Ben Linders tries to provide an overview of the quality perspectives during the software development life cycle.
Copyright © 2009-2023 Software Testing Magazine by Martinig & Associates