What are benefits of agile process improvement?

Agile methodologies that we have today are a resultant of the experiences gained from the real life projects that were undertaken by the leading software professionals. These professionals were thorough with the challenges and limitations imposed by the traditional development methodologies on various projects. 

- The agile process improvement directly addresses the issues of the traditional development methods both in terms of processes and philosophy behind it. 

- Agile process improvement provides a simple framework to the development teams suiting varying scenarios while focusing up on the fast delivery of the business values. 

- With all these benefits of the agile process improvements, the organizations have been able to reduce the associated overall risk with the development of the project. 

- The delivery of the initial business values is accelerated well by the agile process improvement. 

- This is achieved through a process of constant planning and feedback. 

- Agile process improvement ensures that the business values are maximized throughout the development process. 

- With the API’s iterative planning plus feedback loop, it becomes possible for teams to align the software process with the business needs as required. 

- Another major benefit of the agile process is that the software development process can adapt to the ever–changing requirements of the process and business. 

- By taking a measure and evaluation of the status based up on the amount of work and testing done, visibility can be obtained to a more accurate value. 

- The final result of the agile process improvement is a software system that is capable of addressing the customer requirements and the business in a much better way. 

- By following an agile process improvement program, not only just deployable, tested and working software can be delivered on an incremental basis but also increased visibility, adaptability and values are delivered earlier in the software development life cycle. 

- This proves to be a great thing in reducing the risk associated with the project. 

- There are a number of problems with the traditional development methods. 

- In a research it was found that the waterfall style development methodology was the major factor in the contribution of failure of the software. 

- Some other software could not meet the real needs. 

- They had the inability in dealing with the changing requirements and late integration. 

- All this has proven that the traditional development methods prove to be risky as well as a costly way for building software. 

- Thus the majority of the industry has turned towards agile development.

- There is a continuous feedback input from the customers and a face to face communication among all the stake holders. 

- The business needs associated with the agile process improvement are ever changing. 

- Organizations want quick results from what they invest. 

- They want their improvement programs to keep pace with these changing business needs. 

- The agile process improvement is composed of several mechanisms using which all this can be achieved. 

- Working iteratively lets you deliver the product before the deadline to the customer. 

- It lets you deliver only the things are actually required i.e., it does not let you waste your time on the un-required things. 

- Also, early and regular feedback from the customer lets you deliver the product with quality as desired by the customer.

- Agile projects are distributive in nature i.e., the work is divided among people. 

- Agile software development is still an immature process and there is a need for improving it for the betterment of the software industry. 

- Agile process improvement is one way to do this.

How to fix the bitmap that failed to stabilize error?

It may happen that the bitmap might fail to stabilize the error in silk test. It is quite a frequently occurring problem but needs to be addressed seriously. 

Most of the times you might have been asked for or required creating a test case that can be straight-forward put to use in carrying out the bitmap verification. 

You set down to create such a test case and go for the verification of the full window while the recording is in progress. 

During the execution of the test case all of a sudden you get an error as stated below:

“Error: bitmap failed to stabilize”

Finding such an error can even be a nightmare for you and sometimes the whole quality assurance team may fail to think of a solution for this. You won’t even find solution for this in the silk test documentation. 

- There are situations that the bitmap issue might be stated in a described state.

- It is only when there is some instability in the verified windows that is to say that some element of the screen is experiencing frequent changes. 

- In such a situation, the stable copy of the bitmap is captured by the silk test automation tool. 

- If in case it could not get the window tested within a specific time interval, then it generates an exception saying “E _ BITMAP _ NOT _ STABLE”.

- Different approaches to such a situation might be used by the different quality assurance engineers. 

- You need to set the below mentioned options to 0 in the 4test code:

Agent. Set option ( OPT _ BITMAP _ MATCH _ COUNT, 0 )

Agent. Set option ( OPT _ BITMAP _ MATCH _ TIME OUT, 0 )

Agent. Set option ( OPT _ BITMAP _ MATCH _ INTERVAL, 0 )

- Another way of doing this is going to the options menu, then agent, then bitmap and change the required values. 

