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?

  • It really depends on the context? In different companies there are different methodologies. Why are you asking this question? What is the real problem you're trying to solve?
    – dzieciou
    Commented Nov 4, 2015 at 10:17
  • I have exam of "software testing" tomorrow , and this question arised when I was reading notes
    – jklm
    Commented Nov 4, 2015 at 10:19

4 Answers 4


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.
  • 1
    I think you missed the most important piece, getting defects resolved destroys the stand alone bubble.
    – Paul Muir
    Commented Nov 4, 2015 at 12:57
  • 1
    Sure, happy to add that (done). Let me know if bullet point #1 reads ok to you. Commented Nov 4, 2015 at 14:15

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.

  • that is edited by someone else ,and thanks my concept clear now :)
    – jklm
    Commented Nov 4, 2015 at 11:57

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.