KarieraPlus jobfair is the biggest fair of its kind in the Czech Republic. About 100 companies from various industries presented themselves (±10 of them were from the field of IT) this year. About 5 000 visitors attended, interested in jobs of all kinds of industries. We are lucky that the fair takes place in Ostrava, the location of profiq’s Software Engineering Centre of Excellence. We decided to attend for the first time in the history.
This article follows-up with the series of articles about tackling test complexity, adding a view on the importance of product knowledge, when coping with the complexity of testing. Let’s assume that you understand already, who your customers are;)
I managed testing of a large integrated suite of software products on one of my past projects. Each product had its years of individual history already, when the decision was made to release them as a suite. And each of them was quite complex on its own, even without considering integration with other products. The number of installation issues reported by customers started increasing to an unacceptable level after a couple of years of the products suite’s existence. The whole engineering organization became concerned about the issue. First hypotheses about the cause assumed that the released installer was defective or that the product documentation was unclear. These were not proven however. So, we decided to conduct a profound root-cause analysis.
We argued in a previous article that independent testing is about the way testers act and the quality of information that they provide, rather than about the way they are organized or governed. Organization and governence still tend to have a crucial impact on independence. That’s perhaps the reason, why some of defined standards approach testing independence from the point of view of the organization (, ). I prefer to talk about organizationally or governence-wise separate testing rather than independent testing in this context. Here is why.
Testing independence is being referred to in various ways: organizational independence of a test team on other teams within a company, independence of a testing service vendor on other vendors, or testing as an independent engineering or scientific discipline. This blog site intends to refer to software testing as a business function and its in/dependence on other business functions (e.g. software development or other, even non-technical functions). Let me hence, share my perspective on independent testing from this angle and contrast it with outsourcing testing services, given that I see their usage often confused.