SDLC

Pete had previously asked, "You had mentioned that this blog would also be for those new to the field of software testing. I would fit in the "New" category which also gives me the excuse of asking basic questions. What is the Software Development Cycle and how does Testing fit into this Development?"

Good question. Like Pete many might not be aware of what exactly does System Development Life Cycle (SDLC) exactly mean in the software world.

Lets take the simple example where you plan to build a house. The whole process will require a whole lot of brainstorming before you lay the first brick. First, you look at the ideal location. Once you have that, you would look into the layout, internal arrangement of the house, how many rooms do you need, etc. You would probably hire an architect to do the planning. Next you would have a construction authority work on the type of material you would like to use, how many days you would like the house to be up and complete in etc. Once all these details are laid into place, the construction will finally begin. So everything goes by a particular method or process.

Lets get to the definition of SDLC provided at http://www.webopedia.com/TERM/S/SDLC.html It states:

(quote)

SDLC is the process of developing information systems through investigation, analysis, design, implementation and maintenance. SDLC is also known as information systems development or application development. SDLC is a systems approach to problem solving and is made up of several phases, each comprised of multiple steps:

• The software concept - identifies and defines a need for the new system
• A requirements analysis - analyzes the information needs of the end users
• The architectural design - creates a blueprint for the design with the necessary specifications for the hardware, software, people and data resources
• Coding and debugging - creates and programs the final system
• System testing - evaluates the system's actual functionality in relation to expected or intended functionality.

(unquote)

Lets take a case where a company decides to develope a new product. First, they need to identify the need for this product. Why would it be required in the market. Next, how the end user would use this product. What would they want out of this product and what the market lacks right now which this product will provide.

Once these have been identified, we would probably have the Pragram Manager write down the specifications of the product. This is a document which has details of every small requirement that the product should meet. Right from the kind of platform it should work on to how its final output should look.

Once the specifications are up, the Development team starts putting them down into code and test team starts testing the code written by the development team.

Did anyone spot an ambiguity? Anyone?

Lets go back to the house. Your architect lays out the entire plan and you start the construction. A few months down the line, the house is built and you move in. You love your new house but your master bedroom is on the eastern side of the house, which is right next to Interstate - I 95. Passing cars and trailors all night keep you awake. The guest bedroom on the other side of the house is perfectly soundproof and your visiting mother-in-law enjoys the perfect sleep! The guest bedroom is too small for you and your wife to move into... Oh!! Only if you had thought about this I-95 before!!

So is it with software. Having the specs does not mean the product is ready to code. Read the spec and start thinking outside the box. First point of the spec says "Client shall take as input a file using the file dialogue open window" (this is a lame way of writing a spec, I am just trying to provide an on the spot example). Anyone try to think what will happen if I choose a file and before I hit open, someone from another machine with access to the server deletes that file? How should the system behave? What if I enter a filename which is not present? How will the system behave? Rip that spec apart.

Lets go back to the house. You finally cant bear the vehicle noise on I-95 and you break a few walls, make the guest room bigger and move in there. In this process you are set back by a few thousand dollars.

The same goes for software, a bug in the spec is much cheaper to correct rather than a bug in the product once the code is up and running.

A good tester would not only find bugs in the product, but would find bugs in the spec. This is where testers come in. I would also like to mention here that developers also go through specs and try to identify bugs, but testers are more concentrated on developing test cases for the spec, developers for design prototypes for the specs.

Back to SDLC. And once a lot of reviews and discussions and prototyping is done, the dev team starts coding and test team continues testing till the final product is complete.

During this entire process the management team oversees the progress, makes decisions about new hires, deadlines, addition/deletion of new features etc.

I think I am going to add a new post of why its important to analyze specs before we start coding + some other stuff.