Increasing build stability and quality with proper developer testing

Quality Assurance activities in a software project are considered a major factor in its success or failure. In most of the cases, software life cycle would never ignore the need of a proper and rigorous QA cycle. Dedicated QA teams need to work closely with the software developers at various stages of a project. Many advocate a ratio of 1:2 or even 1:3 between developer and tester, although it is a rare sight in most of the small and medium size projects. No matter what the ratio is, the QA department however is still not the only one responsible for ensuring the quality. Developers themselves play the most critical part in making the quality assurance process efficient and fruitful by ensuring their code passes a small test phase every time they make the code available to others in the team. Yet, it is unfortunately considered the least important task among developers. There are various approaches towards effective developer level testing. Following key points can help address the need of this important activity.

Developer’s test run- A Mandatory step:

Developers generally feel home when they see their code is up and running. In pressure situations, they are keen to mark the job done and move to a new task. However, with experience, they realize how important it is to include few more validation steps before announcing completion. The First rule to remember is that pushing untested code to QA is a crime (indeed). A code should never leave a developer’s workstation as a part of application unless they have done some reasonable test effort. The confidence and satisfaction that a piece of code works well should not come before doing a decent dry run. Whenever a unit of code gets completely implemented from a developer standpoint, they should plan for a quick set of tests themselves to see if the code runs fine in different scenarios. There is no point in pushing software/modules to QA team if a developer can observe the bugs himself. The attitude of leaving a bug to be identified later by QA and then fixed in new iteration is only a disaster. It not only increases no. of bugs, but eats up QA time in logging bugs that are already known to developers. Additionally, making a new build creates another overhead which then needs to be tested and approved by QA team again. This definitely adds up substantial time and additional iteration, hence more burden and pressure on the overall final production release. Sanity check is the first step towards a developer test which ensures that a code never produce casual bugs. Like a button able to be clicked but non-functional, or a date field accepting a string value. Secondly, unit level bugs should ideally not get past developer tests almost always. A developer should make sure a unit of code works well in certain scenarios. For example, you are writing a piece of code to send emails in your application. You obviously need to test if your functionality works by sending emails and making sure they are being received properly. You should try and find a few different ways to send emails in your application and try the scenario at least once yourself before marking a feature complete. Now if QA points out an issue, it is perfectly fine as they will most likely post issues associated to a particular scenario or in a sequence or state and it wonít be a casual bug where pressing a button donít trigger a particular functionality always. Furthermore, authoring a particular piece of functionality can involve writing code at various application layers. If the code is not written carefully, it can introduce bugs in existing functionalities as well. On the other hand, a new change might just be isolated and specific to a certain area but depending on the situations, the closely related functionalities should also get a test run, though it purely remains a judgment call.

Test Driven development (TDD):

A pretty mature and useful approach of ensuring quality in a development process is Test Driven Development. TDD requires the developer to write test cases first up before actually start coding functionality. So there always stand verification/validation logic to approve the implemented functionality against. Most development frameworks offer integrated support for creating Unit tests and re-running all before a release or compile effort. This approach although offer various benefits in the long run but is not always feasible in terms of time it adds initially to the project. However, as a general rule, unit tests should not be avoided in a size-able project and in case they are left out, it should be a justified decision rather than a practice.

TDD diagram

  1. No comments yet.

Leave a reply

 
 
 


four + 9 =