- Another error occurs while capturing image via the capture bitmap method. 

- In some cases when this method was executed the silk test was observed giving the following error:

“bitmap region size (some coordinate) is not valid”

- In such a case the getrect method can be used for obtaining the coordinates of the bitmap. 

- The getrect method returns the following:

1. X coordinate of the active bitmap
2. Y coordinate of the active bit map
3. Width of the active image
4. Height of the active image

- For capturing an image, one requires two coordinates of the image i.e., (x1, y1) and (x2, y2).

- Here the coordinates correspond as follow:
1. First co-ordinate is for the top left corner of the image whereas

2. The second coordinate points to the right bottom corner of the image. 

- You can even take help of the identify object feature of the silk test workbench for discovering these coordinates. 

- To avoid these errors it is necessary that you fix the screen resolution in the first go itself i.e., using the first script itself using the following function:

Maximize()

- Once this function has been implemented, and then you should go for capturing the screen shot. 

- If this is not done then there are chances that the screen size may keep on changing i.e., it may expand or shrink according to the settings that you made for the previous scripts. 

- This may also cause the coordinates to shift on the screen which may cause the script to capture something else than what was expected. 

- However, the getrect method can return both absolute as well as the relative methods. 

How can you handle exceptions in QTP?

Exception handling is one of the major features of any test automation and testing software suite. The same is with the HP’s quick test professional which is also a test automation and software testing suite. 

How exceptions are handled in QTP?

- The exception handling thing is managed by the quick test professional by means of some recovery scenarios. 

- The basic goal of exception handling in quick test professional is to have the tests running even if some unexpected failure is encountered. 

- There is some memory space associated with the applications that are tested. 

- This memory space is hooked by the HP quick test professional and this in turn gives rise to some exceptions which may cause the quick test professional to falter, terminate and become unrecoverable. 

- The recovery scenarios used by the quick test professional come in built with the whole software package. 

- But it is not always beneficial to rely on the recovery scenarios rather it is always better if you can handle the exceptions and errors yourself. 

- A recovery scenario manager is also available which has an in – built wizard using which you yourself can define you very own recovery scenarios. 

- This wizard can be accessed by going to the tools menu and then selecting the option “recovery scenario manager”. 

- These recovery scenarios deal in three steps as stated below:

1. Triggered events
2. Recovery steps and
3. Post recovery test run.

Some may think that using the recovery scenarios is the only option for handling the exception in quick test professional but it is not so.  

- Another option is which involves the use of descriptive programming.

- This approach is better than the former option since using it your application can gain more visibility and robustness. 

- Though, the recovery manager can be used for many scenarios but some of the real time scenarios cannot be handled using it. 

- In such cases descriptive programming is the alternative. 

- Third option will be make use of the exception handling capabilities of the visual basic script like the following:

1. Err object
2. On error resume next
3. On error go to 0 statements and so on.

- The last two can be used at the script level. 

- The in–built recovery scenario of the quick test professional supports only 4 exceptions:

1. Object state exceptions
2. Pop up exceptions
3. Application crash exceptions and
4. Test run error exceptions

- A simple example is when you play back the recorded script, the AUT screen is minimized and a run time error is generated as “object not visible”.

- A “test run handler” can be used for this. 

- Four trigger events have been defined during which the recovery manager is supposed to be used:

1. When  a pop up window appears while an application is open for the test run,
2. When the value or the state of a property of an object changes,
3. When a step in the test run becomes unsuccessful or fails terribly, and
4. When the open application itself fails while the test is in progress.

- All of the above mentioned 4 triggers are nothing but exceptions. 

- The quick test professional can be instructed accordingly regarding how to recover from an unexpected event or failure that occurred during the test run in the application development environment. 

- Separate individual files can be created for different scenarios as per the requirements. 

- If you search the web you can find an advance qtp script that can attach as well as enable the recovery scenario file when the test run is in progress. 

What is a Test Fusion Report in QTP?

This article gives a detailed description of what a test fusion report is. Once a test has been executed, all the aspects of that particular test report are displayed by a certain report that has been termed as the test fusion report. 

