2

I am confused whether a developer or tester should typically do unit integration testing.

For example, I know that Unit Testing is done by a developer, System Testing is done by a tester, and User Acceptance Testing is done by the client.

Who is typically responsible for Unit Integration testing?

  • What's your confusion and I think there are lot of resources in google to answer this question. – demouser123 Apr 11 '18 at 14:50
  • It depends: Testers can do unit testing of their own libraries, integration testing is often done by testers and developers – dzieciou Apr 11 '18 at 14:52
  • @demouser123 not clear – nikhil jain Apr 11 '18 at 14:55
  • What is not clear – demouser123 Apr 11 '18 at 15:01
  • who does it integration ans system testing some sites says developer some says tester? – nikhil jain Apr 11 '18 at 15:02
4

The one and only correct answer to this question do not exist. It depends on many factors. It depends on the software development life cycle model, on the team and developer to tester ratio and so on. There are 5 main testing levels that we can highlight:

  1. Unit testing - It is basically done by the developers to make sure that their code is working fine. They test classes, functions, interfaces, and procedures.
  2. Component testing - It is also called as module testing. The basic difference between the unit testing and component testing is in unit testing the developers test their piece of code but in component testing, the whole component is tested. A component is made of the "units" mentioned above, put together in a logical sense. Mostly done by developers but testers can also participate, focusing on important or complex modules.
  3. Integration testing - Done when two modules are integrated, in order to test the behavior and functionality of both the modules after integration. I'd say this is mostly done by testers but I also encountered developers writing integration tests for crucial parts.
  4. System testing - testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirement, done by testers.
  5. Acceptance testing - verification of the behavior of a software product, generally expressed as an example or a usage scenario. Usually done by the customer or a client but sometimes it is the testers responsibility.
0

Usually speaking this Question has two parts:

1) Unit Integration Testing: This is the part which the Developer needs to check before providing the Build to the QA Team. This Unit test will atleast ensure that Basic Integration between the Features are working fine.

2) Thorough Integration Testing: This is the major part and hence the Tester is the whole responsible for this part. QA Team need to ensure that all the Basic and Advanced functionality of the integration tests are working fine.

This approach is usually followed by the top software testing companies.

-1

tl;dr Everyone involved is responsible for the outcome, including quality.

Create true teams, not simply groups of people ordered to create the same thing. The best solutions come from truly collaborative, cross-functional, self-organizing teams comprised of paint drip or T-shaped professionals. Instead of focusing on individual responsibilities, promote collective ownership of product development including quality.

Promote a test first mentality starting with planning. Discussing the applicable scenarios (happy path, errors, boundaries, ranges, integration, performance, etc.) when beginning the effort on a slice of work then designers, developers, testers, etc. have a better understanding of the needed functionality and are thinking about quality as the effort is undertaken.

Various techniques and practices such as Test Driven Development, Behavior Driven Development, and Acceptance Test Driven Development can be used to combine planning, design, and development. The result is a safety net of automated tests to help ensure quality from the beginning and against regression.

Pair and mob programming are additional tools that help promote collaboration, shared ownership, and improving paint drip or T-shaped professionals.

Well written tests become a part of documentation. They show how the product should behave, validation that it does, and indication when that changes. It is a helpful starting point for new team members or when another team member has to visit, or revisit, existing code.

Everyone involved is responsible for the outcome, including quality. The divisiveness between roles is a problem that impedes individuals, teams, and organizations from efficiently and effectively creating and delivering valuable solutions. Collective ownership through collaboration is one way to address the issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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