Learn Software Development » Software

Explain the waterfall model of software testing. What are its advantages and disadvantages?

ashish — Sun, 20 May 2012 19:17:40 +0000

There are a number of models that have been developed for the software testing like the waterfall model, spiral model, agile model and so on. The discussion in this article is limited to the waterfall model of software testing along with its advantages and disadvantages. You must have seen a waterfall and how the water flows in it ! In a similar way to the water fall, this software development model progresses and so has been named as the water fall model of software development. Like a waterfall, it follows some sequence of flow and therefore is considered to be a sequential design process which is generally used in the software development life cycle or the SDLC which require the flow of the development to be downwards like in a water fall – progressive and steady through different phases like those mentioned below:
1. Conception
2. Initiation
3. Analysis
4. Design
5. Construction
6. Testing
7. Production
8. Implementation
9. Maintenance etc.
This model has a flow similar to that of a real water fall. Now below we list out all the phases of the software development process that implements a water fall model:
1. Requirements
2. Specifications
3. Architecture
4. Design
5. Implementation
6. Testing
7. Deployment, and lastly
8. Maintenance
Now below we are mentioning some of the common methodologies apart from the water fall model of software development that too are used in the software development process:
1. Agile
2. Clean room
3. Iterative
4. RAD or rapid application development
5. RUP or rational unified process
6. Spiral
7. XP
8. Lean
9. Scrum
10. V model
11. TDD or test driven development
The below mentioned tools are used for the implementation of the water fall model of software development:
1. Compiler
2. Debugger
3. Profiler
4. IDE or integrated development environment
5. GUI or graphical user interface designer.

When a water fall model of software development has been implemented, the software system or application under development can move to the higher stages only if the preceding one has been successfully completed and all the issues discovered in the preceding stage have been identified and fixed. So many types of water fall models have been developed with different ways and order of implementation of the common steps. The most popular waterfall model of software development is that of the “Royce’s final model”. Other types of the waterfall model have been derived from this model only. Now we list some advantages and disadvantages of the waterfall model of software development:

Advantages:
1. Waterfall model insists on spending time on the early stages of development since it open ups the option of greater economy at the succeeding stages regarding the money, efforts and time.
2. It employs the idea of fixing the bug earlier with spending less efforts and money rather than spending huge amounts of time and efforts later.
3. It employs the idea of the big design upfront model.
4. It makes sure that the preceding stages have been perfectly completed before the development moves on to the next stage.
5. It involves the identification of all the requirements and resources before the beginning of the development process so the development in progress won’t fall short of resources and thus saves the potential wastage of the efforts.

Disadvantages:
1. Most of the times it has been considered as a bad idea to be followed in the practical implementation since it is not possible for any project to complete the preceding level 100 percent before moving on to the next one.
2. The designers stay unaware of the future implementation difficulties while designing a software product that has not been implemented.

Rapid Development: Taming Wild Software Schedules	The Mythical Man-Month	The Waterfall Method (Kindle)

What happens when your product is not stable close to release date ? – Part 1

ashish — Mon, 07 May 2012 20:19:36 +0000

This is probably one of the most controversial topics in software development. You have a software on which the company has dedicated an insane amount of effort on, the software contributes a significant percentage (upwards of 25%) of the revenue of the company and it is a well know software. This could be MS-Office, could be Photoshop, could be the latest release of Apple OS, or could be other similar software that are very well known. Now, these software have a known release date, and given the power and money riding on these software, it is extremely important that the software makes its release date. The problems if the date gets delayed are many: The company suffers at the hands of the market and analysts, its reputation takes a dip, revenue already slotted for the current quarter has to be scaled back, and somebody in the chain of management has to take a hit.
However, what happens when you reach a scenario where the software is not yet fully ready ? There are still bugs in the software, not everything is fully stable, and quality teams are hesitant to release the software. In some cases, the apprehension of the teams are unfounded, and the software is good enough to release and earn accolades in the market. However, the difficulty comes when the software is not yet ready, when the apprehensions of the quality teams is correct. In such a case, if the software were to be released, things could get problematic for the company real quick. A release that has suspect quality gets pilloried real fast; with more social media and more active consumers, items such as reduced ratings on Amazon and a lot of comments of poor quality on Facebook / twitter can cause huge damage to the reputation of the company and will most certainly lead to forced removal of people in the company.
So the challenge is to determine which is the current state. This is probably one of the most important decisions that the senior management team of the group has to decide, and it is a very hard decision. The chance of making a mistake in this area is incredible, and if there are obvious mistakes, then it is fairly career limiting for the people who did make the mistake. And you certainly don’t want to be the senior management person who released a product that was of bad quality, and at the same time you don’t want to be known as the person who was unable to take a realistic call of whether the product quality was good or bad. The previous sentence was just a confirmation about the difficult position that management is in when trying to evaluate the current position.