What are Test Fusion Reports?

Basically the below mentioned aspects of a test run are displayed by the test fusion report:

1. A high level overview of the results.
2. Tree view of that particular test specifying the exact point where the application software actually encountered failure and this tree view is expandable.
3. The data that was used during the test run.
4. The screen shots of the steps of the test run where the application software showed some discrepancy.
5. Explanation of each check point in high detail along with the fail and pass criteria.

- These test fusion reports can be combined along with the quick test professional. 

- The main advantage of this is that on combining these reports with the quick test professional, they can be shared among the whole development and quality assurance team. 

- The test fusion report displays at what all exact points the application software failed. 

- The test fusion report consists of a data table. 

- This data table gives a record of the whole test data. 

- A screen view is also presented in the test fusion report which provides one with the actual screen view. 

- With the aid of the test fusion report, even the success or failure of the check points can be determined. 

- The test fusion report proves to be quite a handy tool while the developer has to report to its client or customer. 

- There are some other components of the test fusion report as mentioned below:

1. Name of the test
2. Test case
3. Start of the test run
4. End of the test run
5. Name of the result
6. Iteration
7. Status

- A different aspect of the test run is displayed by the test fusion report and can also be considered to be a kind of compilation of the whole application testing process. 

- The screen shots provided by the test fusion report provides a solid support for any inconsistencies that are present within a software application. 

- The test fusion report is represented in the tree format and displays all the aspects of the test run in the same format. 

- You can find detail for each and every step of the iterations here in the test fusion report. 

- All the results of a test are collected by the test fusion report. 

- Test fusion report can also be categorized under the instances of the collecting parameter return. 

- There is a big difference between the errors and the failures which is distinguished by the test frame work. 

- Anticipated problems are called failures whereas the un- anticipated ones are the errors. 

- All these are listed by the test fusion report. 

- The results of the testing have to be reported at various stages like unit testing, integration testing and system testing and so on. 

- The test fusion report provides the state of the software product that is under development through different angles. 

- Producing this test fusion report takes around 5 – 10 percent of the total development effort. 

- This percent though being quite less is of great significance, after all an organization cannot give a certification about the readiness of the software product in just one line. 

- Producing a test fusion report becomes much more important especially when the software encounters some problem.

- There are several other aspects of the software system or application that the customer would like to know apart from the functional requirements like a few mentioned below:

1. platform
2. dependence
3. performance and so on. 

What are different characteristics of smoke testing?

Smoke testing is considered to be one of the preliminary software testing techniques to further testing that are intended to reveal simple failures that are simple enough to be a cause of a software project to be rejected. 

In the term “smoke testing”, smoke is used as a metaphor. All the test cases that are known to provide coverage to most important functionality of a component of the software system or application are selected and grouped under a set and later are run. This is basically done to ascertain that the most crucial functions and features of the software system and application are working as desired or not! 

One can understand smoke testing better by having a look at the below mentioned questions:

1. Does the program run?
2. Does clicking the start button do anything?
3. Does the program run?

Goals of Smoke Testing

- The primary goal of the smoke testing is to determine if the problem or fault in the software system or application is so worse that any further testing on that software system or application will be a waste. 

- To put it simply, the smoke testing can be considered to be a cheap and less time consuming way to broadly cover the features and functionalities of the software product in a limited period of time. 

- By carrying out smoke testing, you can easily find out if any of your software system’s or application’s key feature or functionality is broken at some point and so your development team would not spend further time on it fixing or recreating it. 

People often confuse between the two similar terms i.e., smoke testing and build verification test. No doubt both are one and same the only thing when the smoke testing is performed on a build it called build verification test.

When should smoke testing be performed?

- One of the best practices of software testing is that the smoke testing should be performed everyday without fail. 

- Furthermore, the smoke testing can also be performed by the testers before accepting a module or build for further testing.

- Some testing has been listed as the most cost effective method for the identification and fixation of the defects in a software system or application after the code reviews by the software giant Microsoft Corporation. 

