There are several questioning comments on my post Testing is Not a Service: What do I mean by testing and how do I reconcile my statement with the context-driven school of testing?
Let me clarify what I mean by service first. The way the participants were discussing testing as a service, they meant a common service to the organization, not the project. In the same way that accounting is a service to the organization, or the HR is a service to the organization, their organizations thought that testing was something that could be applied to projects (frequently long after development “finished”), in the same way that other organizational services could be applied to the organization.
But if you think of testing as a service, it's applied to a project, not an organization. In a waterfall lifecycle, where the bulk of testing occurs at the end, it's barely possible to have effective testing after development. It costs more in time, risk, and money. The testers take much more time to find problems because they're not integrated into the project. It's likely the testers will not find the problems the customers will. The cost to fix a defect is much higher. But the kinds of testing these people were talking about, “Spend a couple of weeks testing this app,” or my favorite, “Go over it lightly” is not effective for the product or the people. Those aren't services to the project; they are a service to the organization–an ineffective service to the organization.
To me, testing is a part of development. When I talk about development, I mean code and test and documentation development, because I mean product development. Whatever it takes for the whole product is part of development. In that sense, testing is a service to the project, but definitely not a service to the organization. Product development is the service to the organization. Cost effective, reduced-risk product development requires integrated testing.
So how do I reconcile my view of testing (a component of product development) with the context-driven school of testing? Look at the The Seven Basic Principles of the Context-Driven School. My statements are congruent. Especially see: Testing groups exist to provide testing-related services. They do not run the development project; they serve the project. (They don't serve the organization; they serve the project.
Product development is the goal, not code development or test development. Effective product development requires an integrated team, who all provide services to the project, not the organization.
Labels: organization, product development, project management
Hi Johanna,
You scooped my next question 🙂
I’m sure we could quibble about details, but now I’m comfortable agreeing with your written .
I like to think about testing as delivering information to various stakeholders. If the stakeholders then act upon this information, I call it feedback.
As a tester, being integrated with the stakeholders helps me tune the information so that it is more likely to be acted upon.
Another thing that helps me deliver better information is to realise that the stakeholders have different needs. Coders require different types of information than documenters, and documenters need different types of information than project managers. And so on with end-users, customers, sponsors, managers, auditors, the testers themselves, etc.
While I agree that testing should be an integrated process in the development of a product, I think the argument you are making is just semantics. You are actually arguing that testing should be integrated in the development process and not just
tacked on to the end – which I am in total agreement with.
However, you can call testing a “service” to the organization AND it can be integrated from the start (or it may not be). Or, you can just call it part of development AND it can be integrated from the start (or it may not be). I don’t think calling it a service to the organization is wrong or incorrect.
If it suits your needs to call it a service to the organization, then that’s fine.
If it suits your needs to call it a part of the development process (or a service to the product or the development team), then that’s fine.
Either way is fine, so long as testing starts with the start of development. Isn’t that what you are trying to say?
Your assumption that a service (to the organization) cannot be an integral part of a project isn’t correct, but I don’t think that was the point you were trying to make.
Testing is a major component of the righthand side of the V-model. It comprises of verification and validation – I assume reader know the difference.
Although the activity of doing tests is part of development – and therefore part of the project – the act of doing tests may be specialistic and require special resources (e.g. skills, equipment, security area access). It may be efficient for an organization to have a specialized “testing department” to provide the “service of testing” to the project.
This way testing is both a service and an activity of the project.
Hey Johanna
Product design testing is a requirement of ISO in verification and validation. Testing is verifying and validating the outputs or deliverables of the design.
However, testing is also done throughout a company outside of product development. There is testing to validate product improvements, process changes, and perhaps trying to duplicate a performance issue that a customer identified. In these ways, it can be viewed as a common service for manufacturing, marketing, and design.
I guess I see it as both.
Pingback: Project Work vs. Product Work – 1