Read this book for some more advice in this area: Judgement Calls: Making Good Decisions in Difficult Situations –

In the next part (Part 2), I will talk more about this decision, the factors that guide it, and what all to do ..

An explanation of the concepts of static analysis testing

ashish — Thu, 15 Mar 2012 16:51:37 +0000

A software system or application indeed consists of many bugs and errors which cannot be rooted out using just one software testing methodology. Each aspect of a software system is tested by a uniquely defined testing methodology for it. As a result, many software testing and analysis methodologies have been developed and static analysis is one of them. This article deals with the concepts of the static analysis. Static code analysis is also known as static program analysis or SPA. It is somewhat similar to the static testing. Like static testing, static program analysis is a software testing methodology that is carried out on the software, but no actual execution takes place. The counterpart of static analysis is dynamic analysis in which the programs are executed and then tested. The static analysis can be carried out either on the source code or on the object code as the case may be.
The process of static analysis is often automated and rarely carried out manually. When carried out manually it is called code review or program comprehension. The levels on which the static program analysis is carried out may also vary depending up on the sophistication of the testing strategy i.e., whether the testing is to involve only the tests for the behavior of individual statements or it is to be carried out on the complete source code of the software program. The information deduced from the outcome of the static analysis can tell the programmers about the possible errors and flaws in the coding of the program. Nowadays, reverse engineering and software metrics are being considered as the different forms of the static program analysis.
This is so because in many of the testing strategies, the testers often deploy these three techniques i.e., software metrics, reverse engineering and static analysis together for the creation and testing of embedded software systems. These three testing methodologies are also used together for defining the objectives of the software quality. Static program analysis is being used commercially for the verification of the properties of the software system or application and these are the software that are implemented in the safety critical computer systems. From all this we can conclude that the static analysis is aimed at finding the code with potential vulnerabilities. Some of the organizations make use of this static program analysis for making improvements in the quality of their complex and highly sophisticated software systems and applications.
Such complex and sophisticated softwares include nuclear software and medical software. Another form of static program analysis is the SAST or static application security testing and it is employed in the industry of the application security. Certain formal methods have been defined to assist the static analysis. Formal methods are purely mathematical in nature and include techniques like axiomatic semantics, denotational semantics, abstract interpretation and operational semantics. Below we are mentioning some of the implementation techniques for formal static program analysis:
1. Data flow analysis: This technique is lattice based and is used for gathering the information regarding the set of values that is possible.
2. Model checking: This technique takes into consideration the software systems that either have a finite state or there is a possibility that they can be reduced to the finite state by the process of abstraction.
3. Abstract interpretation: This method is being used for the analysis of the effects that every statement has.
Static program analysis can also be thought of as a methodology for debugging the program. Static program analysis provides a better understanding of the software system or application.

Software Verification and Analysis	Static Analysis of Software	Software Testing and Analysis

What is meant by branch coverage or decision coverage? How is it calculated?

ashish — Thu, 23 Feb 2012 20:17:50 +0000