- The smoke testing is deployed as a process for the validation of the changes that have to be in the code before they are passed on to the source control in the Microsoft Corporation. 

- The smoke testing has to be carried out either automatically or manually that is purely the choice of the tester.

- When the smoke testing is carried out manually, the process goes on normally but when the automated tools are used, the tests that have to be carried out are initiated during the same process through which the build is generated. 

Smoke tests have 2 types as mentioned below:

1. Unit tests: Smoke tests under this category are known to exercise the sub routines, object methods and individual functions and so on.
2. Functional tests: These types of smoke tests are known to exercise the complete program along with various inputs.

Both the above mentioned type of smoke testing tools together make up a third party product that falls out of the compiler suite. 

A scripted series of program inputs form a function test and some may also have an automated mechanism. On the other hand the unit tests may be formed out of the separate functions that lie within the code. They can even be a driver layer that might be linked to the code. The smoke testing in software can be compared to the smoke testing in hard wares. 

What are different shortcomings of test driven development?

The test driven development though touching a new high is not free of any drawbacks or short comings! It does have some short comings like any other software development process. 

The test driven development as we all know was considered to be somewhat similar to the test – first programming concepts of an agile software development process popularly known as the extreme programming or XP.

Because of all this, the test driven development methodology suffered a whole lot of criticism and so many of its short comings were discovered. 

Even after the test driven development process got its own individual standing in the line of the software development processes, the critics did not stop criticizing it! What were those short comings? 

Shortcomings of Test Driven Development

1. It is quite difficult to use the test driven development process in the situations and conditions where the success or failure of the software system, application or program is determined by the full functional tests. For example, it cannot be employed for developing the below mentioned things:

(a)    User interfaces

(b)   Programs that involve a data base in their working

(c)    Programs or applications depending up on some specific network configurations.

2. The software developers and programmers are encouraged to keep minimum possible amount of source code in to the software modules in the test driven development. On the other hand they are also encouraged to maximize the logic that lies in the library code which is testable. It encourages the use of the mock objects and fakes for the representation of the outside world.

3   3. The test driven development calls for an extensive need of the management support which is quite vital. The management may get a feeling of the wastage of the writing test cases since the entire organization is not in to the believing that the software product can be improved by the test driven development.

     

     4. The software developer who writes the code for the tests is the same one who is also assigned with the duty of the creation of the automated unit tests in the test driven development. Therefore a possibility that the same blind spot might be present in both the tests is induced which potentially endangers the stability of the software system or application. Both the produced test and code will be wrong!

    5. In test driven development process a false sense of security might be induced by a higher number of passing tests. This in turn will result in less number of additional software testing activities like compliance testing and integration testing.

     6. The tests created for the test driven development system themselves form a part of the maintenance over head of the software project. The tests which have been produced badly may include hard coded error strings which may make the whole test prone to failure are quite expensive when it comes to their maintenance. Such tests are typically fragile in nature.

    7. With the test driven development one risk is always there which comes from the ignorance of the regularly generated false failures. This causes the real failure also to be ignored and thus preventing its detection. Several methods have been developed to create tests which require low and easy maintenance. Creation of such test cases is considered to be a goal of the code refactoring phase of the development cycle.

     8. If you are following the test driven development, then it would be difficult for you to reproduce the level of coverage and testing detail achieved during the repeating test driven development cycles. Deleting those original tests can lead to undetectable holes in the test coverage. 

Explain Test-Driven Development Cycle?

Test driven development or TDD is considered to one of the most effective as well as efficient software development methodology or process that is often cited under the category of the agile software development processes.

The term “test driven development” is self justifying as one make out from the term itself that it is driven by the tests. Actually, the test driven development process is wholly based up on the repetition process of the several development cycles that are shorter than the usual development cycles. 

This whole article is dedicated to the discussion regarding the test driven development cycle. 

What are the steps in TDD process?

Test driven development process involves the below mentioned steps:

1. First step involves the creation of an automatic test case that is failing and defines a new function or some desired improvement in the code.

2. Second step involves the production of code which can pass the test.

3. Third and the final step involves the re-factoring of the new code in order to meet the prescribed standards.

