Understanding Waterfall Model from a tester's perspective

      In this article, I will describe the waterfall model and understand it in a better way myself too.

      Waterfall Model is a sequential process model used in SDLC in which sequence of activities flows from top to bottom in a linear manner with next activity starting once previous activity is completed. Normally, The Output of the first activity acts as an input to the subsequent phase in waterfall model, also changes in the analysis can be traced back to previous phases if any change is identified in later phases of SDLC.

      Waterfall model can also be described as a document driven approach as communication depends on the quality and quantity of documentation.

This was first of the models used in Software Engineering provided by Winston W. Royce in an article published in 1970. Since the Software Industry evolved a lot in the past 40 years, new models and methodologies have also evolved which covers the shortcoming of Traditional waterfall model, but some or other features of waterfall Model are used in various other software methodologies. Therefore it is useful to understand the waterfall model before discussing other models.

Different Phases in Waterfall Model are described in the section below:

a. Requirement Analysis: 

In this phase, the requirements are understood from the client and analyzed. To Understand requirement , customer are consulted, the feasibility of the requirements are understood and based on all the inputs, business requirement specification is developed and is signed off by client as an agreement between client and supplier on the agreed functionality.

b. System Design: 

Before starting with system design, all the requirements are freeze in the requirement phase. The requirement documents acts as an input to this phase and based on this a system design is prepared in this phase.

c. Architecture Design:

  The system design is analysed and an architecture design dividing requirement into module based on functionality is developed. The input for this phase is the system requirement documents and output helps in preparation of low level design for the projects.

d. Low Level Design: 

In this phase, low level design at module level is developed which acts as input to coding phase. The high level design or Architecture design acts as input to this phase.

e. Coding: 

The Low level design is implemented to code. All the code is merged together and various modules are integrated together to form a system as defined in System design.

f. Testing:  

When Coding is completed, the code is passed on for testing and various testing types are conducted on the code and the defects are passed on to development team . Based on the defect impact, there needs to be changes implemented at code level or can impact the previous levels. The more the impacted phases, more will be the cost of fix.

g. Operations and Maintenance:

 Once testing is completed, the system goes to Production. Support and maintenance team helps in maintenance of the product.

Waterfall Model

Where to Use Waterfall Model: 

Waterfall model is most useful to be followed in projects where:

a.  Requirement is very well documented and probability of requirement changes is low.

b.  Expertise of resources is available to ensure each phase is completed with minimum gaps and rework.

c.  The time span of the project is short.

d.  The Project is stable with minimal requirement changes 

 Waterfall Model Positives:

a. Easy to understand and manage as the milestones in project are defined and mostly at a time only one phase is active, so needs to manage one phase only at times.

b. Processes are well defined.

c. Documentation is done properly for each of the stages in the life cycle.

d. Developing a culture of analysis before coding as there is thorough analysis from requirement to design to coding.

  

Waterfall Model Negatives:

a. The major negative of the model is the risk and uncertainty associated with the model which can arise due to below reason:
        a. Requirement change at a later stage.
        b. Since the application is not developed till a major part of life cycle, Actual feedback on functionality happens late in the life cycle

        c. The cost of fixes is high if uncovered late in the life cycle

b. Most of the defects are uncovered in system testing phase which results in a lot of rework and at times changes in the design, which can impact the timeline and acts as major threat to the success of the project.

c. At times, the testing time shrinks in the waterfall model due to delay in earlier stages of model. This can led to defects escaping the testing phase, which if uncovered in production can result in higher costs and can impact business too.

 Conclusion: 

Waterfall model was first of the model to be used in Software development model and acted as a basic framework to track and relate various phases of development. With time, various new models of Software development life cycle evolved, for e.g. V-Model, Iterative model, agile Model and so on, but somewhere we can see glimpses of waterfall in each of the models. Hence Understanding the most basic of models is highly useful before going to understand newer model that evolved over the years in SDLC.

Testing Models - Understanding V-Model from testing perspective

V-Model is a software development  Model which shows software development life cycle to follow a V shape. V-Model was developed with the intention to cover some of the problems found in waterfall Model with one of the main issue as defect uncovered late in the Software development life cycle.

The main purpose of representing in a V is to show the relationship between each phase of development life cycle with its associated phase in testing. The execution of processes happens in a sequential manner in this model. This is also sometimes called as Verification and Validation Model

During the initial stage, i.e. from requirement to Coding and Implementation are verification phase and then from Coding and Implementation to User Acceptance testing are Validation phases in the model.

Before continuing with understanding the responsibility of testing in various phases of a V-Model, we must distinguish between Verification and Validation.

