Sharing development test cases (unit and development integration) with the QA (test) team?

The testing team (the so-called QA team in some organizations) insists that the development team should share their (the development team’s) test cases with them. Their arguments are that the development test cases are the starting point for the QA testing.

As a development team member, I don’t understand the request. Per me, the tester should test the solution based on the requirements. I don’t know if the test team should be shared with the detailed design (low-level design) document. However, we are sharing them the detailed design.

I have read some posts here that say the QA team should share their test cases with the development team for a better solution and for better throughput. But, nothing sort of the development team sharing their test cases with the QA test team.

It looks like my QA team is very happy if I share my development unit and integration test cases and the test results.

When your dev team and your QA team don’t not talk to each other, there is a certain risk that some tests are unnecessarily done twice, and some others are forgotten. One worst case scenario is when your dev team has implemented some nice automatic integration tests, which run in a few minutes or hours, and your QA people tests the same things manually, spending days or weeks for that task. Another bad scenario is when both groups think that the other group is responsible for some type of tests, and so those tests are omitted.

So, assuming both groups work as a team and not against each other, it makes sense to inform each other in detail which tests are made by which group, and let the two groups coordinate there activities.

Testing team (the so called QA team in some organization) insists that the dev team should share their (Dev team’s) test cases with them.

Sure, QA should have a general understanding of what is covered by unit/integration tests, and what is not.

Their arguments are Dev test cases are the starting point for the QA testing.

…even if their reasoning is flawed. The #1 mantra of a QA person is don’t trust the developers. “Don’t worry about it! I checked that thoroughly!” is the first step towards a giant production issue.

As Doc Brown says, it’s not good to spend a whole bunch of QA time on something that is well covered by automated tests. But it is foolhardy to spend no time on something that is well covered by automated tests. And it’s wasteful to spend a whole bunch of time documenting your unit tests in detail when QA shouldn’t really trust them anyways (and because that level of documentation drives your developers to make less/bad unit tests).

In a modern software architecture the intent is that the tests not only test the code but they do so in a way that documents their functionality.

This documentation of what the code does (in addition to what it is intended to do in the specs) is useful for QA’ers to better understand the intent of the code and also whether it matches the requirements. It is also useful information when QA’ers are writing test cases and it will help give them a sense of what is, in theory, being tested already. Some of the areas under test might benefit from additional cases and others might be exposed as not having tests at all.

The actual details of this exposure will depend greatly on the organizational makeup and in particular on the technical depth of the testers (e.g. reading source code).

To be somewhat contrarian… I often like to ignore the developer tests and come up with my ‘own’ tests (I am a member of a large QE team). I have found that ignoring developer tests helps to avoid the mindset of looking at the problem/issue/feature from a developers point of view only.

MY QE motto is: QE should be adding value by testing the product. “merge and run unit tests” alone is insufficient QA !

My first reaction of this question is “it depends”.

It depends on what you mean by “development team test cases”.

If you have only unit tests (white-box test); QA Team (integration and system test) could not leverage your test-cases. Unit test are only there to verify your unit, which solely don’t satisfy a requirement (mostly). White-box testing shouldn’t be the way for integration or system tests.
If you have behavioral tests; QA Team can use them to derive some integration scenarios.
If you are using TDD; as per definition, tests are executable documents of the requirements, architecture and design of the application. QA team would definitely need these test cases.
Some test design methods like gray-box testing requires detailed design information to be able to isolate or to mock test subjects like component or subsystem (integration test). Therefore sharing the detailed design with QA team is also necessary.
System Test guys never bother with detailed design. They focus on user scenarios. Therefore development tests (white-box) won’t be any use for them.

My humble recommendation for your case is an evaluation of agile approaches like having tester(s) (QA) within the dev-team and design tests (feature, integration, system) together upfront.

There’s no reason that you shouldn’t share what you’ve tested with the QA team, however they should be duplicating the tests of yours that they feel are important to properly verifying the application.

1) They are responsible for testing the code/application/whatever. By duplicating your tests where appropriate, they verify that your test was done properly.

2) As a developer, you’re responsible for unit testing your code (generally, however some organizations have started having dev’s test their code as well). This is a different approach, and typically is focused more on covering the decision points in a method.

3) As you mentioned, it’s important for your test team to share their test cases with you to help you think of cases that you may not have originally considered.

4) Someone mentioned that it’s the test teams responsibility to test to the requirements, and while this is true, the detailed design is quite helpful as well. By having the design, the test team not only can make sure that you’re covering the requirements, but helps them to understand some of the design decisions, and will help them to ultimately create better test cases.

Filed under: softwareengineering - @ 21:09

Thẻ: integration-tests, qa, teamwork, unit-testing

Thiết kế website giá rẻ

Danh mục

Sharing development test cases (unit and development integration) with the QA (test) team?