Software Development Life Cycle (SDLC)

Visit Quality Testing

Introduction

Software Development Life Cycle (SDLC) is a methodology that is typically used to develop, maintain and replace information systems for improving the quality of the software design and development process. The typical phases are analysis, estimation, design, development, integration and testing and implementation. The success of software largely depends on proper analysis, estimation, design and testing before the same is implemented. This article discusses SDLC in detail and provides guidance for building successful software.

The Software Development Life Cycle (SDLC) steps

The Software Development Life Cycle is the cycle in which the business analysts, the software developers, the database designers and/or the database developers, the QA developers and end users collaborate to build the application software. Basically, it involves designing the application from scratch, documenting everything, adding the improvements and fixing the bugs that occur in the SDLC. It is the lifecycle of Software from concept to obsolescence.

A quality software system is based on the following three principles:

· Modeling of the software development process (process)


· Modeling of the measurement of product (product)


· Modeling of the management and human interactions (people)

The software development life cycle (SDLC) may be divided into the following steps:

1. Requests from customers/original idea


2. Creation of feature lists based on item 1


3. Technical design of features based on item 2


4. Software design and time evaluation based on item 3


5. Code implementation based on item 4


6. Software Testing


7. Beta release/ bug fixes


8. Final release


The following section discusses each of these steps briefly.

Requests from customers/original idea

All the information relevant to the system and its scenarios, the occurrence and the behavior is gathered in this phase from the customer or the client who can provide the valuable information. These are basically raw facts or materials collected from the customer’s point of view by his or her observation over a period of time.

Creation of feature lists based on item 1

The information collected from the discussions mentioned on item1 is considered for a refinery process that varies from company-to-company depending on the standardization and the methodology that they do adopt. It lists all the details of the proposed items in an organized manner.

Technical design of features based on item 2

Here the technical aspects come into the picture and the designing of those aspects in terms of computer terminology. It involves the designing of the architecture and the sources that influence them like UML, OOAD, etc.

Software design and time evaluation, based on item 3

The software design phase in the software development life cycle is produced from the results of the requirements phase. It contains detailed design of the software in terms of the interfaces that it will provide and also the relevant functionalities that have to be implemented. It also involves the designing of the database. In this phase it is equally important to estimate the duration required based on the number of resources available in hand.

Code implementation, based on item 4

The coding phase involves writing the source code based on the required functionality by adhering the coding standards, code optimization, etc.

Software Testing

After developing the software it is important to ensure that the functioning of it is perfect. Software testing involves a mechanism that is used to report the bugs/undesired results that may occur in the SDLC.

Beta release/ bug fixes

The newly developed software will be released to undergo the tests for issues like the performance and its behavior under different circumstances. The bugs that occurred earlier in the cycle are rectified.

The Final release

After the clearance of the bugs reported during the beta release, the software is now ready to be released and delivered to the customer

TESTING PRINCIPLES. . . .

In the premise of software testing, there are few guidelines or testing principles, which appears to be quite obvious but often overlooked. Let’s discuss these testing principles. 

1.A necessary part of the test case is the definition of the output of expected data 

While designing test cases, it is quite important to describe the output or expected result on the basis of given input, along with input data execution environment is also quite important to analyze output data. As it is said, that testing is destructive process and testers tries to break the code by giving expected or un-expected input to the system but still it is human psychology that it still desires to see the correct result, So if proper output is not defined then one can consider un desired output as desired output of the system. 

2.A programmer should avoid testing his own program 

Software design and development is a constructive job and Software testing on the other hand, breaks the code, so it is not possible for the software developer to change his mind set overnight from constructive activity to destructive testing activity, because he can’t bring himself into frame of mind of exposing errors.

Secondly, along with psychological problem, it can be possible that programmer is not fully aware about the software specification or misunderstood the specification. If it is the case, that programmer will have the same misunderstanding while testing his own program.

This does not implies that programmer cannot test his own program; rather quality of software would be great if programmer tests his code by executing test cases, but testing is more effective and successful if performed by some other party. 

3.Test cases should be written for valid and expected, invalid and unexpected input conditions 

It is common practice that while testing, testers concentrate on valid and expected input conditions, and neglect the invalid and unexpected input conditions. But it is observed that most of errors in production come from the unusual and unexpected data input. And frequency of errors is great when testing with invalid and unexpected input conditions. 

4.Examining a program 