Objective of Verification is to ensure the product is being built according to requirement .Walk-through, reviews, inspection are some of the activities, whereas objective of Validation is to ensure the product build meets the user requirement. Whereas Verification activities are mostly done during product building process, Validation is done post product is build

Below are the activities performed by testing team during various stages of V-Model.

a. Requirement Analysis

 Testing tasks includes preparation of User Acceptance testing plan to be followed during UAT testing during the first phase of V-Model. Involvement of testing team early in the requirement help understanding the requirement and analyzing gaps and refining requirements based on scenarios identified for User Acceptance testing.   

b. System Design

 Once we have the requirement signed off by the customer, the developer and testers in parallel starts to work on system development design and system test design respectively.

c. Architecture Design

In this phase, test and plans related to integration testing of different modules are created. From development point of view, In this phase, high level design of the system is created starting from dividing requirement into different modules based on functionality and the interaction of modules defined with each other , external world as well as existing modules if the new functionality is an added functionality in the existing system.

d. Module Design

This phase from development point of view defines the low level design of each of the modules.  To ensure each module is working correctly, to test the internal structure of the module, we need to create unit test cases to test units in the module. Unit testing is mostly performed by developers as is mostly related to internal structure and design of modules.
   

e. Coding and Implementation

Next Phase in the V-model is implementation of low level design into code. So in all the above phases of the V-Model, similar to developers, testing phases occurs in parallel and does verification and analysis at each phase and prepares for testing.

f. Unit Testing 

 Once Coding and Implementation is completed, we need to execute unit test to verify the designed has been coded and implemented properly. Units are tested as they are developed. Unit tests prepared during Module designed are executed to unit test the modules individually

g. Integration Testing

Once the modules are unit tested individually, it is the time to test integration of modules with other modules and external systems. Integration test prepared during Architecture design are executed in this phase.

h. System Testing

 Once we have tested the modules followed by Integration of modules and external systems. Next step is to verify whether the system is working properly and as defined in the requirements
    

i. Acceptance Testing

 Once the system is tested properly by QA Team, it is passed on to customer to perform User acceptance test. This can be performed by client or UAT Team designated by client.Please note from  step f. on wards, we started in step a. to e., the necessary test preparation and analysis tasks.
  

Conclusion  On a whole, V-Model is a much disciplined Model with salient feature including testing starting as early as possible from requirement phase. Requirements are clear and properly analyzed by different perspective, i.e. business analysts, testers and developers. This model has shortcomings in case of some requirement changes in between the software development life cycle

Seven Principles of Software testing

Software Testing focuses on ensuring the quality of the software. Software not tested properly can cause many problems including financial losses, reputation loss and at times injury or even death. How much testing is required depends on the risks associated with the software as well as time constraints. There are few principles of testing that can help to better understand the process of testing and define testing process

The principles of testing are as follows:

1.  Testing shows presence of defect  

Testing helps in uncovering defects although we can never be sure that that there are no defects in the software even after testing. So the focus of testing is to find as many defects in the system.

2.  Exhaustive Testing is not feasible

 Going by the first principle, tester can never be sure that there are no defects in the system, One of the reason for first principle is exhaustive testing is impossible. We can test all the scenarios related to software but the time and resource cost for testing exhaustively will be so huge, it will not bring any value and will not be able to deliver software. Due to this proper risk analysis and priorities of scenarios should be taken care of in testing for balanced and timely testing completion.  Test cases should be prepared based on the functional specification, as test cases for high priority scenario should be executed first.

3.  Testing should start as early as possible

 Catching defects early in the Software development life cycle reduces the cost of fixing of defect. For e.g. Testing should start as early as possible, Reviews should take place to identify gaps in requirements understanding, and identify code issues early.  Also test designing should start as soon as possible.

4.  Most of the Defects are confined to small module

This has been noticed that most of the defects are confined to small module; the reason of defects can be understanding gaps in the particular set of modules and the technical skill of the resources.

5.  Pesticide Paradox

 Executing the same test cases again and again eventually results in no defects being identified by test cases. Due to this reason test cases should be reviewed from time to time, with new test cases added and redundant test cases removed from the regression pack to keep the test suite fresh, up to date and effective. Test cases must include both manual and automated test cases for higher coverage of test scenarios.

6.  Testing requirement varies from software to software 

Testing is done differently for different software. A social networking site will have different requirement of content and performance testing compared to banking software that will require functionality and security as main factors compared to the social networking site. The testing requirements should be well defined in the scope of testing.

7.  The software developed should be usable by user

and should meet user’s need and expectation. It does not matter if there were no defects in testing the software if it does not meet the need of end users.Software 

Understanding Quality Assurance and Quality Control

