Advertisment

5 Common Mistakes In Software Testing

author-image
PCQ Bureau
New Update


Advertisment

Q: What are the essential testing processes required to be performed on software before deployment?

Singh: Testing should start as soon as system or functional requirements are made available. Requirement testing helps eliminate defects way up-front in Software Development Life Cycle (SDLC) thus significantly reducing cost, saving time and later effort. Test strategy and test planning are part of test design phase. The 4 most common phases of Software Testing Life Cycle (STLC) are Unit Testing, System testing, System Integration Testing and Acceptance Testing. Unit Testing is more often white box testing and helps to debug the code. System testing focuses both on functional and non-functional aspects of the system. The SIT (System Integration Testing) assures end to end functionality of the system both from both functional and non-functional perspectives. Acceptance testing takes care of User (UAT), Operational (OAT), Contractual (CAT), alpha & beta testing.

Advertisment



Q: What are 5 common mistakes organizations make during the software testing phase?



Singh: Here are the 5 common mistakes made:



1) Not having a dedicated/professional tester to do testing. We still see firms where developers or business Analysts do testing.

Advertisment

Testing is an art in itself, and developers who write the code can often overlook semantic or syntactic bugs in their own code, which requires a professional tester's perspective to find. Developers may rush the testing phase given tight deadlines, resulting in bad code.

2) Not giving enough time for testing. The testing phase is forced to absorb any delays from upstream phases.

If the design or implementation phase of the SDLC takes more than allocated time, time for testing is shortened to achieve a tight deadline. Upstream phases cause downward pressure, resulting in buggy software to achieve goal of “time-to-market”

Advertisment

3) Start testing after coding and UT (Unit Testing) is completed. Testing should start as soon as requirement is available. This may help eliminate 20-30% defects way up front.

One of the principles used in agile software engineering methodologies is to write unit tests before the implementation is done! This is effective as it ensures that requirements are fulfilled as specified, rather than testing functions that behave as the programmers expect.

4) Not implementing traceability across the life cycle. Requirement-> Test Case-> Defect Code. Another mistake often made is to not measure the coverage. We may not need to measure 100% coverage, but it should be objective/scientifically decided.

Advertisment

Traceability of defective code is critical to have quick turnover of fixing bugs, else it becomes a time-consuming process. Also, tracking coverage is important to ensure all functions involved have been tested in some way.

5) Not analyzing the defects found in any of the testing to determine the cause. Root Cause Analysis (RCA) helps to reduce the defects in subsequent releases/cycles.

Identifying the root cause of a defect enables the ability to fix it, which ensures that other bugs do not arise because of that particular root cause. Classifying defects by root cause can also throw light on which part of the SDLC went wrong (requirement error, test error, code error etc.)

Advertisment



Q: How can organizations avoid making these mistakes?



Singh: Here are some pointers they need to follow:

1) They need to hire a dedicated/professional testing team

Advertisment



2) Plan sufficient time for testing. If the project is delayed, re-plan the release instead of sacrificing testing span. Use Statistical methods to prioritize testing in case testing time is compromised for business reason

3) Follow waterfall or V model, requirement flows into both development & testing team at the same time.



4) Use a test management system (TMS) and implement two-way traceability.

5) As part of the process ensure an RCA (Root Cause Analysis) at the end of each test phase and also at the end of the release.





Q: Does testing of software stop after deployment?

Singh: The customer experience is the final measure of the quality of the product. Testing team is the custodian of customer expectation & experience. Hence it is vital for the system/product to be continuously monitored post deployment. The most impactful suggestion for change for improved utility may come from consumers. So the drive or quality (which testing tries to ensure) continues after the deployment.



Q: What testing principles should teams working in agile methodologies follow ideally?



Singh: The core principles that must be followed are:



1) Early and continuous engagement

Providing feedback to the customer is one of the critical needs of working in an agile methodology. Hence, if there is any defect in the product that needs to be conveyed or if features need to be tweaked, then testers will also need to be involved in interaction with clients.

2) Co-location of Development and Testing teams

Since agile methods focus on developing features in “sprints” that are time-critical, it is important that developers and testers work together closely to identify and fix bugs in code. Since they need to be interacting with each other on a constant basis, it becomes far more efficient when testers and developers are physically located to each other.

3) First Time Yield

First time yield signifies the quality of a product after the first pass of testing. To reduce the number of iterations needed to fix the bugs in code, the quality of code needs to be excellent. This metric can be improved by testing and fixing as many bugs as possible in early iterations.

4) Parallel automation of all repetitive tasks

Manual testing can be cumbersome and time-consuming, so automated tests should be programmed and run iteratively to ensure systems integration, so that previous features are not broken and still pass successfully as new features are being iteratively added.

Note: Only text shown in italics represents the views of the spokesperson.

Advertisment