Difference between Bug, Defect and Error

Bug, defect, and error are terms that are commonly used in software development, but they have slightly different meanings:

Bug:

A bug is a coding error or mistake in software that causes it to behave unexpectedly or not according to its specifications. Bugs can be introduced at any stage of software development, including design, coding, and testing.

Defect:
A Defect is a deviation from the requirements or specifications of a software product. It can be caused by a bug, a design flaw, or a misinterpretation of the requirements. A defect is essentially a problem with the software that prevents it from working as intended.

Categories of defects - There are three main category of defects;
Wrong: The requirements have been implement the wrong way. This defect is a variance from the given specification.

Missing: There was a requirement given by the client and it was not done. This is a variance from the specifications, an indication that a specification was not implemented, or a requirement of the customer was not noted correctly.

  Extra: A requirement incorporated into the product that was not given by the end   customer. This is always a variance from the specification, but may be an attribute  desired by the user of the product. However, it is considered a defect because it’s  a variance from the existing requirements.

  Error: An error is a human mistake that results in a problem with the software. Errors can occur at any stage of software development, including requirements gathering, design, coding, and testing. An error can cause a bug or a defect.

Fault: A wrong or mistaken step, process or Data definition in a computed program which causes the program to perform in an unintended or unanticipated manner.

In summary, bugs and defects are related to the actual software code, while errors are related to human actions or decisions. Bugs and defects are often used interchangeably, but they have slightly different meanings.

Difference between SRS, BRS & FRS Documentation

Most of the times the interviewer asked you that have you familiar with SRS, BRS & FRS Documentation or tell me the difference between SRS, BRS and FRS. Well, I tell you the differentiation in general and as per the CMMI process what is the difference between all above. Basically, usage of this document depends on the organization and company type, their standards and how organization follows processes.

SRS - System Requirement Specification:
It describes entire system flow, how data is going to flow into the system and overall functionality of the system. SRS says brief about each module's functionality and doesn't include in-depth functionality of each page and module. SRS documentation is written by IEEE Std. 830. If you want to know How to write the SRS documentation then click here
SRS documentation includes a set of use cases that explain all the interactions the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contain non-functional requirements.

NOTE: The Software Requirements Specification should contain descriptive labels for and references to every figure, table, and diagram included within the document.

BRS - Business Requirement Specification:
This document is called as high level document includes the entire requirement demanded by the client. Ideally, this document simply includes all the requirements should be part of proposed system. BRS includes list of requirements which are demanded by client and should be part of proposed system.

Business Requirements Specification Contents
• The purpose of the project
• The Client, the Customer, and other stakeholders
• Users of the product
• The scope of the work
• The scope of the product
• Features and Functionalities
• Usability and Humanity Requirements
• Performance Requirements

FRS - Functional Requirement Specification:
FRS includes requirements, converted into functionality and says that how this requirement is going to work as a part of proposed system. FRS includes requirement converted into the way it is going to work as a part of proposed system.

Priority and Severity in Software Testing

Severity of a bug is based on how much does it impact on the system. Severity refers to the seriousness of the bug with respect to functionality of the product. Is related to technical aspect of the product. It reflects on how bad the bug is for the system.The Quality Assurance (QA) Engineer decides the severity level. It is determined as per the risk assessment of the customer. Severity is defined by Tester.

Severity can be categorized into the following levels
Blocker
Critical
Major
Minor
Trivial (Also known as Cosmetic)
Enhancement (Suggestions)

Priority is based on how fast we should resolve the bug. Should we fix it now, or can it wait? How difficult is it to resolve? How many resources will be tied up by the resolution?
Priority is defined by Test Lead or Project Manager.

Priority can be categorized into the following levels
Urgent
High
Medium
Low

Lets take some example on Severity and Priority:-

high priority and low severity :
If Gmail logo is not correct then its high priority... though there is no functional bug here, any one would try to correct the logo as quick as possible as it represent the business name. So it is taken as high priority and low severity.

Low Priority & High severity :
Suppose one application which generates some banking related reports monthly, quarterly & yearly by doing some calculations. If there is a mistake while calculating yearly statement. This is a high severity fault but low priority because this fault can be fixed in the next release as a change request.

High Priority & High Severity :
Any banking application if there is a fault while calculating weekly report. This is a high severity and high priority fault because this fault will block the functionality of the application immediately within a week. It should be fixed immediately.

Low Priority & Low Severity :
If there is a spell mistake on the pages which has very fewer hits throughout the month on any website. This error can be considered as low severity and low priority.

Note for Experience peoples - most of the testing Guys do while answering the Simple question they took the examples from the Global project LIKE Yahoo, Google, Rediff, etc.
I my opinion this is Bad Habit, Always give the Example from your current or previous projects. It actually leaves a good impression on the Interviewer. You just know the concept of what "Priority" and "Severity" is, Prepare the examples from your current / previous projects.

Selenium Testing

Selenium is automating web applications for testing purposes. Nearly all of the software applications today are written as web-based applications to be run in an Internet browser. Now a day’s many organizations are using some form of Agile methodology, test automation is frequently becoming a requirement for software projects. Test automation means using a software tool to run repeatable tests against the application to be tested.
Advantages of the automation tools are repeatability of the tests and the speed at which the tests can be executed. Selenium is possibly the most widely-used open source solution. It support for several languages (Java, JavaScript, Ruby, PHP, Python, Perl and C#) and support for almost every browser out there.

Selenium IDE - Continue Reading