This development strategy or process was introduced in the year of 2003 by Kent beck. The first programming concepts of the extreme programming or XP are considered to be related to the concepts of the test driven development to some extent.

But, nowadays the test driven development has been observed to be an individual development methodology with its own rules and independent procedures. The test driven development process has proved to be successful in improving and debugging legacy code that has been developed using the older development techniques. 

We all know that every development process has its own requirements so here in this the requirements are the automated unit tests that provide a definition of the code requirements and create the associated code themselves. 

Test Driven Development Cycle

Now let us describe the test driven development cycle in detail and sequence:

1. Adding of a test: 

- In test driven development, for every feature to be added, first a test is written that is inevitably expected to fail since it is written before the actual implementation of the features. 

- If the test does not fail, then there are two probabilities: the test is either wrongly formulated or the feature for which the test has been created already exists. 

- The test should be written with utmost understanding of the specifications and requirements which can be achieved from the use cases and user stories. 

- An already existing test can also be modified.

- Writing unit tests before the implementation of the feature helps the software developer or program focus up on the requirements before the actual code is written. 

- This feature of the test driven development differentiates it from the others and leaves a subtle and important effect.

2. Execution of all the tests and check if they fail: 

- This step involves the validation of the test harnesses for their proper working.

- This is done to ensure that no test passes mistakenly without requirement of new code. 

- The test itself is also tested but in the negative so that all the possibilities of passing of the new test are ruled out making it worthless.

3. Production of code: 

- This step involves the production of code by virtue of which the test will pass.

- The code even if its no perfect is accepted since later it can be improved.

4. Execution of the automated tests: 

After all the tests have passed, the developer can be confident that the code is perfect.

5. Refactorization of the code: 

This involves clean up drive of the code and the tests can be re- executed in order to ensure that the existing code is not being damaged.

6. Repetition: 

This involves repetitions of the whole development cycle in order to improve functionality. 

How can we reduce the risk by using a test plan?

A test plan apart from just serving the purpose of a guide for the software testing life cycle also plays a great role in the assessment of the risks associated with the development of that particular software system or application and also provides the alternatives or builds for overcoming those factors which are the root cause of the risk.

The preparation of the test plan must be based on all the risks identified during the process of risk assessment. This article is focussed up on the relation that exists between the risk and the test plan and how a risk based test plan can help reducing the overall risk.

How a risk based test plan reduce the overall risk?

- Such a test plan is effective only when a test oriented risk analysis is carried out during the software system or application development life cycle.

- With the advancing and sophisticated technology the complexity of the software systems and applications is also increasing and so does it lengthens the testing process which is quite exhaustive.

- The software testing methodologies therefore should be quite selective and should also be chosen keeping in mid the time limit and the budget of the project.

- It is often stressed by many testers that the testing should be based on the risk which is not possible until and unless the testers are well equipped with the knowledge of the risk.

- It is a wise decision of concentrating the testing more on the area which is at higher risk compared to other parts of the software system or application.

- Many researchers have made a rigorous research on the subject of risk based testing and have stated that a software system or application requires apart from the understanding of software testing, the knowledge of risk and its analysis also.

Types of Risks
There are two types of risks namely:

1. Forward Risks
These are the risks associated with the operation of the system and one of the major cause of the software failure.

2. Backward Risks
These are the risks associated with the development issues like those mentioned below:
(a) Inappropriate design
(b) Casual programming
(c) Incorrect specifications
(d) Inadequate management

Risk is thought of as a function of two components as described below:

1. The probability of occurrence of an undesirable event that is defined and
2. The degree of the severity of the consequences if the event of the system failure does occur.

In most of the cases, the consequences following the failure of the software system are related to the purpose of the software and therefore reducing the risk is not always an option.

Thus, this leads us to the conclusion that the risk must be reduced by reducing the probability of the failure of the software system which in turn can be achieved only with an efficient test plan.

Now you must be wondering can this actually happen? Yes of course.

- The software testing reduces the risks by digging out many of the bugs.

- But, the actual risk reduction is based up on the implementation of the corrected code and functions.