Code Coverage is a very important aspect when it comes to testing, although a number of people may not even have heard about it. It should not be ignored, instead attempts should be made to incorporate it as part of processes. There are practical difficulties – it requires a great deal of effort to understand it and implement it properly, especially when you want your team to implement it. Here we have tried our best to keep the concepts as simple as possible so that you can atleast understand the basics of code coverage.
Code coverage is a measure to determine the extent to which you have tested a certain piece of code of your software program which is under testing, and the higher the coverage, the better. In this article we are going to discuss about one particular type of code coverage called “branch coverage” and how it is calculated. If we talk about Code coverage, it is used as a method to complement the unit testing, since the code coverage also tells us how much code remains to be tested and unit testing just tells us that about the performance of the code that has been tested. The target of a tester should be to achieve 100 percent code coverage (although it gets difficult to get to 100%).
In a software development cycle the code coverage is measured in the terms of statements and branches that are to be tested. One point you should always keep in mind is that achieving 100 percent code coverage does not means that your software system or application is free of bugs and error. It still might be having many critical bugs. Code coverage just gives the extent of how much code has been tested and does not eradicate the bugs and errors. Bugs and errors still persist. Code coverage might deceive you by giving you an illusion of false sense of security. You are wrong if you think that 100 percent code coverage achievement is enough to give you a solid and bug free product.
Branch coverage is a means to just enough give you an indication about the big visible errors and bugs and not about the hidden ones. It helps in discovering bugs and errors which lie unexplored and unexposed in the unexecuted part of the program code. Branch coverage has got another drawback; it is not effective in digging out bugs and errors that are hidden in the interactions between the decisions and their structures. For your information, path coverage is mostly preferred since it is very comprehensive and more robust as compared to the branch coverage technique. Being more robust it helps discover errors and bugs within a short span of time. It is a known fact that branch is the result of a decision.
So to put it simply we can say that the branch coverage gives the measure of the extent to which the outcomes of the decisions in a particular piece of executable code of a program have been tested. Though being less effective than the statement coverage, it is far much better than the simple statement coverage. Now, calculating the number of branches is pretty easy. In a program; for making decisions either Boolean decisions are used or switches are implemented. Boolean decisions, as we all know can have only 2 outcomes i.e., either true or false. The switches result in only one value for each particular case. It is not surprising that the number of branches equals the number of the outcomes of the decisions in a certain piece of code. Don’t forget to add the one branch for every straight line code. The branch coverage for discovering all the errors and bugs doesn’t works and carrying out exhaustive testing on each and every branch is not recommended.

Lessons Learned in Software Testing	Software Testing (2nd Edition)	Testing Computer Software, 2nd Edition

Different types of software errors and handling them properly

ashish — Tue, 14 Feb 2012 18:58:14 +0000

Errors are a major headache to software programmers, developers as well as testers. They cause the whole software system or application to falter, produce unexpected results and cause the software to behave abnormally. Some errors cause more harm while some cause less, some of them are easy to discover whereas some are hideous and cause huge frustration to developers and testers. Some errors are as active and disruptive like a volcano and others are dormant. Every software system or application suffers from many errors, and it is now seen as impossible to remove all the errors from a software system.
Therefore error handling becomes an important factor in deciding the success of a program. Error handling is the way a program is built to handle the errors that disturb its functioning.
- The error handling procedure should be very strong and smart.
- Error handling requires a lot decision making.
- The error handling process, like other processes, is also a victim of defects and can sometimes not work properly.
The main steps involved in an Error handling process are detection, anticipation and resolution of the errors that occur during the execution of the software program or application. Some applications even employ programs called “error handlers” developed specifically for handling the errors. A software system or application is said to have good error handling capabilities if it is able to recover from errors without causing the whole program to terminate, or if it is not able to handle that error, properly terminate the program without causing any data loss. Such forceful termination is nothing but an error handling mechanism.
The basic factors causing the run time errors are invalid input data and adverse function parameters.
Lack of memory is another defect causing factor.
A Software application comprises of various small programs. These programs may conflict with each other during the run time. Similarly web applications also experience errors due to electrical noise and malware or other undue pressure on the server.
A software system or application can overcome these errors by its error handling process. Thus we can define the error handling defects as the defects that reduce the efficiency of the error handling process.
On the initiation of the error handling process, the discrepancy between the expected behavior and actual behavior is identified. Whenever there is some discrepancy in the behavior of the program, a defect is created. The test script that was being executed at the time of encounter of the defect is tested. This process is called defect creation. After this, the discovered defect is verified i.e., whether or not the defect is valid. A severity level is assigned to the defect. This severity level indicates the impact and visibility of the defect on the program. The defect can cause the core functionality to go out of order or stop working. It can affect the operational environment. Such defects prevent the user from accessing the features and functionalities of the software system or application.
Incorrect navigation links are also a defect.
According to the level of severity of the encountered errors and the problems they can cause, they are assigned priorities. This process is defect prioritization. Several priority codes have been defined. For example, there are some defects that do not even allow the testing to take place. Defects causing such errors are given the highest priority. The defect is once again confirmed and this process is called defect confirmation. After the defect confirmation the defect is analyzed, the affected code is redesigned, developed and tested again for any shortcomings. This process following the defect confirmation is called defect resolution. The defects after being resolved are once again reviewed by the developer and certain test scripts are run to confirm that the defect has been resolved. After the verification the defect is closed.

Lessons Learned in Software Testing	Software Testing: An ISTQB-ISEB Foundation Guide	Software Testing (2nd Edition)