Examining a program to see if it does not do what it is supposed to do is only half of the battle; we also have to see if program does what it is not supposed to do. For example if Program generates ticket in ticket reservation system, it should be make sure that it does not generate duplicate ticker or ticker without charging fare amount. 

5.Avoid throwing test cases

Do not throw test cases until the program life has ended, when we create test cases to test a specific functionality of a module, effort is there to create test cases to cater all scenarios. But after testing if the test cases are thrown away, it would create difficulty when we have to re-test the program it mean the effort we put for creating test cases will be lost so maintaining the repository of test cases is a good practice. 

I read these testing principles from the "The Art Of Software Testing" by Glenford Myer 

WHAT IS THE ROLE OF "A TESTER". .?. .

A tester is a person who tries to find out all possible errors/bugs in the system with the help of various inputs to it. A tester plays an important part in finding out the problems with system and helps in improving its quality.

If you could find all the bugs and fix them all, your system becomes more and more reliable.

A tester has to understand the limits, which can make the system break and work abruptly. The more number of VALID BUGS tester finds out, the better tester he/she is!

WHY THERE IS A NEED OF INDEPENDENT/SEPARATE TESTING. .?. .

This is a right question because, prior to the concept of TESTING software as a ‘Testing Project’, the testing process existed, but the developer(s) did that at the time of development.

But you must know the fact that, if you make something, you hardly feel that there can be something wrong with what you have developed. It's a common trait of human nature, we feel that there is no problem in our designed system as we have developed it and it is perfectly functional and fully working. So the hidden bugs or errors or problems of the system remain hidden and they raise their head when the system goes into production.

On the other hand, its a fact that, when one person starts checking something which is made by some other person, there are 99% chances that checker/observer will find some problem with the system (even if the problem is with some spelling that by mistake has been written in wrong way.). Really weird, isn't it? But that’s a truth!

Even though its wrong in terms of human behavior, this thing has been used for the benefit of software projects (or you may say, any type of project). When you develop something, you give it to get checked (TEST) and to find out any problem, which never aroused while development of the system. Because, after all, if you could minimize the problems with the system you developed, it’s beneficial for yourself. Your client will be happy if your system works without any problem and will generate more revenues for you. 

BINGO, it's really great, isn't it? That's why we need testing!

WHY WE GO FOR TESTING. .?. .

Well, while making food, its OK to have something extra, people might understand and eat the things you made and may well appreciate your work. But this isn't the case with Software Project Development. If you fail to deliver a reliable, good and problem free software solution, you fail in your project and probably you may loose your client. This can get even worse!

So in order to make it sure, that you provide your client a proper software solution, you go for TESTING. You check out if there is any problem, any error in the system, which can make software unusable by the client. You make software testers test the system and help in finding out the bugs in the system to fix them on time. You find out the problems and fix them and again try to find out all the potential problems.

WHAT IS TESTING. .?. .

Software Testing can be defined as: Testing is an activity that helps in finding out bugs/defects/errors in a software system under development, in order to provide a bug free and reliable system/solution to the customer.

In other words, you can consider an example as: suppose you are a good cook and are expecting some guests at dinner. You start making dinner; you make few very delicious dishes (off-course, those which you already know how to make). And finally, when you are about to finish making the dishes, you ask someone (or you yourself) to check if everything is fine and there is no extra salt/chili/anything, which if is not in balance, can ruin your evening (This is what called 'TESTING').

This procedure you follow in order to make it sure that you do not serve your guests something that is not tasty! Otherwise your collar will go down and you will regret over your failure!

WHY GOOD BUG REPORT. .?. .

If your bug report is effective, chances are higher that it will get fixed. So fixing a bug depends on how effectively you report it. Reporting a bug is nothing but a skill and I will tell you how to achieve this skill.

“The point of writing problem report(bug report) is to get bugs fixed” – By Cem Kaner. If tester is not reporting bug correctly, programmer will most likely reject this bug stating as irreproducible. This can hurt testers moral and some time ego also. (I suggest do not keep any type of ego. Ego’s like “I have reported bug correctly”, “I can reproduce it”, “Why he/she has rejected the bug?”, “It’s not my fault” etc...)

Why good Bug report?

If your bug report is effective, chances are higher that it will get fixed. So fixing a bug depends on how effectively you report it. Reporting a bug is nothing but a skill and I will tell you how to achieve this skill.