- The failure of software system is not systematic and hence cannot be predicted by just checking out the history.

- So for the cases like these, only the estimation of the potential consequences of the failure works via the risk based testing that acts as a single factor analysis in
such cases.

- For some it may seem like a trivial process but, it is not so and calls for a thorough examination of the system failure.

- The single factor analysis though does not produce a very correct estimate; it does help the testers in focussing their testing on the code that is buggier than the other units.

What is the entry and exit criterion for regression testing?

Regression testing is a very common software testing methodology and its importance is not hidden from us. Regression testing forms a part of software testing life cycle of every software system or application and project is finalised before running it at least once under the regression testing.

Like the other software testing methodologies the regression has also defined some entry and exit criteria for itself that a software system or application needs to fulfill satisfactorily to undergo regression testing.

But first we will state a brief discussion regarding the regression testing since then it will be easy for us to recognize the entry and exit criteria for the regression testing.

About Regression Testing

- Regression testing is just like the validation testing and is aimed at providing a repeatable and consistent validation of all the changes that have been made to the software system or application under its development or after its completion or after being modified.

- There are chances that at the fixation of a defect new faults and errors might be introduced in to the code of the software system or application that may cause further problems in the functioning of the software system or application.

- An uncertainty is introduced up to some level regarding the ability of the software system or application to make repetition of everything that went right till the encounter of the point of failure.

- To put it simply we can say that the regression testing is nothing but the retesting of the whole software system or application or a selected part of it that has underwent some changes or has been modified for assuring that the encountered fault does not re- occur and none of the previously properly working components of the system like features and functions do not fail as the affect of the introduced modifications.

How to conduct regression testing?

There are many options for conducting regression testing.

- It can either be conducted at the end of the development process of the software system or application.
- It can also be carried out in parallel with the substantial completion of the other software testing methodologies in different phases of the software testing life cycle.

Importance of Regression Testing

- In general, the regression testing is thought of as a quality check tool which controls the quality of the software system or application in regard to the changes made to that particular software system or application and ensures that it does not affects the working of the other previously working components.

- One extremely important point to be noted is that the regression testing is not about testing whether the discovered bugs and errors have been fixed or not but it is all about testing the software system or application up to the point at which the system is not affected by the changes made to fix the bugs.

Entry and Exit criterion for Regression testing

Now we list some of the entry criteria that an application needs to satisfy for undergoing regression testing:
1. The documentation of the defect or the bug is ready and the defect or the bug is repetitive.
2. For the purpose of the identification and tracking of the regression testing efforts, a defect tracking record or a change control has been opened.
3. The creation, review and approval of the tests that are specific to the defect have been done.

There is an only one exit criterion for the regression testing which is that the software system or application should not show any negative result i.e., malfunctioning of any component that was previously working alright before any new changes were introduced to the software system or application for fixing the bug.

What are three main purposes of software testing?

It is a world wide established fact that the software testing has proved all the way very effective in improving the satisfaction of the clients and customers by delivering them a software product that is quite free of defects, errors and bugs.

Only the stable, error free and reliable software systems and applications are accepted in to the business. There is no place for the unstable and buggy software systems.

WHAT HAPPENS IF TESTING IS NOT DONE PROPERLY?

- There is a substantial increase in the chances of the failure of a software system or application if it is not tested or tested only up to a small extent.

- This in turn increases the rates of wastage of time as well as one’s precious efforts.

- The rework and rewrites and their maintenance cost the organization so much and also annoys the customers and clients.

- If a software system fails, it only gives an indication towards the inadequacy of the efficiency of the system and a lack of testing.

- The failure of the software systems or applications can cost too much in certain cases where very sensitive and critical matters are dependent on the working of the software.

- Software testing has been scientifically defined as a process that deals with the verification and validation of the software system or application.

- It ensures whether or not the system meets all the requirements specifications that have been used all along its development cycle to guide its designing and makes sure that the software system or application is working as expected by the makers.

THREE MAIN PURPOSES OF SOFTWARE TESTING

