Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
Recently, Tom Grant from Forrester has written about technical debt and its relevance to Product Management. He made some good points, so that it is with me today to add a few thoughts about quality.
His article → For ISVs, Technical Debt Is A Serious Business Issue basically states that it is important to keep an eye on software quality. Today I will be writing about the possibilities, which we have at hand, to do so.
Often Product Managers think that they are fine, when they take care of customer needs. Below you find Grants’s most prominent comment, why this is not the case.
To understand, why Product Management has its stake in software quality, think about the pressure, which you normally receive from your stakeholders that want you to develop features and functions. Do you pass it on?
The more you develop, heedless of the technical debt you create, the harder and harder it becomes to make further changes. While this may seem like an obvious conclusion, it’s not one that has the impact on software development that it should. In their rush into the future, building code that is supposed to expand choices, many teams are actually constraining their choices.
To avoid the accumulation of technical debt (that is the sum of small defects and bugs in the coding, which you deliver to customers), you first have to understand that technical debt is a problem, as it prevents you step by step to deliver functions and features (see Grant’s comment from above). Once this is clear, you can think about the strategies to avoid technical debt.
Well, the basic strategy to avoid technical debt is simple. It happens by means of software testing, and the development according to quality standards. As you see in the following article, we have several methods at hand to test software, or to design it in a way that the technical debt is minimized by design: → Wikipedia – Software Testing.
Ok, at current you might have the following formular in your head: Testing = Software Development Product Management. Below you find an argument taken from Wikipedia, why this formular is not entirely correct – There is testing needed on requirements level (though the majority of the tests is done in the development):
Software testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed. As such, the methodology of the test is governed by the software development methodology adopted.
This comment probably leaves you with the questions: Where to learn, and how to start with Quality Engineering practices. In the following sections I will recommend you further reading.
One influencial body in the area of software testing is the „International Software Testing Qualification Board (ISTQB)“. This community deals with software testing methods, and the required knowledge. You find more information if you follow the following link:→ International Software Testing Qualification Board.
One thought leader in the software-testing-space is named Brian Marick. In his blog you can find a lot of useful information about his work. Most importantly, Marick has also brought the quality view into the Agile Development methodologies. For more information, visit his blog at → Testing Foundations.
Once you know it generally, the next question is „how do I start testing, and which is my role?“. To answer this question, it is helpful to think about the different dimensions, which you target with your software, and which you need to cover with tests. Here, Marick has published a helpful tool, which he calls the Agile Testing Matrix→ My Agile testing project.
In his matrix, he basically distinguishes tests, which are business facing from tests that are technology facing. Then he distinguishes tests, which either support programming or, which are critique the product.
If you fill this matrix with the tests for your product, you will probably see that the upper right quadrant (business facing/ product critique) is the quadrant, where you as a product manager should test. Normally you would use exploratory tests (free style) to verify the usability of your software, or you would check how specific you are able to cover your work process by means of this piece of software.
Here you can subscribe to my blog, and you will receive regular notifications, once an update is published: → Mailinglist. If you are interested in regular information, you can → follow me on Twitter, or you → become a fan on my Facebook-Page.
In my following articles you can find additional, and related reading:
Here you can subscribe to my blog, and you will receive regular notifications, once an update is published: → Mailinglist. If you are interested in regular information, you can → follow me on Twitter, or you → become a fan on my Facebook-Page.
Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:
Ich arbeite seit vielen Jahren in der Softwareentwicklung für Unternehmensanwendungen bei der SAP SE. Dieser Blog ist privat, und die Meinungen sind meine eigenen. Sie sind hier richtig, wenn sie sich für Praxiserfahrungen im Produktmanagement für Investitionsgüter interessieren.
High Def WordPress Theme by Graph Paper Press
Subscribe to entries
Subscribe to comments
All content © 2024 by Der Produktmanager