“The point of writing problem report(bug report) is to get bugs fixed” – By Cem Kaner. If tester is not reporting bug correctly, programmer will most likely reject this bug stating as irreproducible. This can hurt testers moral and some time ego also. (I suggest do not keep any type of ego. Ego’s like “I have reported bug correctly”, “I can reproduce it”, “Why he/she has rejected the bug?”, “It’s not my fault” etc...)

What are the qualities of a good software bug report?

Anyone can write a bug report. But not everyone can write a effective bug report. You should be able to distinguish between average bug report and a good bug report. How to distinguish a good or bad bug report? It’s simple; apply following characteristics and techniques to report a bug.

1) Having clearly specified bug number:
Always assign a unique number to each bug report. This will help to identify the bug record. If you are using any automated bug-reporting tool then this unique number will be generated automatically each time you report the bug. Note the number and brief description of each bug you reported.

2) Reproducible:
If your bug is not reproducible it will never get fixed. You should clearly mention the steps to reproduce the bug. Do not assume or skip any reproducing step. Step by step described bug problem is easy to reproduce and fix.

3) Be Specific:
Do not write an essay about the problem. Be Specific and to the point. Try to summarize the problem in minimum words yet in effective way. Do not combine multiple problems even they seem to be similar. Write different reports for each problem.

How to Report a Bug?

Use following simple Bug report template:
This is a simple bug report format. It may vary on the bug report tool you are using. If you are writing bug report manually then some fields need to specifically mention like Bug number which should be assigned manually.

Reporter: Your name and email address.

Product: In which product you found this bug.

Version: The product version if any.

Component: These are the major sub modules of the product.

Platform: Mention the hardware platform where you found this bug. The various platforms like ‘PC’, ‘MAC’, ‘HP’, ‘Sun’ etc.

Operating system: Mention all operating systems where you found the bug. Operating systems like Windows, Linux, UNIX, SunOS, and Mac OS. Mention the different OS versions also if applicable like Windows NT, Windows 2000, and Windows XP etc.

Priority:
When bug should be fixed? Priority is generally set from P1 to P5. P1 as “fix the bug with highest priority” and P5 as” Fix when time permits”.

Severity:
This describes the impact of the bug.
Types of Severity:

• Blocker: No further testing work can be done.
• Critical: Application crash, Loss of data.
• Major: Major loss of function.
• Minor: minor loss of function.
• Trivial: Some UI enhancements.
• Enhancement: Request for new feature or some enhancement in existing one.

Status:
When you are logging the bug in any bug tracking system then by default the bug status is ‘New’.
Later on bug goes through various stages like Fixed, Verified, Reopen, Won’t Fix etc.
Click here to read more about detail bug life cycle.

Assign To: 
If you know which developer is responsible for that particular module in which bug occurred, then you can specify email address of that developer. Else keep it blank this will assign bug to module owner or Manger will assign bug to developer. Possibly add the manager email address in CC list.

URL:
The page url on which bug occurred.

Summary:
A brief summary of the bug mostly in 60 or below words. Make sure your summary is reflecting what the problem is and where it is.

Description:
A detailed description of bug. Use following fields for description field:

• Reproduce steps: Clearly mention the steps to reproduce the bug.
• Expected result: How application should behave on above mentioned steps.
• Actual result: What is the actual result on running above steps i.e. the bug behavior.

These are the important steps in bug report. You can also add the “Report type” as one more field which will describe the bug type.

The report types are typically:
1) Coding error
2) Design error
3) New suggestion
4) Documentation issue
5) Hardware problem

Some Bonus tips to write a good bug report:

1) Report the problem immediately: If you found any bug while testing, do not wait to write detail bug report later. Instead write the bug report immediately. This will ensure a good and reproducible bug report. If you decide to write the bug report later on then chances are high to miss the important steps in your report.

2) Reproduce the bug three times before writing bug report: Your bug should be reproducible. Make sure your steps are robust enough to reproduce the bug without any ambiguity. If your bug is not reproducible every time you can still file a bug mentioning the periodic nature of the bug.

3) Test the same bug occurrence on other similar module:
Sometimes developer use same code for different similar modules. So chances are high that bug in one module can occur in other similar modules as well. Even you can try to find more severe version of the bug you found.

4) Write a good bug summary:
Bug summary will help developers to quickly analyze the bug nature. Poor quality report will unnecessarily increase the development and testing time. Communicate well through your bug report summary. Keep in mind bug summary is used as a reference to search the bug in bug inventory.