Whenever a product is delivered to the client, client expects the quality of the end product to be high. To assure high quality of end products, there must be stress on quality. Quality has different meaning for different users. For developer of a product, it means quality of product meets the requirements mentioned in the specifications whereas for end user, it means the product is fit for use and works as expected. A quality Software should possess desired features,should be fit for use and usable at the desired cost

To ensure quality, there are quality Assurance and quality control groups in the organization. In this article, we will discuss the role and difference between quality assurance and quality control.

Quality Assurance

Quality assurance is a planned and systematic set of activities necessary to provide adequate confidence that products and services will conform to specified requirements and meet user needs. The purpose of quality Assurance is to ensure quality policies are defined. The project Quality Assurance must ensure process are implemented for:

•      System development methodologies
•      Estimation processes
•      System maintenance processes
•      Requirements definition processes
•      Testing processes and standards

Quality assurance is a continuous improvement activity in processes uncovering weakness in the process and strengthening the process followed. Normally the quality assurance activities are defined at organization level and are uniformly followed across the project. There are regular audits by an independent QA audit team within organization which audits across different project to ensure Quality assurance activities are followed across the organization.

Quality Control

Quality control is the process in which developed product is compared with requirement at different phases and discrepancy is logged as defects. The process of quality control begins with the development phase. This includes Static testing, and dynamic testing.

Static testing includes reviews and analysis of the code using tools. Reviews include manual examination of the code as well as documentation. Reviews are important to identify gaps early in the development process. Defects detected during reviews early in the life cycle are often much cheaper to remove than those detected while running tests Reviews can vary from informal reviews to formal reviews. Informal reviews, Walkthrough, Technical review, and inspection are all examples of review with varying degree of documentation and formal approach. Static analysis also includes verifying the code effectiveness through code analysis tools.

Once the development of the requirement is completed, the product is passed on to testing team for complete testing. The purpose of testing is to uncover as many defects in the system as possible. The focus of testing is look at the product from different views. A system tester or functional tester will verify the system/functionality is working as per functional requirement. Performance tester will need to verify the performance of system under stress and load conditions and so on. How much testing and what testing is required is normally defined in the scope of testing. There are various test management tools like Quality center that helps to manage and map various test artifacts and defects with test cases.

Quality Assurance and Quality Control activities are required to ensure quality deliverables to client and should be followed religiously to ensure high quality to the customer

Test Estimation : Understanding Test Efforts Calculation

Estimates plays very important role in successful projects as incorrect estimates can lead to time crunches , or improper resource utilization in case of excessive time in estimates.
In this article we will discuss various factors in estimation and how to create good estimates in a testing project.

Before providing estimates, we need to know the requirements of the project. First step before any testing task including test plans and estimates is to know what we are delivering to the client. Once we are clear on the requirements, we need to define the tasks that need to be done as exit criteria for the project. 

We have to answer following points before progressing with estimates:

1.   What is the time required to set-up the basic infrastructure. This includes acquiring resources, testing tools, setting up environment and training requirements of resources.

2.   What are the testing types we are performing in project? Does it include automation testing, API Testing, and other testing types?

3.   What is the Software Development Life cycle followed in the project, i.e. it is agile, waterfall or V-model, if iterative, what is the scope of each iteration.

4.   Is this project new phase of an existing project or a version of existing application to released in the current project.

5.  Techni Experience of resources working in Project. This helps to determine the time for preparing test artifacts.

So Once we know answers to above questions, we need to create a WBS document most preferably in Microsoft Project which helps in defining the tasks with time estimates, resources overloading  and defining milestones in project. Below points should be considered while creating the Work Breakdown Sheet.

1.  First of all create the high level milestone for the project. This can be various phases of the project or iterations of project in and agile methodology.

2.  Now create subtask for each milestones of the project. This will include tasks like test planning, test review, test execution, test data preparation for various forms of testing and regular team meetings.

3.  Task test planning, test review, test data preparation and test execution requires further breakdown of requirements into test scenarios and further into Test cases. Once the requirements are broken down into test scenarios/ test cases, we require estimates for each of the tasks.

Example: 

• Suppose we have 250 test cases in an application for a particular milestone. We need to define time for test planning, test review, test execution, and test data preparation for each of the test artifact, can be test case for manual execution and test script in automation testing. Automation testing will also include task for framework development.

• Now divide each of the test cases based on test complexity into high, medium and low complexity. Dividing and allocating time for each test case using test case complexity is very useful in case of large number of test cases where estimates for a particular test case in not feasible and time required for each test case is more or less uniform based on complexity. In this approach, time estimates are provided for test cases based on complexity. For e.g.  10 hours for test case preparation for high complexity, 6 hours for medium complexity, and 4 hours for low complexity.

• In Point b), we provide test estimates based on complexity and was useful since time for test cases was uniform and there was large set of test cases. 

