Problem: How to make sure the project keeps reliable knowing that its parts are reliable when tested separately?

Background: Our project is currently structured as having each team working in a specific deliverable. Each deliverable is being built in its specific code branch and there's automation processes testing each deliverable over the branches. As each deliverable progresses, they're merged back into Trunk along with other deliverables.

It's not possible, however, to apply the same automation applied into software pieces into the whole project.

Should exist a specific team to test the integration between deliverables?

  • 1
    Is this a process question or an engineering question? What is your role on the project? – Todd A. Jacobs May 9 '14 at 17:31
  • This could very well be integrated as a recurring task in your sprints. This would help the task get visibility and would be counted as part of the remaining work towards the end of the iteration. – phadaphunk May 12 '14 at 13:55
  • 1
    I can see where you are coming from that this is a project issues but I don't think it is a PMSE question. – Richard Jun 4 '14 at 15:34
  • 1
    I don't think so this is related to PMSE. TO answer your question use SVN to solve code check-in issues. – rinuthomaz Jun 5 '14 at 9:05
  • Hi Ramu, I slightly restructured your question trying to make it more PM-oriented. Feel free to revert it in case I misunderstood your original problem. – Tiago Cardoso Jun 7 '14 at 13:09

A software project testing cycle encloses several steps - including the ones you mentioned. However, happens that in most of the cases such testing cycles overlaps each other pretty much because the projects aren't big enough. In the end, both technical and functional aspects are tested all together, as a big pile of tests and checks.

There are cases, however, when testing cycles must be split and clearly defined.

  • The test you have right now, as per your description, sounds like an automated Unit Testing (or a pack of Unit tests). The objective of this is to make sure each functionality or deliverable (you name it) works fine from a technical perspective. That's the kind of testing most of the projects have.

  • I assume you might also have some sort of System Testing, to make sure that the changes are fine from a functional point of view.

  • What seems you're missing now is the testing to be applied in between both, which is called the Integration Testing.

In big projects, such tests are usually covered by specific team(s) with specific checks to be done. Is important to make sure that the testing pack used by the Integration Testing is not the same as the System Testing, as the objective of the former is to make sure the interfaces between modules are working as expected. If you don't define clear boundaries, you'll have a never ending testing cycle, so good to define beforehand the expected results and coverage of each testing cycle.

So yes, what you need is a specific team (that could be built by one resource from each module) with a specific set of integration testing to be done. To build up this test pack, I'd strongly suggest to have clear the interfaces between each deliverable.

A last tip: The testing lifecycle names, expressions and flows depends a lot on the company methodologies, so when talking with other PMs make sure what's the phase you need assistance for.

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.