5) Read bug report before hitting Submit button:
Read all sentences, wording, steps used in bug report. See if any sentence is creating ambiguity that can lead to misinterpretation. Misleading words or sentences should be avoided in order to have a clear bug report.

6) Do not use Abusive language:
It’s nice that you did a good work and found a bug but do not use this credit for criticizing developer or to attack any individual.

Conclusion:
No doubt that your bug report should be a high quality document. Focus on writing good bug reports, spend some time on this task because this is main communication point between tester, developer and manager. Mangers should make aware to their team that writing a good bug report is primary responsibility of any tester. Your efforts towards writing good bug report will not only save company resources but also create a good relationship between you and developers.

WHY ARE GOOD COMMUNICATION SKILLS SO IMPORTANT. .?. .

A tester's professionalism and competence is perceived and judged based upon how they communicate verbally and in writing. 

As testers, our job is to find bugs so we are constantly the bearers of bad news. If we present this bad news in an ambiguous way or with a bad attitude, the recipient's natural response may be to "shoot the messenger". By having professional and accurate communication skills a tester can easily be viewed as a valuable member of the team and not as a "necessary evil" 

Every day, testers communicate orally. They talk about the bugs they found, describe them, and discuss the urgency to fix them. They also talk about the progress that they are making on the testing and their opinion of the quality and ship-ability of the product. Testers communicate bugs, test cases, test results, status reports and test reports in writing. They also communicate daily by email. See Tips for more insight into the importance of good communication skills.

DEFINITION OF BUG. .?. .

What is a bug?

A bug is an error or defect in the software. A behavior is deemed a bug if the software doesn't perform as required, specified or expected.

Why error or a defect is called a bug?

The legend goes that the first digital computer, ENIAC, was having a malfunction. Lt. Grace Hopper, looking in the hardware components, found a moth trapped in the boards.

"Oh, it's just a bug."

However, The New Hacker's Dictionary [Eric Raymond, Second Edition, MIT Press, (1994)] states that the term was used prior to that event. Even so, the legendary moth is now reputed to be property of the Smithsonian Institute.

HOW IS SOFTWARE MADE. .?. .

In general, here's how software is made: 

