Why testing is not a stand alone activity

Question

I am trying to understand the following concept -

Testing is done parallel with other activities and thus it is not a stand alone activity, it is a complete process called STLC (Software Testing Lifecycle)

Can somebody explain this concept? I mean how is really testing done with other activities?

Answer 1

Testing is not a standalone activity because:

• resolving bugs means talking with product and development to make sure that the bugs are well understood and that the path to correct them makes sense for all.
• understanding business requirements and what an application is trying to achieve means working with business users and product owners
• understanding software configuration means working with developers
• understanding the enviromental setup and requirements can involve devops
• understanding the issues that users are reporting that should be tested against can involve customer support
• in Agile environments (probably the majority based on some surveys I've seen), qa doesn't stand alone but has to work hand-in-hand with product and development as changes are made in an iterative fashion.
• there should a constant flow of information with the rest of the organization about what they understand the application does and what the organization wishes it to do now and in the future.

Answer 2

The software testing life cycle includes more steps than just the practical "doing". In short it starts with reviewing the design / requirements, going over to planing and designing your tests, execute the tests (often called testing) and finishes with reports.

So I think you connect the word "testing" only with the "doing" while having an application running and you check if a functions works as intended. But testing is more than that. The link you provides yourselfs shows this quite good in my opinion.

Answer 3

Carpenters have this saying: "Measure twice, cut once." Before you cut a piece of wood, you measure it twice, because the cost of remeasuring is much less than the cost of recutting.

The "plan before you act" principle applies to software, too. We make lots of decisions when we create software. We aren't even aware of some of them. The right amount of process can reduce the number of bad decisions. That happens before a QA person tests the software.

In theory, keeping your QA staff involved in all aspects of the software lifecycle allows a QA perspective to catch mistakes early. My experience is that you only get that with a very engaged and knowledgable tester. In practice, getting the tester involved everywhere may be less valuable than the theory suggests.

Correspondingly, giving non-testers input into the test process can improve the test process -- but only if those parties are engaged and knowledgable about testing.

The STLC page you mentioned decomposes the test process into activities, each of which requires different skill sets. That's a idea worth knowing if you are training to be a tester or managing a test team or test process.

You asked how it works in practice. A test process in one organization will look familiar to another organization, but they will vary depending on the personalities involved and the nature of the business. I think most will skip or be informal about some of those activities. For example, most testers at my company do not review each other's test cases.

Answer 4

I believe that a software tester should be involved at all stages of a website or software development. As a software tester, you are just as important as the developer and often have a more general knowledge of the item that is being tested than a developer may have. (Developers may just specialize a small component of a piece of software) If involved from the requirements or design stage you will be able to spot problems with requirements, offer suggestions on how things can be improved at an early stage and just as importantly get to know what work you have coming up so you can plan your time.

We've recently published a blog post https://blog.testlodge.com/the-role-of-qa-in-agile/ providing some tips of how a software tester should work with an agile team and be involved at all stages from planning to the retrospective.