Three main purposes of the software testing have been laid down as mentioned below:

1. Verification
This purpose deals with the verification of the development process of the software system or application and ensures that the software is being developed or built in the right way.

2. Validation
This is all about making sure that the right software artefact is being produced.

3. Defect finding verification
This is for the purpose of ensuring that the software system or application that is being built, meets the technical specifications and requirements stated for it by the customer or the clients. It also checks out for the variation of the defect range between the actual outcome and the expected outcome.

BENEFITS OF SOFTWARE TESTING

- Software testing has very well taken up the responsibility for ensuring that the software system or application meets the business requirements as specified for it and thus whether or not works as expected.

- The compatibility of the software system or application with a range of different platforms is also evaluated and the performance rating is given.

- Whether the software system or application should be released or not, is determined on the basis of the results of the software testing.

- Software testing has a whole lot of benefits, the greatest ones being the saving of the time and efforts which are indeed very priceless commodities.

- Defects, bugs and errors if detected earlier eat up less time and money and reduce development time and also if the application or system is kept error free in the beginning itself, then less problems will be faced in the future development phases.

Software failures as mentioned above can give rise to life threatening issues to the:

- People (for example, control system failure resulting in a plane crash, life support system failure in hospitals causing deaths)

- Environment (for example, a software failure causes the harmful radiations and chemicals to be released in to the environment and thus affecting the whole eco system)

- Companies (for example, some times the software might do the bill incorrectly due to some discrepancy in it causing the company a great money loss) and so on.

What is meant by severity of a bug? What are different types of severity?

We all know what a software bug is! It is a flaw, error or mistake in the software system or application that can cause it to crash or fail. Pretty much simple!
But very few of us are actually aware about the severity of a bug i.e., how much destruction it can cause to a software system or application.

- Bugs are of course results of the mistakes made by the software programmers and developers while coding the software program.
- Sometimes incorrect compilation of the source code by the program can also cause bugs.
- A buggy program is very hard to clean.
- Bugs can have a chain reaction also i.e., one bug giving rise to another and that in turn giving rise to one more bug and so on.
- Each bug has its own level of severity that it causes to the software system or application.
- While some bugs can work out total destruction of the program, there are some bugs that do not even come in to detection.
- Some bugs can cause the program to go out of service.
- In contrast to these harmful bugs, there are other bugs which are useful such as security bugs.

WHAT IS SEVERITY OF A BUG & ITS TYPES

-"Severity can be thought of as a measure of the harm that can be caused by a bug."
- Severity is an indication of how bad or harmful a bug is.
- The higher the severity of a bug, the more priority it seeks.
- Severity of the bugs of software can sometimes be used as a measure of its overall quality.
- Severity plays a major role in deciding the priority of fixing the bug.
- It is important that the severity of the bugs is assigned in a way that is logical and easy to understand.

There are several criteria depending on which the severity of a bug is measured. Below mentioned is one of the most commonly used ranking scheme for measuring severity of bugs:

1.Severity 1 Bugs
bugs coming under this category cease the meaningful operations that are being operated by a software program or application.

2.Severity 2 Bugs
Bugs coming under this category cause the failure of the software features and functionalities. But, still the application continues to run.

3.Severity 3 Bugs
Bugs coming under this category can cause the software system or application to generate unexpected results and behave abnormally. These bugs are responsible for inconsistency of the software system.

4.Severity 4 Bugs
Bugs coming under these categories basically affect the design of a software system pr application.

COMPONENTS OF SEVERITY
Severity has two main components namely the following:

1. Impact
- It is a measure of the disruption that is caused to the users when they encounter a bug while working.
- There is a certain level to which there is an interference with the user performing a task.
- Even the impact is classified in to various levels.

2. Visibility
- It is the measure of the probability of encountering the bug in future or we can say that it is measure of the closeness of a bug to the execution path.
- It is the frequency of the occurrence of a bug.

The severity is calculated as the product of both the impact as well as visibility. A measure of perceived quality and usefulness of the software product is given by the severity. Therefore it would not be wrong to say that the severity provides an overall measure of the quality of the software system or application.