Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

As a developer my knowledge of best QA practices, etc., are limited to know just enough to get me by writing unit tests, etc.

From a tester's point of view, what testing procedures should the developer ideally have gone through before signing off a project to the QA team to be tested?

Obviously this will vary based on what development methodology is in place, so different answers based on different methodologies would be fantastic. I don't want to step on any toes but at the same time I don't want to be passing over completely untested code.

Based on my first sentence, should I just sharpen up my knowledge in this field?

share|improve this question
    
These are all brilliant answers, many many thanks to you all! –  Luke May 13 '11 at 9:47
1  
Related: sqa.stackexchange.com/questions/54/… –  Jay Bazuzi Jun 8 '11 at 14:45
    
10,000 upvotes and a hearty THANK YOU for asking this question in the first place. Some developers feel that testing is unimportant and "somebody else's job". In truth the best products are built when everybody makes an effort to think about quality during the entire process. In my experience the best developers are the ones who thoroughly test their code before passing it off to QA. –  culix May 21 '13 at 14:07

12 Answers 12

Although unit tests are normally good enough, it's nice to see a developer ensure that they've run a process from start to finish, not just the unit tests. Because the types of tests that should be run vary greatly with the type of application, I would discuss with a testing point of contact for the product.

With new developers to me, I usually ask them if they'd be comfortable with installing the software in production without being tested by QA and taking responsibility for any defects(never really serious about it). This tends to get them thinking of types of tests that I hadn't even thought of!

share|improve this answer
    
Thats a really good question to ask - so long as you have that sort of relationship with developers. –  CBA May 11 '11 at 12:06
    
It seems like the sort of person who answers "Yes" to that question is the wrong sort of person to be a software developer. I'd never be able to do the amount of testing that an entire QA team can get done. I do testing before I pass it off, yes, but I wouldn't dream of sending it to production before it goes through more rigorous testing. –  Ed Marty May 11 '11 at 17:03
    
I can't say that I disagree with you Ed. However, the point that I was trying to make was to ensure that the developer has tested it and is reasonably certain that it works before asking for the code to be promoted to a test environment. –  Lyndon Vrooman May 11 '11 at 17:11
    
I generally do give the app a quick once through, checking that all the features (at least on a quick run) work as I intended. I wouldn't dream of passing any code over that hasn't at least been unit tested and verified by myself! –  Luke May 13 '11 at 9:20

What has worked well for me is the following steps.

  1. The developer makes their best effort at writing good code.
  2. The developer gets a code-peer review from another developer
  3. The developer runs their unit tests, and checks that they all pass.
  4. The developer and the tester sit down for a review:
    • The developer walks through with the tester to let them know what is being delivered, any related changes and any areas that aren't finished yet so that bugs aren't logged in those areas.
    • The tester runs through the tests that they have written for the feature . This allows the developer to review the tests and ensure that they make sense.
    • The tester takes a few minutes to execute some high level test and walk through the feature with the developer. Any obvious bugs are fixed on the spot, without logging them in the system.
    • With the review complete, the developer checks in
  5. The tester then formally tests the feature in the next days daily build.

Whilst on paper this may seem really onerous, we found it to be really effective in flushing out and fixing a lot of obvious issues really quickly and cheaply as we haven't touched the defect tracking system yet, and that saves everyone time in the long run.

share|improve this answer
    