• In case the project has 10 requirement of varying complexity, like 1 requirement will take 100 hours and other 2 hours, So Rather providing estimates based on complexity, we can define the estimate based on past experience of users, and provide below time:
• Min Time to complete the task
• Worst Scenario Time to complete the task.
•  Average time to complete the task

• We can calculate the average of above time to calculate time to complete the task. While providing the estimate as calculated in step c) we must take into consideration resources experience in the application and technology.

4.   We can provide time for each of the tasks in the work breakdown sheet. Summing time for all the activities will give us the test efforts required in the project.

5.   We further need to assign task to different types of resources based on the tasks and can provide resourcing estimates  for the project. we can define the resources utilization during different phases of project .

I will try to cover further in future articles on estimates things I might have missed here.

What are different activities in Testing Process

Testing Process includes following activities that should be followed sincerely for proper testing.

1. Test Planning

Before beginning with testing, we need to define test plan based on which we perform testing for the rest of testing life cycle. We should develop a test plan based on following key points to be considered in testing life cycle.

• Test Objectives should be measurable, prioritized, and should be signed off between stakeholders before moving forward with test planning. Acceptance Criteria should also be defined during objective settings to validate if the test objective has been accompanied.

• Test Matrix should be defined on how to test the test objectives and to validate all the requirements are covered in testing.

• Test Schedule should be defined, how milestones in testing will be covered and timeframe in which milestones will be delivered

• Budgeting and resources planing should be defined.

• Testing material including environment ans software/availability should be defined.

• Training required for testing should be defined.

2. Test Control Activities

Once Test plan is created and signed off by stakeholder, Activities in test plan should be compared with actual and any deviation from the projected plan should be reported to stakeholders as risk.

3. Test Analysis

In this phase, test objectives defined in test planning are converted into test scenarios and test cases.Below are the main task in this phase:

• Reviewing the test artifacts like business requirements, design, and test objectives.

• Identifying and prioritizing test scenarios and test cases based on business requirements.

• Identification of test data for execution of test conditions

• Test environment availability

4. Test implementation

Below are activities in test implementation

• Developing and prioritizing test cases with test steps

• Preparation of test data for execution of test scripts.

• Environment set up for testing.

• Development of automation test harness.

• Preparation of test suites for regression, smoke testing, and execution of similar tests in batch.

5. Test Execution and Reporting

• Execution of test scripts either manual or automated.

• Reporting defects found during test script execution.

• Regression testing and retesting of fixed defects. 

• Reporting of test execution status to stakeholders.

6.  Exit criteria

• Evaluating Testing status against the exit criteria specified in test planning.
• Test Status should validate that all acceptance criteria are verified.

7. Test Closure Activities

• Delivering all the planned test artifacts to the client. For e.g : Automated Test Scripts,test scripts, test data for further reuse.

• Handover of artifacts and knowledge transfer to maintenance team

• Analysis of lesson learnt during testing process.

Priniciple of Software Testing and Difference between QC and QA

Basics of Testing

Testing is a quality control activity with objectives as finding defects, gaining confidence on the quality of products and preventing defect. Testing should start as early as possible and should be planned for different phases of software life cycle. Early detection of defects reduces the cost of fixing defects.

Principles of Testing

Below are the principles of testing which should be taken into consideration while performing testing:

• Testing shows presence of defect but we cannot ensure there are no defects in the system. The reason for this is described in next principle

• Exhaustive testing is not possible as covering all combination of data and scenario is not feasible as it will take lot of cost and resources & time.

• Testing Activity should start as soon as possible. This will result in defect fixed with less effort in development and development can more easily accommodate the changes in early phases than latter.

• So now the question arises, which things to test first. Most of the defects are concentrated to small number of modules, which is defect clustering. So we need to concentrate more on modules more prone to defects.

• Next test case needs to be updated regularly to avoid pesticide paradox i.e same test cases if executed again and again will not be able to find more defects.

• Testing should be context sensitive, i.e before considering testing, we should take into consideration the impact and importance area of the application

• And finally the product delivered and tested should match the client expectation, and is no purpose even if no defect is found, but product does not fulfill client requirement.

    

 Quality Control and Quality Assurance

Last point in the Testing principles mentions the product delivered to the customer should be quality product. To ensure quality of the product, we must follow quality assurance and quality control activities.

Quality Assurance ensures proper quality processes are followed during product development .For example. There are regular audits, inspections, review activities, estimations, testing process standards during the software life cycle to assure the quality of product.

Quality Control is the testing activities in which product quality is compared with expected standards and issue is raised in case of defects or non conformance being encountered.

Some of the most important Quality Factors are Correctness, Reliability, Efficiency, Integrity, Usability, Maintainability, Reusability, and portability.