ISTQB - Fundamental Testing

In this section we will cover the topic about Necessary of testing. This topic came in ‘K2’ section. All the terms like bug, defect, error, failure, fault, mistake,quality and risk will be explained here.

Soft wares are generally part of life now a days. There are several types of application can be developed. We can take example of banking, customer relationship management, consumer application, business application etc. But many people are not satisfied with product as they are not working as expected and it caused critical problems like loss of money, wastage of time, poor business.

ISTQB - Fundamental Testing

A person can make mistake in code which can be call as error and that mistake produce a bug or defect or fault in the system and document. Suppose this code is running and system will fail to give expected result due to defect, this can be call failure. Still we can say that not all defect cause failure of system because some of them are not that much critical For example, label of the home page is not correct or name of the application is not correct on home page of an application. This can be a defect but it will not cause failure. But instead of this is user is not able to navigate on home page after clicking on login button then it is failure of an application.

Defect can be happened due to time pressure, complex code or infrastructure, changing technology or system interactions with different operating systems and database.Failure can be done because of environment also in electromagnetism systems. Thus we can understand the importance of testing in Software life cycle.Lets move further, Now we understand the importance of maintenance and operations of testing.

System testing and documentation of system will reduce the risk of problems in operation. Thus, we can improve the quality of the system. The defect which have been found during the operation of application, can be solved before the final client release. In software testing, we need to maintain requirement and contract document and for that we need to meet the industry standards.

Now the question is, how we can measure the quality of a software. The answer is, we can measure quality by posted defects. In the testing phase of software life cycle, Tester have to post functional and non functional defects. With the count of the founded defect, measurement of software quality can be defined. The defect can be found on basis of requirements, reliability, usability, efficiency, Maintainability and portability of an application. We will discuss further on functional and non functional defects. Now we can say that if software have few defects or no defects then it has good quality. A proper designed testing phase can reduce the risk of system failure. But only finding defects is not proper. That defect must be solved before release of the product then software quality will be increased.

How we can post the defect. This is explained here. Our bug or defect must have unique ‘Defect ID’, ‘Defect Description’ is required to understand what is the actual result of the application which have been differ from requirements. ‘Defect Steps’ must be explained in detail so developer team can be able to re-generate the bug and verify the same. ‘Application version’ should be declared in defect for maintaining whole product. ‘Date’ should be mentioned here while reporting the bug for verification so we can get idea about how long that defect have been logged. ‘Reporter Person’ name can be mentioned. ‘Status’ is important entity of defect. There are different kind of status available like Open, Assigned, In Progress, Release to unit, Release to QA,Close, Re-open etc. ‘Fixed By’ should be mentioned too. Here name of the developer or ID can be mentioned. ‘Severity and ‘Priority’ of defect should be mentioned properly so developer team can work accordingly. ‘Date Close’ will be mentioned at the end while bug have status as closed. This all terms will be define in details in further article.

To Maintain the software testing phase, we can learn lessons from past releases or projects. After understanding the root cause of defect which have been found in other application, testing process will be improved and we can reduce the risk of re-occurring defects and quality can be improved for future soft wares. Thus Quality Assurance is required.

No comments:

Post a Comment