I don't doubt the benefits of this methodology. I do doubt the idea of management approving such "nonproductive" time spent. I know, I know. It's not nonproductive at all, but it appears to be on the surface, which is as far as management will look at it. :( –  corsiKa May 11 '11 at 14:04
    
I disagree glowcoder, I've seen this work in Agile shops, or on Scrum teams when looking at determining whether code is done. I've even done this on small teams when getting builds and doing an "interview" with the developer about what to test. –  MichaelF May 11 '11 at 14:17
2  
The one change I would make is to make step 4 be step 1. Do the reviews on the plans first. This allows the developer to build in testability features and helps the tester avoid writing useless tests or missing key areas for testing. A review after coding might also be good, but I think a pre-review is much more important. @glowcoder, with the modification I mentioned, we do this on our (small, Agile) team, and I saw this at Microsoft as well (large, branch-and-merge). Both hire management with experience as senior developers, which seems key. –  Ethel Evans May 11 '11 at 16:45
1  
@Michael I'm not saying it's not effective. I'm saying telling management it's a good idea will not go over well because it doesn't 'appear' to be productive. I know it is, you know it is, but they're the ones with the funding and the stamp of approval. @Ethel We have senior devs for management too, but I think the issue is that they were devs HERE, so the don't have experience in what one might call a best practices environment. –  corsiKa May 11 '11 at 16:49
1  
If its presented right it can go over well, other environments might be more receptive than your own. –  MichaelF May 11 '11 at 20:18

There is no hard and fast rule for what kind of testing a developer should do before handing off to QA. It depends on the developer, the QA team, the organization, and the product. Testing is a means to an end, not an end in itself.

The important thing is to pay attention to the quality of what QA receives and the quality of the released product. If the quality at either of those points in time isn't what you want it to be, your organization needs to look at where the problems are. The problem might be with a particular developer who writes a lot of bugs, but it could just as well be, for example, a fragile third-party package or a vague or unstable set of requirements.

As a rule of thumb, here is a prioritized list of what the developer should test before handing off to QA:

  • The product still builds.
  • The product still installs.
  • The smoke test passes, i.e. the parts of the product that are essential to the most fundamental kinds of testing still work.
  • The most positive obvious test cases (by whatever definition is available) all work. In other words, if you are just trying to use the product, it should work.
  • The negative test cases all work. In other words, if someone tries to break the product, they can't.
share|improve this answer

I'm also a firm believer in the idea of developers peer review. Since adopting this methodology at my place of work the quality of work has significantly increased. The new set of eyes provided by peer review are frequently finding more efficient ways to write code or picking up errors that would have otherwise been missed.

This said there is always the matter of available resources / size of the project; a small team might not be able to effectively peer review all new features while simultaneously sustaining their regular work flow.

Additionally as obvious as this sounds I would encourage you to clearly inform your testers of all changes that you make to your code (no matter how small). There have been countless times when new features have been implemented but because the relevant work items were never updated with specific enough details I never knew the new feature existed; until I stumbled across it by accident during exploratory testing that is.

This is even more important if your testers have a large amount of automated tests (as the smallest change can cause these tests to begin to fail).

share|improve this answer
2  
Additionally, let your testers know if the code modified is called by or used anywhere else in the application or another application that is integrated. I've seen a few times where a simple change to a variable has broken seemingly completely seperate functionality. –  Lyndon Vrooman May 11 '11 at 14:31

This really depends on the complexity of the project, the size of the team and the difficulty of integration.

  • Unit Tests. Everybody knows this, but it doesn't hurt to repeat. Run your unit tests to make sure your code still does what it should. This is particularly important for developers with code that doesn't need compilation (I'm looking at you, applicative DBAs).
  • Integration Tests. Whenever a project has more than two developers, it needs integration. You would not believe how many times I've had broken builds when one dev breaks an interface without telling another dev. These are also usually quite easy to automate, as they just involve an quick regression check of the unit test.
  • Smoke Test/Preliminary Acceptance. These are quick (15 minute) tests run by the developers after a build to ensure that the build is good enough for QA. The best strategy I know for these is to get QA to write them and dev to execute them. That way nobody can complain about the others, and there is less feeling of time wasted. These are usually done per feature, and you only need to test what you've changed.
  • Automated Regression Test. Another idea is to have an automatic test run right after the nightly build. The test compares the results of the new build to a known good build and reports any differences. We run the build at 0300 and the test at 0430. That way you have results waiting when you come in to the office.

Those should normally deliver good builds to QA, which tends to improve the working relationship, among its other advantages.

share|improve this answer

In my organization, we try to have a developer and a tester sit down before writing any code to have exactly that discussion - because the answer will probably be different for each feature you implement.

Unit testing is a given in my team - but more often than not, the tester and developer will also automate GUI tests up front too. That way the core business logic is tested when the feature is passed to QA - leaving testers to conduct exploratory testing.

share|improve this answer

The development process should include as part of the deliverable, well written unit tests that accompany the software into the QA cycle. Preferably, a Continuous Integration server would be configured to run the unit tests after QA test build completion.

share|improve this answer

It depends. If your process is lightweight (e.g. Scrum), then continuous build, automated tests, etc. may be sufficient.

If your process is heavyweight (e.g. waterfall) with segregation/slowness between development and testing organizations, then you probably want to do your own formalized manual testing so to avoid being the bottleneck. In addition to automated tests (unit, integration, UI automation if possible), you should deploy the software in a production-like environment using your production deployment process.

After the deployment, run a few smoke tests against important and/or high risk components. Then, have each developer verify their bug fix(es) and feature add(s). Better yet, have developer B test developer A's work and vice versa.

share|improve this answer

We have Developers test their code by doing a build and deploying it to the Development environment, and verify what they can in the new environment. If there are other changes in the build they need to coordinate with others to make sure testing is done. In other environments Developers would write out simple plans and switch them with each other, so each Developer is testing code they did not write.

I'd check with your QA team and see what they would need, at a minimum what you should have done is enough to verify that the build will not crash when started in the QA environment so they don't waste time installing a build that will not work.

share|improve this answer

All of these suggestions are great. I have only thing to add. When a bug is fixed in 1 platform, since code is sometimes shared with other platforms, please test the other platform(s) too to see if the bug exists there. Especially with customer bugs.

share|improve this answer

At an absolute minimum, a developer should ensure that the software:

  • compiles (if applicable)
  • installs (if applicable)
  • runs (open and/or log in)
  • unit tests pass

If any of these fail, then there is no reason to go on to further testing.

Also, you may want to have an automated "smoke test" that runs through the basic functionality and verifies that there are no major errors when taking all the common paths through the system. If a smoke test of this kind exists, it would also make sense for it to be run before handing the build off to the QA team.

share|improve this answer

Test more than Functionality, especially if a web application.

  • SQL Injection
  • XSS
  • Security Modules (http vs https, header injection, cookie hijacking) etc
  • Also ensure functionality of your client side code in multiple browsers if your environment allows multiple browsers
  • Test with Javascript on/off
  • Test Section 508 if needed
  • Test buffer overflows
  • Test when application crashes and determine if it leaves things in an insecure state

There are plenty of things a developer should be concerned with other than functionality (but make sure you do test functionality).

The functional tester probably isn't going to find the more critical errors if he/she is only interested if it works or not.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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