Complexity is a direct indicator of software quality and costs: if the complexity for any code is high, the quality of that code will be lower and it will cost more to manage it. Complexity measurements can be used to estimate development and test activities and to decide where refactoring is needed to improve quality and prevent problems.
Testability must be explicitly designed in the system said Peter Zimmerer from Siemens AG. Test architects should drive testability and collaborate with architects, designers and testers in using good design and engineering practices. At the QA&Test 2014 conference Peter gave a tutorial about design for testability for embedded software systems.
Creating and maintaining a Quality Management System (QMS) can be difficult, certainly when organizations have multiple product lines where different regulations and standards are applicable. InfoQ interviewed Willem van den Biggelaar about the benefits of having a QMS, dealing with multiple regulations, assuring adherence, how a QMS can support agility and deploying a QMS in an agile way.
The 2014 CAST Research on Application Software Health (CRASH) report states that enterprise software built using a mixture of agile and waterfall methods will result in more robust and secure applications than those built using either agile or waterfall methods alone. InfoQ interviewed Bill Curtis about structural quality factors, and mixing agile and waterfall methods.
Agile software development teams have to assure that the products that they develop have sufficient quality. Management often also expect that they increase their velocity to be able to deliver more functionality faster to their customer. Several authors explored the relationship between quality and velocity and suggested ways to improve both quality and velocity.
Long working days, deadlines and team pressure can impact the quality of the software that agile teams deliver. What can we do to prevent that from happening and enable teams to improve the quality of their software? Some suggestions are to arrange for scope and deadline slack, adopt pull systems, and to make sure that people can slow down and get enough sleep.
Developing and delivering products which customers don’t want and for which there is no market can be costly. Agile can help you to efficiently develop products, but you need to know what to build. How can you find out which products your customers need?
Brannon B. King, a software developer working for Autonomous Solutions Inc., has published an article entitled Dangers of Violating SOLID Principles in C# in MSDN Magazine, May 2014. The author outlines some of the mistakes developers can make in their C# code, breaking the SOLID principles and leading to code that is more difficult to extend or maintain.
A report on why agile development races ahead of traditional testing, reasons and new agile testing trends.
Software debt exists in different ways. Technical debt is widely known, some other forms are competence debt and quality debt. Software debt can cause product maintenance costs to increase and can depress developers. Several solutions exist to manage software debt.
Experimentation using for instance lean startup can help you learn about your customers and find out which features and product would be valuable. The value however comes from building products and actually delivering them to customers. You need to find ways to balance between experimentation and delivery.
At the recent Testing Portugal 2013 conference Klaus Olsen presented on the Bug Hunting technique, a style of Exploratory Testing.
Organizations learn through their employees. To enable adoption of agile ways of working, organization have to support the personal development of their employees.
An exploration of recent advice from Henrik Knibert, Ward Cunningham and Hayim Makabee on technical debt, how to make the most of it and when to pay it off.
“Many team and their product owners believe that the team's unique job is to deliver more and more story points, but we consider this to be a complete misunderstanding of the relation between the team and the product owner” said Damien Thouvenin and Pierrick Revol. They ran a sprint planning game on investing time to produce stories, investigate issues, reduce technical debt, or do training.