Software Testing @ what stage of SDLC

A Software Development Life Cycle (SDLC) model represents all the activities and work products necessary to develop a software system. Life cycles models make the software development and dependencies visible and manageable.

Conventional waterfall has the phases in SDLC are:
1. Requirement & analysis
2. Design
3. Development (Coding)
4. Integration/Testing
5. Maintenance

From above, we can see that testing starts after the development of some functionality. Testing team is not involved in any of the first two steps. This is how I have seen in my career. Could be different in other companies, but I can guesstimate it will be more or less for the smaller to medium size companies. 

In waterfall/ modified waterfall, iteration method, design team designs the software based on the specs. Specs, are not always written with every scenarios, especially the odd ball scenarios are not present in the Specs. So what happen is, when we start testing those odd ball scenarios, it falls into a gray area. According to developer, it’s not in specs and as a tester (represents users of the real world) it’s a problem and it get stuck in some gray area and sometimes it involves one level upper position people to resolve this (unnecessary) dispute. 

We can minimize this type of scenario if we could involve the testing team members who will give input to the requirement/ design team from user's perspective. Many things can be discussed at the beginning so that it can be prevented to occur at the first place. 

I would like to share few of my experience here. (I believe testing team is the middle man between developer and user. So, testing will, in SDLC will represent user.)

#1. I worked on a core banking project. They were developing a portal interface. Design team designed a web interface that will take some input and will submit it to the database.  I was not part of the initial design team. I was invited to participate on their final design review. I looked at it. The first thing that struck my mind is what if I create an automated process and dump garbage data. Clearly that was not handled in the design. I'm talking about Challenge key. Even though it’s a very common thing now a days to handle, it wasn't like 10/15 years ago. Designed team then realize the issue and they added additional thing to protect it. 

#2. Another simple example. We had one product that was already in the production. It was decided to add a new feature to the existing system. So, the user, BA and developer was there. Testing team was not there. Developers implemented the feature based on the verbal interactions with the user. (Agile allows not to have comprehensive specs. That is more emphasize on human interaction less on papers. Hmm, sounds like a haven for the people who hates to document). Then it was given to the testing team. The first thing that testing team found was they broke the existing system. It was quickly reported and then fixed by developer. I think, this can be called an iteration. I was wondering in my mind, was this iteration was necessary? One the first thing testing team did check whether it broke any functionality or not. It could have been discussed during the brainstorming session. It was skipped (blaming the Agile!). It defiantly incurred some time and money. 

I can continue with few more examples like this, but I think the point is clear that we will have to have test plan for all phase of SDLC. This is what I felt at the very early stage of my career as tester. Apparently I was not the only one felt for it. So, the software testing community introduced some modification/ improvement of the traditional system. 

V-Model design is such an improvement of the existing waterfall method and can also be applied, to some extent on Iterative or Agile method. This model is based on association of a testing phase for each corresponding development stage. This means that for every single phase/iteration in the development cycle there is a directly associated testing phase. I have chosen this one as it visually represents, easy to understand the concept of engaging testing in each phases, not necessarily the sequential phases of waterfall.

V- Model design:

(Photo credit – NaveenKumar Namachivayam / Google search..)

  