• Someone has a good idea (sometimes it's a marketing person, sometimes an engineer), they do some research, & define some requirements (how will it work, what machines will it work on,when will it ship). 
• The engineers work on the detailed design (how it will work behind the scenes and what the user will see), chose the appropriate software language and tools and write the code. 
• The software testers test the product and verify that fixes work correctly. 
• When it's deemed ready by the project team and/or the management team, the product is shipped/released to the customer.

INTRODUCTION TO SOFTWARE TESTING

Before moving further towards introduction to software testing, we need to know a few concepts that will simplify the definition of software testing.

• Error: Error or mistake is a human action that produces wrong or incorrect result. 
• Defect (Bug, Fault): A flaw in the system or a product that can cause the component to fail or misfunction. 
• Failure: It is the variance between the actual and expected result. 
• Risk: Risk is a factor that could result in negativity or a chance of loss or damage. 

Thus Software testing is the process of finding defects/bugs in the system, that occurs due to an error in the application, which could lead to failure of the resultant product and increase in probability of high risk. In short, software testing have different goals and objectives, which often include:

• Finding defects; 
• Gaining confidence in and providing information about the level of quality; 
• Preventing defects.

WHAT IS SOFTWARE TESTING. .?. .

Software testing is the task of trying the software application to see if it works and trying to break it. This is done before the product is shipped/released to customers. Sometimes a tester can rely upon a written specification to explain what the software is supposed to do or how it is supposed to respond to errors. Sometimes the tester will have a written test case to follow that indicates exactly what the tester is supposed to do and what the software should do. More often (in consumer products) none of those exist and a tester must figure out what to test and what the software should do on their own. To do that they use a combination of asking questions of the product manager and engineers, their knowledge of how software and computers work and their intuition based upon their experience. (Please note that the world of testing large systems such as those for the government/defense department/NASA/FAA differ in that they do make the time to precisely define requirements, specifications, designs and test cases.)

How do I start with testing . .?. .

Think twice (or may be more) times before you choose a career. Are you interested in it or do u just want to jump on the bandwagon?

Prerequisite 

You can join a software development company as a tester if you can convince the interviewer 

1. You have a knack for breaking software

2. You are aware of basic Quality concepts and be live in them

3. You want to pursue Testing as a career and not just to try it 

OO Software Testing Issues 

A common way of testing OO software testing-by-poking-around (Binder, 1995). In this case the developer’s goal is to show that the product can do something useful without crashing. Attempts are made to “break” the product. If and when it breaks, the errors are fixed and the product is then deemed “tested”. 

Testing-by-poking-around method of testing OO software is, in my opinion, as unsuccessful as random testing of procedural code or design. It leaves the finding of errors up to a chance. 

Another common problem in OO testing is the idea that since a super class has been tested; any subclasses inheriting from it don’t need to be.

This is not true because by defining a subclass we define a new context for the inherited attributes. Because of interaction between objects, we have to design test cases to test each new context and re-test the super class as well to ensure proper working order of those objects. 

Yet another misconception in OO is that if you do proper analysis and design (using the class interface or specification), you don’t need to test or you can just perform black-box testing only. 

However, function tests only try the “normal” paths or states of the class. In order to test the other paths or states, we need code instrumentation. Also it is often difficult to exercise exception and error handling without examination of the source code.

WHAT DO TESTERS DO ALL DAY?

Well, primarily testers test and write up bug reports. After a new build of software is delivered from engineering, testers verify that old bugs have been fixed. Sometimes they review specs, documents or help text and sometimes they write test cases or write a status report. Try walking through A Day In The Life Of A Tester to see if the daily activities of testing appeal to you.

WHAT QUALITIES DOES A GOOD TESTER HAVE .. ? ..

Some of the qualities that are useful for a software tester to have are:

• Well organized
• Inquisitive or curious
• Quick Learner
• Ability to work with a minimum of direction
• Ability to work with ambiguity (in direction and in the software)
• Ability to mentally piece a concept together without having to have it explained precisely (understand the "gist" of something)
• Self motivated
• Interested in how software works and/or how computers work
• Excellent written and verbal communication skills

WHY WE NEED A TESTER . .? . .

Testing is the most important way of assuring (or controlling) the quality of software. Good practices throughout the development process contribute to the quality of the final product, but only testing can demonstrate that quality has been achieved and identify the problems and the risks that remain.

This is not really the best state of affairs, as testing is by far the costliest method of finding bugs. The cost of a bug found using inspections, walk through, reviews, modelling and proofs is much less than a bug found in testing. These techniques can be performed early, at intermediate stages of development, meaning that fixing a bug entails less rework, less re-checking, and less likelihood of introducing a new fault. 

Testing, on the other hand, entails manufacturing test data and transactions, and running the software on something approaching the live hardware and network infrastructure. It also requires a (nearly) working piece of software, which is usually only available towards the end of a development stage (or development iteration in iterative processes). All this is expensive and time-consuming.

To fix a bug found during a test implies rework, which might go far back into the development cycle - possibly all the way back to the initial requirements. All that rework needs to be re-tested. The cost of fixing bugs increases exponentially at each stage of development. Rework and re-testing are time-consuming and expensive, and fixes are error-prone - studies have shown that each fix has a 50% chance of creating a new defect.

Despite the drawbacks and the available alternatives, software development still relies heavily on testing. Testing was probably the first activity used by programmers to flush out bugs in software before it is made live. It is the most intuitive step to take - write a program, then run it. The persuasive appeal of testing is that it has, at least within the abstract realm of software, relatively tangible results. At the end of a test, you have evidence of the software’s behaviour.

Even if you employ the best in software development practices, tools and engineers, and you deploy the full range of quality assurance/quality control methods throughout the whole life cycle, you will still need to test. You may find that you have reduced the cost and timescales of testing by employing ‘best practice’ bug-prevention and early bug-detection disciplines during development, but you will still need testing to measure and prove just how effective all that was none of the other quality techniques provides the same level of observable confirmation that software behaves as expected, and running it does not result in failures. You will need to test to be confident that software performs technically and functionally as designed, to demonstrate to users that it solves the problem they intended it to, and to measure what risks you may be taking if, as is nearly always the case, the software is not perfect. 

Business management is increasingly aware that software testing is an essential process that can deliver significant business benefits. With its abilities to demonstrate that business requirements are met and to expose the risks that remain in deploying a newly developed piece of software, testing has business interests at its center. It is a powerful tool in ensuring that software development results are aligned with business objectives.