Software tester

Sep 14 2009   1:00PM GMT

Ten facts (or myths) about developers and testers

Posted by: Jaideep
software testing, Software tester, Bug, coding, software code, software, developer, code, customer requirement, business requirement, business needs

We all know developers and testers both have a tough job all the time. Developers have a key role in developing the software as per customer requirements embedding customer’s business needs into it. Similarly testers have to put all their efforts in ensuring that the software is matching customer specifications flawlessly and is bugs free. In a nutshell both developers and testers have a common goal of ensuring a superior product delivery at customer end. If that is so why there is a never-ending tussle between testers and developers. Why developers feel testers are unnecessarily trying to poke their nose into their affair. Why testers feel that out all the bugs found out by them, most of the bugs would have been already handled by developers if they had done their job more seriously.
All this leads to certain questions about testers and developers which they only can reply to:
1. Testers are not supreme and so are developers. If developers can build so many bugs while writing the code, testers are also bound to leave certain loopholes in their testing. This is universal and never ending story.
2. Most of the testers around the world who test software do not understand very well the purpose behind the testing. They keep oscillating between their role as policing, controlling quality and excessive reporting.
3. Both developers and testers carry a single goal of ensuring good quality of software at the end of the day but still keep blaming each other for the shortfalls.
4. If developers are kept for writing code, it is well understood that they are being paid for writing good code and not bad code. Then why bugs at all? If a developer has been hired for coding, is it wrong at organization level to expect a 100% bug free coding from developers. If they are permitted to write code with bugs, why not every other function in the organization is allowed to perform their daily tasks with errors. Can’t we have perfect coders?
5. If testers find out the bugs, instead of being thankful to them, why developers start finding out reasons of cornering them. Developers are hurt when testers find out bugs in their code, and instead of going into a thanks mode for testers they start going into another mode where they themselves start losing their respect. In turn they start finding out weaknesses in tester’s capabilities, testing criteria or bug reporting process.
6. It is a well proven fact that while fixing reported bugs developers are bound to generate new bugs. Does it not make them circling them around the same product?
7. Testers sometimes have an understanding that if they report less bugs will mean a question mark on their job, which forces them to report many a times non-quality bugs thereby increasing gap between developer and tester.
8. Developers, once they know that the product has to undergo testing, write code so foolishly that they generate lot of unexpected bugs.
9. If testers are hired for finding out bugs, is it not their lack of depth of knowledge that leads to bug explosions at the later stages? Are testers involved in coding, or business study or implementation?
10. If developer’s after reading so many books on development write codes with bugs, I don’t think a good tester criteria should be if he has read a book on testing or not.

Jul 6 2009   10:00AM GMT

Five stages in a project when Software Tester becomes Quality Analyst

Posted by: Jaideep
Quality Assurance, Software tester, software testing, Project Planning, Test Plan, test case, product analysis, customer requirement analysis, product functionality, software functionality, software documentation, software document, test result, test performance, software performance, testing process, quality analyst, QC, QA, quality control, load testing, performance testing, functional testing, security testing, test coverage, software build, software, analysis, functionality

A software tester evaluates software based on certain parameters. These parameters are set as per product, customer and organization requirements. Testing could be just of functional features or include load, performance and security. For any parameters a tester has to work as quality analyst to understand requirements, features and accordingly build test cases and perform test. This is the quality control part. On quality assurance front the quality team has to build standards for requirement freezing, planning, development, implementation and post implementation phases of a project.

A software tester at various stages of a project gets on to the job of a Quality Analyst by performing following tasks:

Analysis of customer requirements: The first and foremost analysis required is that of the customer requirements to ascertain if it is complete, detailed and free from any confusions, ambiguities or equivocalness. Any flaw in requirements will certainly lead to a big disaster at a later stage. Unclear requirements are not difficult to build, but are difficult to manage. Every requirement should be in black and white. Each line should be very clearly documented such there should be nothing hidden between the lines.

Analysis of Product Functionality: Requirements documented and product built has to go hand in hand. It should not happen that requirements and product speak differently even a single line. Usually while testing functionality of a product, tester forgets to refer to requirements documented, or asks developer about the functionality. The developer will certainly explain him the functionality he has built not what exactly has been mentioned in the requirements document. If this happens, it will certainly cause a big blast at implementation or acceptance stage.

Analysis of Product related documents: There are many documents prepared during the project. Some are meant for internal use, some are prepared for customer. All these documents need to be inspected thoroughly and neatly.

Analysis of test results: Test cases are built to perform tests resulting in bugs report or test results report. A thorough scan is must to ensure complete coverage and thorough testing. The report should be detailed in all respects in terms of clarity and coverage.

Analysis of Testing Process: The testing process once establishes need to be revisited again and again to improve further at every go. Once established does not mean it is ultimate and best. Improvement has always a scope howsoever best your process or product is.