Following are the short description of validation phases in V-Model:
(I liked the description of Tutorials Point site. So I’ll be quoting following few para from them. http://www.tutorialspoint.com/sdlc/sdlc_v_model.htm)

Following are the Validation phases in V-Model:

Acceptance Testing: Acceptance testing is associated with the business requirement analysis phase and involves testing the product in user environment. Acceptance tests uncover the compatibility issues with the other systems available in the user environment. It also discovers the non functional issues such as load and performance defects in the actual user environment. 

System Testing: System testing is directly associated with the System design phase. System tests check the entire system functionality and the communication of the system under development with external systems. Most of the software and hardware compatibility issues can be uncovered during system test execution.

Integration Testing: Integration testing is associated with the architectural design phase. Integration tests are performed to test the coexistence and communication of the internal modules within the system.

Unit Testing: Unit tests designed in the module design phase are executed on the code during this validation phase. Unit testing is the testing at code level and helps eliminate bugs at an early stage, though all defects cannot be uncovered by unit testing.

Ok, lets says those are the steps in waterfall method which has many limitations. Now keeping these phases in mind, lets take a look at what Agile method is trying to say in this regard. From Microsoft's Testing Methodologies topic (http://msdn.microsoft.com/en-us/library/ff649520.aspx)- 

"In Agile, People and interactions are emphasized, rather than processes and tools. Customers, developers, and testers constantly interact with each other. This interaction ensures that the tester is aware of the requirements for the features being developed during a particular iteration and can easily identify any discrepancy between the system and the requirements." 

Agile basically in favor of engaging testing in all phases (if I interpret it correctly). There is an advantage of Agile method- customer is a part of team. So, the gap between the developer and customer being reduced here. Customer does not always be there and does not necessarily understand all technical thing of the software. So, testing team still can be a bridge between developer and customer. Testing team also gets the advantage of knowing the user, user's requirement,  expectation and importantly, user's psychology. 

Another method in SDLC is Iterative method. It says, according to Microsoft, " the development model breaks the project into small parts. Each part is subjected to multiple iterations of the waterfall model. At the end of each iteration, a new module is completed or an existing one is improved on, the module is integrated into the structure, and the structure is then tested as a whole."- (http://msdn.microsoft.com/en-us/library/ff649520.aspx). Which in other words supports the above model, but in smaller iteration. 

Figure: Quality Assurance in the Iterative Model
Credit: snyders.us

Unified Process
Another popular methodology used by Rational Unified Process (RUP) and is performed in an iterative and incremental manner. The life cycle of the UP is presented in following Figure. 

UP divides the project into four phases which are shown above in Figure and discussed below[3]:

• Inception – By the end of this process a business case should have been made; feasibility of the project assessed; and the scope of the design should be set.

• Elaboration – In this phase a basic architecture should have been produced and a plan of construction agreed. Furthermore, a risk analysis takes place and those risks considered to be major should have been addressed.

• Construction – This process produces a beta-release system. A working system should be available and sufficient enough for preliminary testing under realistic conditions.

• Transition – The system is introduced to the stakeholders and intended users. It is crossed when the project team and the stakeholders agree that the objectives agreed in the  inception phase have been met and the user is satisfied


Some of the key features of the UP are as follows [2]:

It uses a component based architecture which creates a system that is easily extensible, promotes software reuse and intuitively understandable. The component commonly being used to coordinate object oriented programming projects.

• Uses visually modeling software such as UML – which represent its code as a diagrammatic notation to allow less technically competent individuals who may have a better understanding of the problem to have a greater input.

• Manage requirements using use-cases and scenarios have been found to be very effective at both capturing functional requirements and help in keeping sight of the anticipated behaviors of the system. 

• Design is iterative and incremental – this helps reduce project risk profile, allows greater customer feedback and help developers stay focused.

• Verifying software quality is very important in a software project. UP assists in planning quality control and assessment built into the entire process involving all member of the team

Waterfall, Iterative, Agile method or RUP- I personally don't think any of the model is good or bad. It depends on project environment , company structure, budget, nature of business etc. In short,  whichever model is more suitable for the company will be the good one.

Management may argue with this concept to engage Testing Team members at Requirement level and/or Design level which may add cost resource, time and cost, but that certainly will minimize the Testing Life Cycle cost by some early measurement / detection. 

References:
[1] Microsoft's Testing Methodologies topic (http://msdn.microsoft.com/en-us/library/ff649520.aspx

[2] B. Grady, C. Robert, J. Newkirk, Object Oriented Analysis and Design with
Applications, 2nd edition, Addison Wesley Longman, 1998

[3] P. Kruchten, “What is Rational Unified Process?”, The Rational Edge,
http://www.therationaledge.com/content/jan_01/f_rup_pk.html Accessed 2/2/2005