Software Testing Department of IT

Semester Code No. Subject No. SOFTWARE TESTING 18ITU27 (For the students admitted in the academic year 2016-2017 and VI onwards) Objective: To develop the skill of Software Testing. Knowledge on Software Testing and how to test the software at various levels. To inculcate knowledge on Software Testing Concepts. Unit No. Topics Hours Introduction to Testing: Principle of Testing- Context of Testing in Producing Software - A test Unit 1 in time-Test the test first-The end of pendulum- Putting all together- 14 Phases of Software project.

Software development and Life cycle model: Quality Assurance and Control-Testing verification and validation- Process model to represent different phases-Life cycle model: Unit 2 15 Waterfall Model, Iterative Model or Spiral model- Rapid Application model and V model Prototyping .

Testing Types White box testing (Static testing and Structural testing), Black box Unit 3 testing: What is testing? , Why testing is done? , When testing is done? 15 How testing is done? , Integration testing, Types of Integration testing, Scenario testing. System and Acceptance Testing Over View of System and Acceptance Testing-Why System Testing- Functional Vs Non Functional Testing-Functional Testing-Non Unit IV 14 Function Testing-Acceptance Testing- Performance Testing-Factors of testing-Methodology of testing- Tools of testing.

Regression Testing What is Regression Testing- Types of Regression Testing - When Regression Testing is done- When Regression Testing is performed- Unit 5 14 Planning Regression Testing-Management of Regression Testing- Execution of Regression Testing- Reporting Regression Testing.

Software Testing Department of IT

Text Books: 1. SrinivasanDesikan&Gopalswamy Ramesh, ―Software Testing Principles and Practices‖, Pearson Educatio,2006.

Reference Books: 1. Renu Rajani, Pradeep Oak , ―Software Testing. – Effective Methods, Tools & Techniques‖ – Tata McGraw Hill. 2. Bob Hughes & Mike Cotterell, ―Software Project Management ―,4th ed, PHI. 3. Ron Patton,‖Software Testing‖ Second Edition, 2005 .

Software Testing Department of IT

Software Testing

Unit -1 Introduction to Testing

SDLC:

Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test high quality software. The SDLC aims to produce a high-quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates.

SDLC is a process followed for a software project, within a software organization. It consists of a detailed plan describing how to develop, maintain, replace and alter or enhance specific software. The life cycle defines a methodology for improving the quality of software and the overall development process.

The following figure is a graphical representation of the various stages of a typical SDLC:

Testing:

This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are mostly involved in all the stages of SDLC. However, this stage refers to the testing

Software Testing Department of IT only stage of the product where product defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined in the SRS.

*Testing is the process of evaluating a system or its component(s) with the intent to find whether it satisfies the specified requirements or not.

Testing is executing a system in order to identify any gaps, errors, or missing requirements in contrary to the actual requirements.

Principles of Testing:

1. Testing shows presence of defects 2. Exhaustive testing is impossible 3. Early testing 4. Defect clustering 5. Pesticide paradox 6. Testing is context dependent 7. Absence of error – fallacy

The common objective of testing is finding bugs as early as possible. And, once the bugs are fixed, make sure it is working as expected and not breaking any other functionality.

To achieve these goals, seven basic principles are given for software testing −

Software Testing Department of IT

1. What Testing shows?

Testing can show that defects are present but there is no way to prove that there is no defect in the product. Testing phases make sure that the application under test is working based on the given requirement and it helps to reduce the probability of undiscovered defects in the application. But, even if no defects are found, it does not mean that it is absolutely correct. We can assume that AUT is matching with our exit criteria and maintaining the requirements according to SRD.

*System Requirements Document (SRD)

The System Requirement Document (SRD) defines system level functional and performance requirements for a system. The SRD is derived from the Capability Development Document (CDD), Concept of Operations (CONOPS), system-level performance metrics, mission threads/use cases, and usage environment and is developed but by the program office. It should include a system level description of all software elements required by the preferred system concept. The SRD is developed during the Technology Maturation & Risk Reduction (TMRR) Phase but a draft SRD should be developed for the Analysis of Alternatives (AoA) in the Materiel Solutions Analysis (MSA) Phase. The SRD is used by the program office to provide more detailed requirements than what‘s provided in the CDD and is normally included in a solicitation package. The SRD should be finalized prior to contract award. [1]

Standard: MIL-STD-961 ―Defense and Program-Unique Specifications Format and Content‖ – 9 Jan 2014

The SRD should be developed with feedback and input from the industrial base. Once the SRD is placed on contract, the contractor will further develop the specification and develop their own, more detailed requirements document; sometimes called a Weapons Systems Specification (WSS).

Software Testing Department of IT

The term ―System Requirements Document‖ is a phrase commonly used to describe a software performance specification. If your acquisition is exclusively for software, you may call yours a ―System Performance Specification‖ or ―System Requirements Document‖.

2. Is Exhaustive Testing possible?

100% coverage or testing of all combinations of inputs and possible combinations are not possible except of trivial cases. Instead of exhaustive testing, risk analysis and priorities are used to define the scope of testing. Here, most of the real time scenarios can consider including most probable negative scenario as well. This will help us track the failure.

3. Early Testing

Testing activities should start as soon as possible and be focused on defined objectives in Test Strategy and expected results. Early stage of testing helps to identify Requirement Defect or design level discrepancies. If these types of bugs are captured in initial stage, it helps us save time and is cost-effective too. The answer to why testing should start at an early stage is very simple – as soon as the SRD is received, the testers can analyze the requirement from the testing perspective and can notice a requirement discrepancy.

Software Testing Department of IT

4. Defect Clustering

Based on previous product defect analysis, it can be said that most of the defects are identified from small set of modules which are critical for application. These modules can be identified based on complexity, different system interaction or dependency on different other modules. If testers can identify these crucial modules, they can focus more on these modules to identify all possible bugs. In a study, it is found that 8 out of 10 defects are identified from 20% functionality of AUT.

5. Pesticide Paradox

What is pesticide paradox – if pesticides are frequently used on crops, there comes when the insects develop a certain kind of resistance and gradually the pesticides thus sprayed seem to be ineffective on the insects.

The same concept is applicable on testing also. Here, insects are bugs while pesticides are test cases that are used to run again and again. If the same sets of test cases are executed again and again, these test cases become ineffective after certain timeframe and the testers will not be able to identify any new defect.

To overcome these conditions, test cases should be revised and reviewed time to time and new and different test cases can be added. This will help in identifying new defects.

Software Testing Department of IT

6. Testing is Context Dependent

This principle states that two different type of application can‘t be tested using same approach until both applications are of same nature. For example, if a tester uses the same approach for Web Based Application and Mobile Application, that is completely wrong and there is high risk of poor quality of product release. Testers should use different approaches, methodologies, techniques and coverage for different types and nature of applications.

Software Testing Department of IT

*Context-driven testing:

Context-driven testing is a model for developing and debugging computer software that takes into account the ways in which the programs will be used or are expected to be used in the real world. In order to successfully conduct this type of testing, software developers must identify the intended market and evaluate the environments in which people are likely to employ the product.

Some adherents of context-driven testing call it a set of values rather than a process or technique. It revolves around the fact that software users are human beings with diverse preferences, needs, abilities and limitations. A program that works well for one person in a given situation might prove inadequate or inappropriate for another person or situation. For example, a word processor with mathematical symbols and a set of tools for positioning and manipulating them might be ideal for a college professor writing a physics textbook but cumbersome and annoying for a novelist. Conversely, a simple text editor may be preferred by the novelist but be rejected by the professor.

7. Absence of Error – Fallacy

This principle states finding defects and fixing them until the application or system is stable, is time consuming and also eats up on the resources. Even after fixing 99% of the defects, there is a high risk of unstable application. The first essential thing is to verify the stability of the application and the prerequisites of the environment. If these two conditions fulfill, only then we can start with the detailed testing.

Software Testing Department of IT

Advantages

 Enhanced user-friendliness of the end product  Optimized functionality for intended users  Adaptability of the product to changing markets and social values

*Software Testing Life Cycle (STLC) is the testing process which is executed in systematic and planned manner. In STLC process, different activities are carried out to improve the quality of the product. Let’s quickly see what all stages are involved in typical Software Testing Life Cycle (STLC).Following steps are involved in Software Testing Life Cycle (STLC). Each step have its own Entry Criteria and deliverable.

 Requirement Analysis  Test Planning

Software Testing Department of IT

 Test Case Development  Environment Setup  Test Execution  Test Cycle Closure

Ideally, the next step is based on previous step or we can say next step cannot be started unless and until previous step is completed. It is possible in the ideal situation, but practically it is not always true.

So Let‘s discuss what all activities and deliverable are involved in each step in detailed.

Requirement Analysis:

Requirement Analysis is the very first step in Software Testing Life Cycle (STLC). In this step Quality Assurance (QA) team understands the requirement in terms of what we will testing & figure out the testable requirements. If any conflict, missing or not understood any requirement, then QA team follow up with the various stakeholders like Business Analyst, System Architecture, Client, Technical Manager/Lead etc. to better understand the detail knowledge of requirement.

From very first step QA involved in the where STLC which helps to prevent the introducing defects into Software under test. The requirements can be either Functional or Non-Functional like Performance, Security testing. Also requirement and Automation feasibility of the project can be done in this stage (if applicable).

Software Testing Department of IT

Entry Criteria Activities Deliverable Following documents should be Prepare the list of questions or List of questions with all available: queries and get resolved from answers to be resolved from Business Analyst, System business i.e. testable – Requirements Specification. Architecture, Client, Technical requirements Manager/Lead etc. – Application architectural Automation feasibility report (if Make out the list for what all applicable) Along with above documents Types of Tests performed like Acceptance criteria should be Functional, Security, and well defined. Performance etc.

Define the testing focus and priorities.

List down the Test environment details where testing activities will be carried out.

Checkout the Automation feasibility if required & prepare the Automation feasibility report.

Test Planning:

Test Planning is most important phase of Software testing life cycle where all testing strategy is defined. This phase also called as Test Strategy phase. In this phase typically Test Manager (or

Software Testing Department of IT

Test Lead based on company to company) involved to determine the effort and cost estimates for entire project. This phase will be kicked off once the requirement gathering phase is completed & based on the requirement analysis, start preparing the Test Plan. The Result of Test Planning phase will be Test Plan or Test strategy & Testing Effort estimation documents. Once test planning phase is completed the QA team can start with test cases development activity.

Entry Criteria Activities Deliverable Requirements Documents Define Objective & scope of Test Plan or Test strategy (Updated version of unclear or the project. document. missing requirement). List down the testing types Testing Effort estimation Automation feasibility report. involved in the STLC. document.

Test effort estimation and resource planning.

Selection of testing tool if required.

Define the testing process overview.

Define the test environment required for entire project.

Prepare the test schedules.

Define the control procedures.

Determining roles and responsibilities.

List down the testing

Software Testing Department of IT

deliverable.

Define the entry criteria, suspension criteria, resumption criteria and exit criteria.

Define the risk involved if any.

Test Case Development:

The test case development activity is started once the test planning activity is finished. This is the phase of STLC where testing team write down the detailed test cases. Along with test cases testing team also prepare the test data if any required for testing. Once the test cases are ready then these test cases are reviewed by peer members or QA lead.

Also the Requirement Traceability Matrix (RTM) is prepared. The Requirement Traceability Matrix is an industry-accepted format for tracking requirements where each test case is mapped with the requirement. Using this RTM we can track backward & forward traceability.

Entry Criteria Activities Deliverable Requirements Documents Preparation of test cases. Test cases. (Updated version of unclear or missing requirement). Preparation of test automation Test data. scripts (if required). Automation feasibility report. Test Automation Scripts (if Re-requisite test data required). preparation for executing test cases.

Software Testing Department of IT

Test Environment Setup:

Setting up the test environment is vital part of the STLC. Basically test environment decides on which conditions software is tested. This is independent activity and can be started parallel with Test Case Development. In process of setting up testing environment test team is not involved in it. Based on company to company may be developer or customer creates the testing environment. Meanwhile testing team should prepare the smoke test cases to check the readiness of the test environment setup.

Entry Criteria Activities Deliverable Test Plan is available. Analyze the requirements and Test Environment will be ready prepare the list of Software & with test data. Smoke Test cases are available. hardware required to set up test environment. Result of Smoke Test cases. Test data is available. Setup the test environment.

Once the Test Environment is setup execute the Smoke test cases to check the readiness of the test environment.

Test Execution:

Once the preparation of Test Case Development and Test Environment setup is completed then test execution phase can be kicked off. In this phase testing team start executing test cases based on prepared test planning & prepared test cases in the prior step.

Once the test case is passed then same can be marked as Passed. If any test case is failed then corresponding defect can be reported to developer team via bug tracking system & bug can be linked for corresponding test case for further analysis. Ideally every failed test case should be associated with at least single bug. Using this linking we can get the failed test case with bug associated with it. Once the bug fixed by development team then same test case can be executed based on your test planning.

Software Testing Department of IT

If any of the test cases are blocked due to any defect then such test cases can be marked as Blocked, so we can get the report based on how many test cases passed, failed, blocked or not run etc. Once the defects are fixed, same Failed or Blocked test cases can be executed again to retest the functionality.

Entry Criteria Activities Deliverable Test Plan or Test strategy Based on test planning execute Test case execution report. document. the test cases. Defect report. Test cases. Mark status of test cases like Passed, Failed, Blocked, Not Test data. Run etc.

Assign Bug Id for all Failed and Blocked test cases.

Do Retesting once the defects are fixed.

Track the defects to closure.

Test Cycle Closure:

Call out the testing team member meeting & evaluate cycle completion criteria based on Test coverage, Quality, Cost, Time, Critical Business Objectives, and Software. Discuss what all went good, which area needs to be improve & taking the lessons from current STLC as input to upcoming test cycles, which will help to improve bottleneck in the STLC process. Test case & bug report will analyze to find out the defect distribution by type and severity. Once complete the test cycle then test closure report & Test metrics will be prepared. Test result analysis to find out the defect distribution by type and severity.

Software Testing Department of IT

Entry Criteria Activities Deliverable Test case execution is Evaluate cycle completion Test Closure report completed criteria based on Test coverage, Quality, Cost, Time, Critical Test metrics Test case Execution report Business Objectives, and Software Prepare test metrics Defect report based on the above parameters.

Prepare Test closure report

Share best practices for any similar projects in future

Context of testing in producing software:

Software testing determines the quality of software after a programmer develops it. This process involves evaluating information that is related to a product. Businesses perform their daily activities more efficiently when they implement software testing procedures.

Competition is tough, so every company must operate exceptionally well; quality is needed throughout the entire day. Software testing helps businesses pinpoint defects in their software and make appropriate corrections. Software testing also helps businesses discover errors and bugs so that they can improve overall system capacity and accuracy.

Software Testing Benefits

When application quality is good, it will last longer and will perform resourcefully even if pressed to maximum capacity. Also, software can be configured so that it will operate well even when conditions are less than optimal.

Testing can also improve overall security, but testing is not a simple process. Each day, there will be difficult challenges that involve coding and decoding. The testing process is an important

Software Testing Department of IT phase during the software development because each small module must be tested to ensure its accuracy and validity.

Testing Procedures

There are two types of testing methods: automated testing and manual testing. Manual software testing is done by workers and requires they check codes and report bugs. Most Java software development companies are now implementing automated testing procedures. The main purpose of automated testing is to lower the amount of time it takes to test software and report bugs. Testing each unit is important because all units must perform in an efficient manner.

Software testing is now a key component of software product development because it improves consistency and performance. Though the main benefit of testing involves error rectification and debugging, testing also helps businesses understand an actual and expected outcome so that they can improve the quality of their products. If software is produced without testing, it could be dangerous to buyers because software has a unique development lifecycle that has important technical components.

Testing is recommended because it ensures validation and authentication. If all bugs are removed, the software will be more accurate and reliable.

Software Testing Department of IT

Test in Time:

Time Estimation for the Software Testing

In the process of creation of a successful software product, there is an inevitable problem of finding a balance between the quality and the release date of the software product. The testing allows obtaining a product that satisfies all requirements. But the covering of each product risk with various test cases and compiling them take too long. The correctly prepared testing process should provide a required quality level without exceeding project time and budget. If the time for testing was estimated wrongly, it can lead you either to the late product delivery, or to the decrease of its quality and competitiveness. The software testing estimation is a rather complicated and volumetric process but its significance for the creation of the successful project shouldn‘t be underestimated.

Time environment configuration

Estimated time for test environment configuration depends on the following:

 Equipment availability. If the company does not possess the necessary equipment to set up testing environment, time required to get it should be considered.  Installation and configuration time. How long does installing and configuring all the necessary equipment take depending on the experience of your specialists? A qualified system administrator will be able to perform the required work much faster than a QA specialist can.

Software Testing Department of IT

For a middle-sized project, setting up and configuring a test environment which consists of relatively common software and hardware usually takes anywhere between an hour and a day depending on the complexity of the environment.

Time estimation for software testing is a very tough topic. While a lot of advanced testing estimation techniques are available, and there are a lot of variables to consider and risks to account for, it still can be quite hard to produce exact results. However, it doesn’t mean that producing accurate estimates is impossible.

By following the estimation template that takes into account the necessary time to complete all the steps mentioned in this article, and being mindful of every factor that could have an impact on each step, you will be able to produce fairly accurate estimates that will give you an accurate estimation most of the time. By using the software testing estimation techniques mentioned above, the accuracy of your estimation will increase in no time.

The Four Levels of Software Testing

Before Segue releases an application, it undergoes a thorough testing process to ensure that the app is working in the manner in which it was intended. There are four main stages of testing that need to be completed before a program can be cleared for use: unit testing, integration testing, system testing, and acceptance testing.

Unit Testing

During this first round of testing, the program is submitted to assessments that focus on specific units or components of the software to determine whether each one is fully functional. The main aim of this endeavor is to determine whether the application functions as designed. In this phase, a unit can refer to a function, individual program or even a procedure, and a White-box Testing method is usually used to get the job done. One of the biggest benefits of this testing phase is that it can be run every time a piece of code is changed, allowing issues to be resolved as quickly as

Software Testing Department of IT possible. It‘s quite common for software developers to perform unit tests before delivering software to testers for formal testing.

Integration Testing

Integration testing allows individuals the opportunity to combine all of the units within a program and test them as a group. This testing level is designed to find interface defects between the modules/functions. This is particularly beneficial because it determines how efficiently the units are running together. Keep in mind that no matter how efficiently each unit is running, if they aren‘t properly integrated, it will affect the functionality of the software program. In order to run these types of tests, individuals can make use of various testing methods, but the specific method that will be used to get the job done will depend greatly on the way in which the units are defined.

System Testing

System testing is the first level in which the complete application is tested as a whole. The goal at this level is to evaluate whether the system has complied with all of the outlined requirements and to see that it meets Quality Standards. System testing is undertaken by independent testers who haven‘t played a role in developing the program. This testing is performed in an environment that closely mirrors production. System Testing is very important because it verifies that the application meets the technical, functional, and business requirements that were set by the customer.

Software Testing Department of IT

Acceptance Testing

The final level, Acceptance testing (or User Acceptance Testing), is conducted to determine whether the system is ready for release. During the Software development life cycle, requirements changes can sometimes be misinterpreted in a fashion that does not meet the intended needs of the users. During this final phase, the user will test the system to find out whether the application meets their business‘ needs. Once this process has been completed and the software has passed, the program will then be delivered to production.

Software is also an entity. Just like developing software involves a sequences of steps, testing also has steps which should be executed in a definite sequence.

This phenomenon of executing the testing activities in a systematic and planned way is called testing life cycle.

Software Testing Department of IT

Below are the phases of Software Testing:

1. Requirements phase 2. Planning Phase 3. Analysis phase 4. Design Phase 5. Implementation Phase 6. Execution Phase 7. Conclusion Phase 8. Closure Phase

#1. Requirement Phase:

During this phase of STLC, analyze and study the requirements. Have brain storming sessions with other teams and try to find out whether the requirements are testable or not. This phase helps to identify the scope of the testing. If any feature is not testable, communicate it during this phase so that the mitigation strategy can be planned.

#2. Planning Phase:

In practical scenarios, Test planning is the first step of the testing process. In this phase we identify the activities and resources which would help to meet the testing objectives. During planning we also try to identify the metrics, the method of gathering and tracking those metrics.

Software Testing Department of IT

On what basis the planning is done? Only requirements?

The answer is NO. Requirements do form one of the bases but there are 2 other very important factors which influence test planning. These are:

– Test strategy of the organization. – Risk analysis / Risk Management and mitigation.

#3. Analysis Phase:

This STLC phase defines ―WHAT‖ to be tested. We basically identify the test conditions through the requirements document, product risks and other test basis. The test condition should be traceable back to the requirement. There are various factors which effect the identification of test conditions:

– Levels and depth of testing – Complexity of the product – Product and project risks – Software development life cycle involved. – Test management – Skills and knowledge of the team. – Availability of the stakeholders.

We should try to write down the test conditions in a detailed way. For example, for an e- commerce web application, you can have a test condition as ―User should be able to make a payment‖. Or you can detail it out by saying ―User should be able to make payment through NEFT, debit card and credit card‖. The most important advantage of writing the detailed test condition is that it increases the test coverage, since the test cases will be written on the basis of the test condition, these details will trigger to write more detailed test cases which will eventually increase the coverage. Also identify the exit criteria of the testing, i.e determine some conditions when you will stop the testing.

#4. Design Phase:

This phase defines ―HOW‖ to test. This phase involves the following tasks:

– Detail the test condition. Break down the test conditions into multiple sub conditions to increase coverage. – Identify and get the test data – Identify and set up the test environment. – Create the requirement traceability metrics – Create the test coverage metrics.

#5. Implementation Phase:

Software Testing Department of IT

The major task in this STLC phase is of creation of the detailed test cases. Prioritize the test cases also identify which test case will become part of the regression suite. Before finalizing the test case, It is important to carry out the review to ensure the correctness of the test cases. Also don‘t forget to take the sign off of the test cases before actual execution starts. If your project involves automation, identify the candidate test cases for automation and proceed for scripting the test cases. Don‘t forget to review them!

#6. Execution Phase:

As the name suggests, this is the Software Testing Life Cycle phase where the actual execution takes place. But before you start your execution, make sure that your entry criterion is met. Execute the test cases, log defects in case of any discrepancy. Simultaneously fill your traceability metrics to track your progress.

#7. Conclusion Phase:

This STLC phase concentrates on the exit criteria and reporting. Depending on your project and stakeholders choice, you can decide on reporting whether you want to send out a daily report of weekly report etc. There are different types of reports (DSR – Daily status report, WSR – Weekly status reports) which you can send, but the important point is, the content of the report changes and depends upon whom you are sending your reports. If Project managers belong to testing background then they are more interested in the technical aspect of the project, so include the technical things in your report (number of test cases passed, failed, defects raised, severity 1 defects etc.). But if you are reporting to upper stakeholders, they might not be interested in the technical things so report them about the risks that have been mitigated through the testing.

#8. Closure Phase:

Tasks for the closure activities include the following:

– Check for the completion of the test. Whether all the test cases are executed or mitigated deliberately. Check there are no severity 1 defects opened. – Do lessons learnt meeting and create lessons learnt document.( Include what went well, where are the scope of improvements and what can be improved)

STLC Phases and Activities Phase Activity Deliverables Necessity

You review the software Requirements/Design  ‘Review Defect’ requirements/design Review Reports Curiosity (Well, if they exist.)

Once you have gathered a  Test Plan Test Planning Farsightedness general idea of what needs  Test Estimation

Software Testing Department of IT

to be tested, you ‘plan’ for  Test Schedule the tests.

You design/ detail your tests on the basis of  Test Cases/Test detailed Scripts/Test Data Test Designing requirements/design of  Requirements Creativity the software (sometimes, Traceability Matrix on the basis of your imagination).

You setup the test environment (server/ Test Environment client/ network, etc) with  Test Environment Setup Rich company the goal of replicating the end-users’ environment.

You execute your Test  Test Results Cases/ Scripts in the Test (Incremental) Test Execution Patience Environment to see  Defect Reports whether they pass.

  Test Results (Final)

 Test Metrics  Test Closure Report You prepare various  Who Worked Late & reports for various on Weekends Test Reporting stakeholders. Diplomacy (WWLW) Report [Depending on how fussy your Management is]

Software Testing Department of IT

Unit -2

Software development and life cycle model

Quality control and quality assurance:

What is Quality?

Quality is meeting the requirement, expectation, and needs of the customer being free from defects, lacks and substantial variants. There are standards needs to follow to satisfy the customer requirements.

What is Assurance?

Assurance is provided by organization management; it means giving a positive declaration on a product which obtains confidence for the outcome. It gives a security that the product will work without any glitches as per the expectations or requests.

What is Quality Assurance?

Quality Assurance is known as QA and focuses on preventing defect. Quality Assurance ensures that the approaches, techniques, methods and processes are designed for the projects are implemented correctly. Quality assurance activities monitor and verify that the processes used to manage and create the deliverables have been followed and are operative.

Quality Assurance is a proactive process and is Prevention in nature. It recognizes flaws in the process. Quality Assurance has to complete before Quality Control.

Software Testing Department of IT

 The function of software quality that assures that the standards, processes, and procedures are appropriate for the project and are correctly implemented. Statistical Tools & Techniques can be applied in both Quality Assurance & Quality Control. When they are applied to processes (process inputs & operational parameters), they are called Statistical Process Control (SPC) & it becomes the part of Quality Assurance.

What is Quality Control?

Quality Control is known as QC and focuses on identifying defect. QC ensures that the approaches, techniques, methods and processes are designed in the project are following correctly. QC activities monitor and verify that the project deliverables meet the defined quality standards. Quality Control is a reactive process and is detection in nature.. It recognizes the defects. Quality Control has to complete after Quality Assurance.

 The function of software quality that checks that the project follows its standards, processes, and procedures, and that the project produces the required internal and external (deliverable) products. When statistical tools & techniques are applied to finished products (process outputs), they are called as Statistical Quality Control (SQC) & comes under Quality Control.

Difference between quality assurance process and quality control

Many people think QA and QC are same and interchangeable but this is not true. Both are tightly linked and sometimes it is very difficult to identify the differences. Fact is both are related to each other but they are different in origins. QA and QC both are part of Quality Management however QA is focusing on preventing defect while QC is focusing on identifying the defect.

Quality Assurance:

 It is a process which deliberate on providing assurance that quality request will be achieved.  A QA aim is to prevent the defect.  QA is the technique of managing the quality.  QA does not involve executing the program.  QA is the process to create the deliverables.

Quality Control:

 QC is a process which deliberates on fulfilling the quality request.  A QC aim is to identify and improve the defects.  QC is method to verify the quality.  QCalways involves executing the program.

Software Testing Department of IT

 QC is the process to verify that deliverables

Quality Assurance Quality Control Quality Assurance is a part of quality Quality Control is a part of quality management process which concentrate management process which concentrates on providing confidence that quality on fulfilling the quality requirements. requirements will be fulfilled Quality Assurance is a set of activities Quality Control is a set of activities for ensuring quality in the processes by for ensuring quality in products. The which products are developed. activities focus on identifying defects in the actual products produced. Quality Assurance is the process of Quality Control is used to verify the quality managing for quality; of the output

The goal of Quality Assurance is to prevent The goal of Quality Control is to identify the buy provigil fast introducing defects in the defects in the software application after it is software application which help to developed. improve the development and testing processes.

QA is Pro-active means it identifies QC is Reactive means it identifies the weaknesses in the processes. defects and also corrects the defects or bugs also.

It does not involve executing the program It always involves executing the program or or code. code.

All peoples who are involved in the Testing team is responsible for Quality developing software application as control. responsible for the quality assurance.

Quality Assurance is process oriented Quality Control is product oriented

Quality Assurance basically aim to Quality Control basically aim to detection of prevention of defects to improve the defects to improve the quality. quality.

It identifies weakness in processes to It identifies defects to be fixed.

Software Testing Department of IT

Quality Assurance Quality Control improve them.

Verification is an example of Quality Validation/Software Testing is an example Assurance. of Quality Control.

It is a staff function. It is a line function.

It is done before Quality Control. It is done only after Quality Assurance activity is completed.

Quality Assurance means Planning done Quality Control Means Action has taken on for doing a process. the process by execute them.

Verification and validation testing:

What is Verification?

Definition: The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase.

Verification is a static practice of verifying documents, design, code and program. It includes all the activities associated with producing high quality software: inspection, design analysis and specification analysis. It is a relatively objective process.

Verification will help to determine whether the software is of high quality, but it will not ensure that the system is useful. Verification is concerned with whether the system is well-engineered and error-free.

Methods of Verification : Static Testing

 Walkthrough  Inspection  Review

What is Validation?

Definition: The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements.

Software Testing Department of IT

Validation is the process of evaluating the final product to check whether the software meets the customer expectations and requirements. It is a dynamic mechanism of validating and testing the actual product.

Methods of Validation : Dynamic Testing

 Testing  End Users

Difference between Verification and Validation

The distinction between the two terms is largely to do with the role of specifications.

Validation is the process of checking whether the specification captures the customer‘s needs. ―Did I build what I said I would?‖

Verification is the process of checking that the software meets the specification. ―Did I build what I need?‖

Verification Validation

1. Verification is a static practice of verifying 1. Validation is a dynamic mechanism of documents, design, code and program. validating and testing the actual product.

2. It does not involve executing the code. 2. It always involves executing the code.

3. It is human based checking of documents 3. It is computer based execution of program. and files.

4. Validation uses methods like black box 4. Verification uses methods like inspections, (functional) testing, gray box testing, and

Software Testing Department of IT reviews, walkthroughs, and Desk-checking etc. white box (structural) testing etc.

5. Validation is to check whether software 5. Verification is to check whether the meets the customer expectations and software conforms to specifications. requirements.

6. It can catch errors that validation cannot 6. It can catch errors that verification cannot catch. It is low level exercise. catch. It is High Level Exercise.

7. Target is requirements specification, 7. Target is actual product-a unit, a module, a application and software architecture, high bent of integrated modules, and effective final level, complete design, and database design product. etc.

8. Verification is done by QA team to ensure 8. Validation is carried out with the that the software is as per the specifications in involvement of testing team. the SRS document.

9. It generally comes first-done before 9. It generally follows after verification. validation.

Process model to represent different phases in software testing:

Software Testing Department of IT

Software Process

A software process (also known as software methodology) is a set of related activities that leads to the production of the software. These activities may involve the development of the software from the scratch, or, modifying an existing system.

Any software process must include the following four activities:

1. Software specification (or requirements engineering): Define the main functionalities of the software and the constrains around them. 2. Software design and implementation: The software is to be designed and programmed. 3. Software verification and validation: The software must conforms to its specification and meets the customer needs. 4. Software evolution (software maintenance): The software is being modified to meet customer and market requirements changes.

Software Testing Department of IT

In practice, they include sub-activities such as requirements validation, architectural design, unit testing, …etc.

There are also supporting activities such as configuration and change management, quality assurance, project management, user experience.

Along with other activities aim to improve the above activities by introducing new techniques, tools, following the best practice, process standardization (so the diversity of software processes is reduced), etc.

When we talk about a process, we usually talk about the activities in it. However, a process also includes the process description, which includes:

1. Products: The outcomes of an activity. For example, the outcome of architectural design maybe a model for the software architecture. 2. Roles: The responsibilities of the people involved in the process. For example, the project manager, programmer, etc. 3. Pre and post conditions: The conditions that must be true before and after an activity. For example, the pre-condition of the architectural design is the requirements have been approved by the customer, while the post condition is the diagrams describing the architectural have been reviewed.

Software process is complex; it relies on making decisions. There‘s no ideal process and most organizations have developed their own software process.

For example, an organization works on critical systems has a very structured process, while with business systems, with rapidly changing requirements, a less formal, flexible process is likely to be more effective.

Software Process Models

A software process model is a simplified representation of a software process. Each model represents a process from a specific perspective.

Prototyping

A prototype is a version of a system or part of the system that‘s developed quickly to check the customer‘s requirements or feasibility of some design decisions.

So, a prototype is useful when a customer or developer is not sure of the requirements, or of algorithms, efficiency, business rules, response time, etc.

In prototyping, the client is involved throughout the development process, which increases the likelihood of client acceptance of the final implementation.

Software Testing Department of IT

While some prototypes are developed with the expectation that they will be discarded, it is possible in some cases to evolve from prototype to working system.

A software prototype can be used:

[1] In the requirements engineering, a prototype can help with the elicitation and validation of system requirements.

It allows the users to experiment with the system, and so, refine the requirements. They may get new ideas for requirements, and find areas of strength and weakness in the software.

Furthermore, as the prototype is developed, it may reveal errors and in requirements. The specification maybe then modified to reflect the changes.

[2] In the system design, a prototype can help to carry out deign experiments to check the feasibility of a proposed design.

For example, a database design may be prototype-d and tested to check it supports efficient data access for the most common user queries.

The process of prototype development

The phases of a prototype are:

1. Establish objectives: The objectives of the prototype should be made explicit from the start of the process. Is it to validate system requirements, or demonstrate feasibility, etc. 2. Define prototype functionality: Decide what are the inputs and the expected output from a prototype. To reduce the prototyping costs and accelerate the delivery schedule, you may ignore some functionality, such as response time and memory utilization unless they are relevant to the objective of the prototype.

Software Testing Department of IT

3. Develop the prototype: The initial prototype is developed that includes only user interfaces. 4. Evaluate the prototype: Once the users are trained to use the prototype, they then discover requirements errors. Using the feedback both the specifications and the prototype can be improved. If changes are introduced, then a repeat of steps 3 and 4 may be needed.

Prototyping is not a standalone, complete development methodology, but rather an approach to be used in the context of a full methodology (such as incremental, spiral, etc).

Incremental Development

Incremental development is based on the idea of developing an initial implementation, exposing this to user feedback, and evolving it through several versions until an acceptable system has been developed.

The activities of a process are not separated but interleaved with feedback involved across those activities

Each system increment reflects a piece of the functionality that is needed by the customer. Generally, the early increments of the system should include the most important or most urgently required functionality.

This means that the customer can evaluate the system at early stage in the development to see if it delivers what’s required. If not, then only the current increment has to be changed and, possibly, new functionality defined for later increments.

Life cycle models:

Software Testing Department of IT

A software development life cycle (SDLC) model is a conceptual framework describing all activities in a software development project from planning to maintenance. This process is associated with several models, each including a variety of tasks and activities.

Software development is a cumbersome activity requiring proper identification of requirements, their implementation, and software deployment. However, the activities do not end there. After the distribution of the software, proper maintenance has to be provided in a timely manner. This term is also known as software development process model.

Testing is an integral part of software development life cycle. Various models or approaches are used in the software development process where each model has its own advantages and disadvantages. Choosing a particular model depends on the project deliverables and complexity of the project.

Now Let us go through the various software testing models and their benefits:

Waterfall Model:

The waterfall model is a sequential approach, where each fundamental activity of a process represented as a separate phase, arranged in linear order.

In the waterfall model, you must plan and schedule all of the activities before starting working on them (plan-driven process).

The Waterfall Model was the first Process Model to be introduced. It is also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases.

The Waterfall model is the earliest SDLC approach that was used for software development.

The waterfall Model illustrates the software development process in a linear sequential flow. This means that any phase in the development process begins only if the previous phase is complete. In this waterfall model, the phases do not overlap.

Waterfall Model - Design

Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate phases. In this Waterfall model, typically, the outcome of one phase acts as the input for the next phase sequentially.

The sequential phases in Waterfall model are −

Software Testing Department of IT

 Requirement Gathering and analysis − All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification document.  System Design − The requirement specifications from first phase are studied in this phase and the system design is prepared. This system design helps in specifying hardware and system requirements and helps in defining the overall system architecture.  Implementation − With inputs from the system design, the system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality, which is referred to as Unit Testing.  Integration and Testing − All the units developed in the implementation phase are integrated into a system after testing of each unit. Post integration the entire system is tested for any faults and failures.  Deployment of system − Once the functional and non-functional testing is done; the product is deployed in the customer environment or released into the market.  Maintenance − There are some issues which come up in the client environment. To fix those issues, patches are released. Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the customer environment.

All these phases are cascaded to each other in which progress is seen as flowing steadily downwards (like a waterfall) through the phases. The next phase is started only after the defined set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model". In this model, phases do not overlap.

Waterfall Model - Application

Every software developed is different and requires a suitable SDLC approach to be followed based on the internal and external factors. Some situations where the use of Waterfall model is most appropriate are −

 Requirements are very well documented, clear and fixed.  Product definition is stable.  Technology is understood and is not dynamic.  There are no ambiguous requirements.  Ample resources with required expertise are available to support the product.  The project is short.

Waterfall Model - Advantages

The advantages of waterfall development are that it allows for departmentalization and control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process model phases one by one.

Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order.

Software Testing Department of IT

Some of the major advantages of the Waterfall Model are as follows −

 Simple and easy to understand and use  Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.  Phases are processed and completed one at a time.  Works well for smaller projects where requirements are very well understood.  Clearly defined stages.  Well understood milestones.  Easy to arrange tasks.  Process and results are well documented.

Waterfall Model - Disadvantages

The disadvantage of waterfall development is that it does not allow much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-documented or thought upon in the concept stage.

The major disadvantages of the Waterfall Model are as follows −

 No working software is produced until late during the life cycle.  High amounts of risk and uncertainty.  Not a good model for complex and object-oriented projects.  Poor model for long and ongoing projects.  Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and uncertainty is high with this process model.  It is difficult to measure progress within stages.  Cannot accommodate changing requirements.  Adjusting scope during the life cycle can end a project.  Integration is done as a "big-bang. at the very end, which doesn't allow identifying any technological or business bottleneck or challenges early.

Software Testing Department of IT

The Waterfall Model

The Nature of Waterfall Phases

In principle, the result of each phase is one or more documents that should be approved and the next phase shouldn‘t be started until the previous phase has completely been finished.

In practice, however, these phases overlap and feed information to each other. For example, during design, problems with requirements can be identified, and during coding, some of the design problems can be found, etc.

The software process therefore is not a simple linear but involves feedback from one phase to another. So, documents produced in each phase may then have to be modified to reflect the changes made.

When to Use?

In principle, the waterfall model should only be applied when requirements are well understood and unlikely to change radically during development as this model has a relatively rigid structure which makes it relatively hard to accommodate change when the process in underway.

Spiral Model:

The spiral model is a risk-driven where the process is represented as spiral rather than a sequence of activities.It was designed to include the best features from the waterfall and prototyping models, and introduces a new component; risk-assessment.

Software Testing Department of IT

Each loop (from review till service — see figure below) in the spiral represents a phase. Thus the first loop might be concerned with system feasibility, the next loop might be concerned with the requirements definition, the next loop with system design, and so on.

Spiral Model - Design

The spiral model has four phases. A software project repeatedly passes through these phases in iterations called Spirals.

Identification

This phase starts with gathering the business requirements in the baseline spiral. In the subsequent spirals as the product matures, identification of system requirements, subsystem requirements and unit requirements are all done in this phase.

This phase also includes understanding the system requirements by continuous communication between the customer and the system analyst. At the end of the spiral, the product is deployed in the identified market.

Design

The Design phase starts with the conceptual design in the baseline spiral and involves architectural design, logical design of modules, physical product design and the final design in the subsequent spirals.

Construct or Build

The Construct phase refers to production of the actual software product at every spiral. In the baseline spiral, when the product is just thought of and the design is being developed a POC (Proof of Concept) is developed in this phase to get customer feedback.

Then in the subsequent spirals with higher clarity on requirements and design details a working model of the software called build is produced with a version number. These builds are sent to the customer for feedback.

Evaluation and Risk Analysis

Risk Analysis includes identifying, estimating and monitoring the technical feasibility and management risks, such as schedule slippage and cost overrun. After testing the build, at the end of first iteration, the customer evaluates the software and provides feedback.Based on the customer evaluation, the software development process enters the next iteration and subsequently follows the linear approach to implement the feedback suggested by the customer. The process of iterations along the spiral continues throughout the life of the software.

Software Testing Department of IT

Spiral Model Application

The Spiral Model is widely used in the software industry as it is in sync with the natural development process of any product, i.e. learning with maturity which involves minimum risk for the customer as well as the development firms.

The following pointers explain the typical uses of a Spiral Model −

 When there is a budget constraint and risk evaluation is important.  For medium to high-risk projects.  Long-term project commitment because of potential changes to economic priorities as the requirements change with time.  Customer is not sure of their requirements which is usually the case.  Requirements are complex and need evaluation to get clarity.  New product line which should be released in phases to get enough customer feedback.  Significant changes are expected in the product during the development cycle.

Spiral Model - Pros and Cons

The advantage of spiral lifecycle model is that it allows elements of the product to be added in, when they become available or known. This assures that there is no conflict with previous requirements and design.

This method is consistent with approaches that have multiple software builds and releases which allows making an orderly transition to a maintenance activity. Another positive aspect of this method is that the spiral model forces an early user involvement in the system development effort.

On the other side, it takes a very strict management to complete such products and there is a risk of running the spiral in an indefinite loop. So, the discipline of change and the extent of taking change requests is very important to develop and deploy the product successfully.

The advantages of the Spiral SDLC Model are as follows −

 Changing requirements can be accommodated.  Allows extensive use of prototypes.  Requirements can be captured more accurately.  Users see the system early.  Development can be divided into smaller parts and the risky parts can be developed earlier which helps in better risk management.

The disadvantages of the Spiral SDLC Model are as follows −

 Management is more complex.  End of the project may not be known early.  Not suitable for small or low risk projects and could be expensive for small projects.

Software Testing Department of IT

 Process is complex  Spiral may go on indefinitely.  Large number of intermediate stages requires excessive documentation.

The spiral model

Each loop in the spiral is split into four sectors:

1. Objective setting: The objectives and risks for that phase of the project are defined. 2. Risk assessment and reduction: For each of the identified project risks, a detailed analysis is conducted, and steps are taken to reduce the risk. For example, if there’s a risk that the requirements are inappropriate, a prototype may be developed. 3. Development and validation: After risk evaluation, a process model for the system is chosen. So if the risk is expected in the user interface then we must prototype the user interface. If the risk is in the development process itself then use the waterfall model. 4. Planning: The project is reviewed and a decision is made whether to continue with a further loop or not.

Spiral model has been very influential in helping people think about iteration in software processes and introducing the risk-driven approach to development. In practice, however, the model is rarely used.

Iterative Development:

Iterative development model aims to develop a system through building small portions of all the features, across all components. We build a product which meets the initial scope and release it

Software Testing Department of IT quickly for customer feedback. An early version with limited features important to establish market and get customer feedback.In each increment, a slice of system features is delivered, passing through the requirements till the deployment.

Iterative Model - Design

Iterative process starts with a simple implementation of a subset of the software requirements and iteratively enhances the evolving versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added. The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental).

The following illustration is a representation of the Iterative and Incremental model −

Iterative and Incremental development is a combination of both iterative design or iterative method and incremental build model for development. "During software development, more than one iteration of the software development cycle may be in progress at the same time." This process may be described as an "evolutionary acquisition" or "incremental build" approach."

In this incremental model, the whole requirement is divided into various builds. During each iteration, the development module goes through the requirements, design, implementation and

Software Testing Department of IT testing phases. Each subsequent release of the module adds function to the previous release. The process continues till the complete system is ready as per the requirement.

The key to a successful use of an iterative software development lifecycle is rigorous validation of requirements, and verification & testing of each version of the software against those requirements within each cycle of the model. As the software evolves through successive cycles, tests must be repeated and extended to verify each version of the software.

The phases of iterative development are:

1. Inception: The goal is to establish a business case for the system. We should identify all the external entities that will interact with the system, and define these interactions. Then, uses this information to assess the contribution that the system makes to the business. If the contribution is minor, then the project may be cancelled. 2. Elaboration: We develop an understanding of the problem domain and architecture framework, develop the project plan, and identify risks. 3. Construction: Incrementally fills-in the architecture with production-ready code produced from analysis, design, implementation, and testing of the requirements. The components of the system are dependent on each other and they’re developed in parallel and integrated during this phase. On the completion of this phase, you should have a complete working software. 4. Transition: We deliver the system into the production operating environment.

Iterative Model - Application

Like other SDLC models, Iterative and incremental development has some specific applications in the software industry. This model is most often used in the following scenarios −

 Requirements of the complete system are clearly defined and understood.  Major requirements must be defined; however, some functionalities or requested enhancements may evolve with time.  There is a time to the market constraint.  A new technology is being used and is being learnt by the development team while working on the project.  Resources with needed skill sets are not available and are planned to be used on contract basis for specific iterations.  There are some high-risk features and goals which may change in the future.

Iterative Model - Pros and Cons

The advantage of this model is that there is a working model of the system at a very early stage of development, which makes it easier to find functional or design flaws. Finding issues at an early stage of development enables to take corrective measures in a limited budget.

Software Testing Department of IT

The disadvantage with this SDLC model is that it is applicable only to large and bulky software development projects. This is because it is hard to break a small software system into further small serviceable increments/modules.

The advantages of the Iterative and Incremental SDLC Model are as follows −

 Some working functionality can be developed quickly and early in the life cycle.  Results are obtained early and periodically.  Parallel development can be planned.  Progress can be measured.  Less costly to change the scope/requirements.  Testing and debugging during smaller iteration is easy.  Risks are identified and resolved during iteration; and each iteration is an easily managed milestone.  Easier to manage risk - High risk part is done first.  With every increment, operational product is delivered.  Issues, challenges and risks identified from each increment can be utilized/applied to the next increment.  Risk analysis is better.  It supports changing requirements.  Initial Operating time is less.  Better suited for large and mission-critical projects.  During the life cycle, software is produced early which facilitates customer evaluation and feedback.

The disadvantages of the Iterative and Incremental SDLC Model are as follows −

 More resources may be required.  Although cost of change is lesser, but it is not very suitable for changing requirements.  More management attention is required.  System architecture or design issues may arise because not all requirements are gathered in the beginning of the entire life cycle.  Defining increments may require definition of the complete system.  Not suitable for smaller projects.  Management complexity is more.  End of project may not be known which is a risk.  Highly skilled resources are required for risk analysis.  Projects progress is highly dependent upon the risk analysis phase.

V Model Prototyping:

The V-model is an SDLC model where execution of processes happens in a sequential manner in a V-shape. It is also known as Verification and Validation model.

The V-Model is an extension of the waterfall model and is based on the association of a testing phase for each corresponding development stage. This means that for every single phase in the

Software Testing Department of IT development cycle, there is a directly associated testing phase. This is a highly-disciplined model and the next phase starts only after completion of the previous phase.

V-Model - Design

Under the V-Model, the corresponding testing phase of the development phase is planned in parallel. So, there are Verification phases on one side of the ‗V‘ and Validation phases on the other side. The Coding Phase joins the two sides of the V-Model.

The following illustration depicts the different phases in a V-Model of the SDLC.

V-Model - Verification Phases

There are several Verification phases in the V-Model, each of these are explained in detail below.

Business Requirement Analysis

This is the first phase in the development cycle where the product requirements are understood from the customer‘s perspective. This phase involves detailed communication with the customer to understand his expectations and exact requirement. This is a very important activity and needs to be managed well, as most of the customers are not sure about what exactly they need. The acceptance test design planning is done at this stage as business requirements can be used as an input for acceptance testing.

Software Testing Department of IT

System Design

Once you have the clear and detailed product requirements, it is time to design the complete system. The system design will have the understanding and detailing the complete hardware and communication setup for the product under development. The system test plan is developed based on the system design. Doing this at an earlier stage leaves more time for the actual test execution later.

Architectural Design

Architectural specifications are understood and designed in this phase. Usually more than one technical approach is proposed and based on the technical and financial feasibility the final decision is taken. The system design is broken down further into modules taking up different functionality. This is also referred to as High Level Design (HLD).

The data transfer and communication between the internal modules and with the outside world (other systems) is clearly understood and defined in this stage. With this information, integration tests can be designed and documented during this stage.

Module Design

In this phase, the detailed internal design for all the system modules is specified, referred to as Low Level Design (LLD). It is important that the design is compatible with the other modules in the system architecture and the other external systems. The unit tests are an essential part of any development process and helps eliminate the maximum faults and errors at a very early stage. These unit tests can be designed at this stage based on the internal module designs.

Coding Phase

The actual coding of the system modules designed in the design phase is taken up in the Coding phase. The best suitable programming language is decided based on the system and architectural requirements.

The coding is performed based on the coding guidelines and standards. The code goes through numerous code reviews and is optimized for best performance before the final build is checked into the repository.

Validation Phases

The different Validation Phases in a V-Model are explained in detail below.

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.

Software Testing Department of IT

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.

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 this system test execution.

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.

V- Model ─ Application

V- Model application is almost the same as the waterfall model, as both the models are of sequential type. Requirements have to be very clear before the project starts, because it is usually expensive to go back and make changes. This model is used in the medical development field, as it is strictly a disciplined domain.

The following pointers are some of the most suitable scenarios to use the V-Model application.

 Requirements are well defined, clearly documented and fixed.  Product definition is stable.  Technology is not dynamic and is well understood by the project team.  There are no ambiguous or undefined requirements.  The project is short.

V-Model - Pros and Cons

The advantage of the V-Model method is that it is very easy to understand and apply. The simplicity of this model also makes it easier to manage. The disadvantage is that the model is not flexible to changes and just in case there is a requirement change, which is very common in today‘s dynamic world, it becomes very expensive to make the change.

The advantages of the V-Model method are as follows −

 This is a highly-disciplined model and Phases are completed one at a time.  Works well for smaller projects where requirements are very well understood.  Simple and easy to understand and use.

Software Testing Department of IT

 Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.

The disadvantages of the V-Model method are as follows −

 High risk and uncertainty.  Not a good model for complex and object-oriented projects.  Poor model for long and ongoing projects.  Not suitable for the projects where requirements are at a moderate to high risk of changing.  Once an application is in the testing stage, it is difficult to go back and change a functionality.  No working software is produced until late during the life cycle.

Rapid Application Development:

The RAD (Rapid Application Development) model is based on prototyping and iterative development with no specific planning involved. The process of writing the software itself involves the planning required for developing the product.

Rapid Application Development focuses on gathering customer requirements through workshops or focus groups, early testing of the prototypes by the customer using iterative concept, reuse of the existing prototypes (components), continuous integration and rapid delivery.

What is RAD?

Rapid application development is a software development methodology that uses minimal planning in favor of rapid prototyping. A prototype is a working model that is functionally equivalent to a component of the product.

In the RAD model, the functional modules are developed in parallel as prototypes and are integrated to make the complete product for faster product delivery. Since there is no detailed preplanning, it makes it easier to incorporate the changes within the development process.

RAD projects follow iterative and incremental model and have small teams comprising of developers, domain experts, customer representatives and other IT resources working progressively on their component or prototype.

The most important aspect for this model to be successful is to make sure that the prototypes developed are reusable.

Software Testing Department of IT

RAD Model Design

RAD model distributes the analysis, design, build and test phases into a series of short, iterative development cycles.

Following are the various phases of the RAD Model −

Business Modeling

The business model for the product under development is designed in terms of flow of information and the distribution of information between various business channels. A complete business analysis is performed to find the vital information for business, how it can be obtained, how and when is the information processed and what are the factors driving successful flow of information.

Data Modeling

The information gathered in the Business Modeling phase is reviewed and analyzed to form sets of data objects vital for the business. The attributes of all data sets is identified and defined. The relation between these data objects are established and defined in detail in relevance to the business model.

Process Modeling

The data object sets defined in the Data Modeling phase are converted to establish the business information flow needed to achieve specific business objectives as per the business model. The process model for any changes or enhancements to the data object sets is defined in this phase. Process descriptions for adding, deleting, retrieving or modifying a data object are given.

Application Generation

The actual system is built and coding is done by using automation tools to convert process and data models into actual prototypes.

Testing and Turnover

The overall testing time is reduced in the RAD model as the prototypes are independently tested during every iteration. However, the data flow and the interfaces between all the components need to be thoroughly tested with complete test coverage. Since most of the programming components have already been tested, it reduces the risk of any major issues.

The following illustration describes the RAD Model in detail.

Software Testing Department of IT

RAD Model Vs Traditional SDLC

The traditional SDLC follows a rigid process models with high emphasis on requirement analysis and gathering before the coding starts. It puts pressure on the customer to sign off the requirements before the project starts and the customer doesn‘t get the feel of the product as there is no working build available for a long time.

The customer may need some changes after he gets to see the software. However, the change process is quite rigid and it may not be feasible to incorporate major changes in the product in the traditional SDLC.

The RAD model focuses on iterative and incremental delivery of working models to the customer. This results in rapid delivery to the customer and customer involvement during the complete development cycle of product reducing the risk of non-conformance with the actual user requirements.

RAD Model - Application

RAD model can be applied successfully to the projects in which clear modularization is possible. If the project cannot be broken into modules, RAD may fail.

The following pointers describe the typical scenarios where RAD can be used −

Software Testing Department of IT

 RAD should be used only when a system can be modularized to be delivered in an incremental manner.  It should be used if there is a high availability of designers for modeling.  It should be used only if the budget permits use of automated code generating tools.  RAD SDLC model should be chosen only if domain experts are available with relevant business knowledge.  Should be used where the requirements change during the project and working prototypes are to be presented to customer in small iterations of 2-3 months.

RAD Model - Pros and Cons

RAD model enables rapid delivery as it reduces the overall development time due to the reusability of the components and parallel development. RAD works well only if high skilled engineers are available and the customer is also committed to achieve the targeted prototype in the given time frame. If there is commitment lacking on either side the model may fail.

The advantages of the RAD Model are as follows −

 Changing requirements can be accommodated.  Progress can be measured.  Iteration time can be short with use of powerful RAD tools.  Productivity with fewer people in a short time.  Reduced development time.  Increases reusability of components.  Quick initial reviews occur.  Encourages customer feedback.  Integration from very beginning solves a lot of integration issues.

The disadvantages of the RAD Model are as follows −

 Dependency on technically strong team members for identifying business requirements.  Only system that can be modularized can be built using RAD.  Requires highly skilled developers/designers.  High dependency on modeling skills.  Inapplicable to cheaper projects as cost of modeling and automated code generation is very high.  Management complexity is more.  Suitable for systems that are component based and scalable.  Requires user involvement throughout the life cycle.  Suitable for project requiring shorter development times.

Software Testing Department of IT

Unit 3 Software Testing Types

Software testing is an investigation conducted to provide stakeholders with information about the quality of the software product or service under test.[1] Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include the process of executing a program or application with the intent of finding software bugs (errors or other defects), and verifying that the software product is fit for use.

Software testing involves the execution of a software component or system component to evaluate one or more properties of interest. In general, these properties indicate the extent to which the component or system under test. A primary purpose of testing is to detect software failures so that defects may be discovered and corrected. Testing cannot establish that a product functions properly under all conditions, but only that it does not function properly under specific conditions. The scope of software testing often includes the examination of code as well as the execution of that code in various environments and conditions as well as examining the aspects of code: does it do what it is supposed to do and do what it needs to do

Various types of testing: Various types of software testing are performed to achieve different objectives when testing a software application. You can also read about different Software Testing Techniques which can be associated with various types of software testing.

1. White Box Testing: WHITE BOX TESTING (also known as Clear Box Testing, Open Box Testing, Glass Box Testing, Transparent Box Testing, Code-Based Testing or Structural Testing) is a software testing method in which the internal structure/design/implementation of the item being tested is known to the tester. The tester chooses inputs to exercise paths through the code and determines the appropriate outputs. Programming know-how and the implementation knowledge is essential. White box testing is testing beyond the user interface and into the nitty-gritty of a system.

This method is named so because the software program, in the eyes of the tester, is like a white/transparent box; inside which one clearly sees.

Software Testing Department of IT

White-box testing: Testing based on an analysis of the internal structure of the component or system. White-box test design technique: Procedure to derive and/or select test cases based on an analysis of the internal structure of a component or system. Example A tester, usually a developer as well, studies the implementation code of a certain field on a webpage, determines all legal (valid and invalid) AND illegal inputs and verifies the outputs against the expected outcomes, which is also determined by studying the implementation code.

White Box Testing is like the work of a mechanic who examines the engine to see why the car is not moving.

Levels Applicable To White Box Testing method is applicable to the following levels of software testing:

Unit Testing: For testing paths within a unit. Integration Testing: For testing paths between units. System Testing: For testing paths between subsystems. However, it is mainly applied to Unit Testing.

White-box test design techniques include the following code coverage criteria:

Control flow testing Data flow testing Branch testing Statement coverage Decision coverage Modified condition/decision coverage Prime path testing Path testing

White Box Testing Example

Consider the following piece of code

Printme (int a, int b) { //Printme is a function int result = a+ b; If (result> 0) Print ("Positive", result)

Software Testing Department of IT

Else Print ("Negative", result) } ------End of the source code The goal of White Box testing is to verify all the decision branches, loops, statements in the code.

To exercise the statements in the above code, White Box test cases would be

A = 1, B = 1 A = -1, B = -3

Advantages: Testing can be commenced at an earlier stage. One need not wait for the GUI to be available. Testing is more thorough, with the possibility of covering most paths.

Disadvantages: Since tests can be very complex, highly skilled resources are required, with a thorough knowledge of programming and implementation. Test script maintenance can be a burden if the implementation changes too frequently. Since this method of testing is closely tied to the application being tested, tools to cater to every kind of implementation/platform may not be readily available.

Under Static Testing code is not executed. Rather it manually checks the code, requirement documents, and design documents to find errors. Hence, the name "static".

Main objective of this testing is to improve the quality of software products by finding errors in early stages of the development cycle. This testing is also called as Non-execution technique or verification testing.

Static testing involves manual or automated reviews of the documents. This review, is done during initial phase of testing to catch Defect early in STLC. It examines work documents and provides review comments

Work document can be of following:

Requirement specifications Design document Source Code Test Plans Test Cases

Software Testing Department of IT

Test Scripts Help or User document Web Page content Under Dynamic Testing code is executed. It checks for functional behavior of software system, memory/cpu usage and overall performance of the system. Hence the name "Dynamic"

Main objective of this testing is to confirm that the software product works in conformance with the business requirements. This testing is also called as Execution technique or validation testing.

Dynamic testing executes the software and validates the output with the expected outcome. Dynamic testing is performed at all levels of testing and it can be either black or white box testing.

Dynamic Testing Techniques:

Static Testing Vs Dynamic Testing

Unit Testing: Under Unit Testing, individual units or modules is tested by the developers. It involves testing of source code by developers. Integration Testing: Individual modules are grouped together and tested by the developers. The purpose is to determine that modules are working as expected once they are integrated. System Testing: System Testing is performed on the whole system by checking whether the system or application meets the requirement specification document.

What is Black Box Testing? Black box testing is defined as a testing technique in which functionality of the Application Under Test (AUT) is tested without looking at the internal code structure, implementation details and knowledge of internal paths of the software. This type of testing is based entirely on software requirements and specifications.

What is BLACK Box Testing? Techniques, Example & Types

In Black Box Testing we just focus on inputs and output of the software system without bothering about internal knowledge of the software program.

The above Black-Box can be any software system you want to test. For Example, an operating system like Windows, a website like Google, a database like Oracle or even your own custom application. Under Black Box Testing, you can test these applications by just focusing on the inputs and outputs without knowing their internal code implementation.

Software Testing Department of IT

How to do Black Box Testing:

Here are the generic steps followed to carry out any type of Black Box Testing.

Initially, the requirements and specifications of the system are examined. Tester chooses valid inputs (positive test scenario) to check whether SUT processes them correctly. Also some invalid inputs (negative test scenario) are chosen to verify that the SUT is able to detect them. Tester determines expected outputs for all those inputs. Software tester constructs test cases with the selected inputs. The test cases are executed. Software tester compares the actual outputs with the expected outputs. Defects if any are fixed and re-tested. Types of Black Box Testing There are many types of Black Box Testing but the following are the prominent ones -

*Functional testing - This black box testing type is related to the functional requirements of a system; it is done by software testers.

*Non-functional testing - This type of black box testing is not related to testing of specific functionality, but non-functional requirements such as performance, scalability, usability. Regression testing - Regression Testing is done after code fixes, upgrades or any other system maintenance to check the new code has not affected the existing code.

Example

A tester, without knowledge of the internal structures of a website, tests the web pages by using a browser; providing inputs (clicks, keystrokes) and verifying the outputs against the expected outcome.

Black Box Testing Techniques

Following are the prominent Test Strategy amongst the many used in Black box Testing

Equivalence Class Testing: It is used to minimize the number of possible test cases to an optimum level while maintains reasonable test coverage.

Software Testing Department of IT

Boundary Value Testing: Boundary value testing is focused on the values at boundaries. This technique determines whether a certain range of values are acceptable by the system or not. It is very useful in reducing the number of test cases. It is most suitable for the systems where an input is within certain ranges. Decision Table Testing: A decision table puts causes and their effects in a matrix. There is a unique combination in each column.

Advantages

Tests are done from a user‘s point of view and will help in exposing discrepancies in the specifications. Tester need not know programming languages or how the software has been implemented. Tests can be conducted by a body independent from the developers, allowing for an objective perspective and the avoidance of developer-bias. Test cases can be designed as soon as the specifications are complete.

Disadvantages

Only a small number of possible inputs can be tested and many program paths will be left untested. Without clear specifications, which is the situation in many projects, test cases will be difficult to design. Tests can be redundant if the software designer/developer has already run a test case. Ever wondered why a soothsayer closes the eyes when foretelling events? So is almost the case in Black Box Testing necessary?

Software Testing is necessary because we all make mistakes. Some of those mistakes are unimportant, but some of them are expensive or dangerous. We need to check everything and anything we produce because things can always go wrong – humans make mistakes all the time.

Since we assume that our work may have mistaken, hence we all need to check our own work. However some mistakes come from bad assumptions and blind spots, so we might make the same mistakes when we check our own work as we made when we did it. So we may not notice the flaws in what we have done.

Ideally, we should get someone else to check our work because another person is more likely to spot the flaws.

There are several reasons which clearly tell us as why Software Testing is important and what are the major things that we should consider while testing of any product or application.

Software Testing Department of IT

Software testing is very important because of the following reasons:

Software testing is really required to point out the defects and errors that were made during the development phases.

Example: Programmers may make a mistake during the implementation of the software. There could be many reasons for this like lack of experience of the programmer, lack of knowledge of the programming language, insufficient experience in the domain, incorrect implementation of the algorithm due to complex logic or simply human error. It‘s essential since it makes sure that the customer finds the organization reliable and their satisfaction in the application is maintained. If the customer does not find the testing organization reliable or is not satisfied with the quality of the deliverable, then they may switch to a competitor organization. Sometimes contracts may also include monetary penalties with respect to the timeline and quality of the product. In such cases, if proper software testing may also prevent monetary losses. It is very important to ensure the Quality of the product. Quality product delivered to the customers helps in gaining their confidence. (Know more about Software Quality) As explained in the previous point, delivering good quality product on time builds the customer‘s confidence in the team and the organization. Testing is necessary in order to provide the facilities to the customers like the delivery of high quality product or software application which requires lower maintenance cost and hence results into more accurate, consistent and reliable results. High quality product typically has fewer defects and requires lesser maintenance effort, which in turn means reduced costs. Testing is required for an effective performance of software application or product. It‘s important to ensure that the application should not result into any failures because it can be very expensive in the future or in the later stages of the development. Proper testing ensures that bugs and issues are detected early in the life cycle of the product or application. If defects related to requirements or designs are detected late in the life cycle, it can be very expensive to fix them since this might require redesign, re-implementation and retesting of the application. It‘s required to stay in the business. Users are not inclined to use software that has bugs. They may not adopt a software if they are not happy with the stability of the application. In case of a product organization or startup which has only one product, poor quality of software may result in lack of adoption of the product and this may result in losses which the business may not recover from.

Software Testing Department of IT

When Should Software Be Tested? The earlier a part of the product can be tested, the cheaper it will be to find any problems that exist. If the parts of the application available at one stage of the process are known to work well and reliably, fewer problems will occur with integrating them or adding to them at laterstages than if all the testing is done at the end. However, it was also shown in that section that software products are traditionally only tested at the end: An explicit QA phase follows the development, then the software is released to beta testers before finally being opened up for general release.

Modern approaches to software project management recognize that this is deficient and aim to continually test all parts of the product at all times. This is the main difference between ―agile‖ projects and traditionally managed projects. Agile projects are organized in short stints called iterations (sometimes sprints). At every iteration, the requirements are reviewed; anything obsolete is dropped and any changes or necessary additions are made. The most important requirement is designed, implemented, and tested in that iteration. At the end of the iteration, the progress is reviewed and a decision made as to whether to add the newly developed feature to the product, or add requirements to make changes in future iterations. Testing is very unlikely to find certain types of defects. Even the combination of several different styles of testing is unlikely to find more than 75% of the total defects. Each individual type of testing, even when carefully executed with a high degree of skill, is unlikely to find more than 50% of the defects. Testing is relatively inefficient at finding defects, even assuming you could find all of them. You will potentially spend a very, very long time trying to find all the defects, especially the last few. You have no way of knowing in advance if all the defects have been found, or whether more remain in the system.

INTEGRATION TESTING is a level of software testing where individual units are combined and tested as a group. The purpose of this level of testing is to expose faults in the interaction between integrated units. Test drivers and test stubs are used to assist in Integration Testing.

Definition by ISTQB-

Integration Testing: Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems. See also component integration testing, system integration testing.

Component Integration Testing:Testing performed to expose defects in the interfaces and interaction between integrated components.

Software Testing Department of IT

System Integration Testing: Testing the integration of systems and packages; testing interfaces to external organizations (e.g. Electronic Data Interchange, Internet).

Analogy; During the process of manufacturing a ballpoint pen, the cap, the body, the tail and clip, the ink cartridge and the ballpoint are produced separately and unit tested separately. When two or more units are ready, they are assembled and Integration Testing is performed. For example, whether the cap fits into the body or not.

Method Any of Black Box Testing, White Box Testing and Gray Box Testing methods can be used. Normally, the method depends on your definition of ‗unit‘.

Tasks Integration Test Plan Prepare Review Rework Baseline Integration Test Cases/Scripts Prepare Review Rework Baseline Integration Test Perform

When is Integration Testing performed?

Integration Testing is the second level of testing performed after Unit Testing and before System Testing.

Who performs Integration Testing?

Developers themselves or independent testers perform Integration Testing.

Approaches; Big Bang is an approach to Integration Testing where all or most of the units are combined together and tested at one go. This approach is taken when the testing team receives the entire software in a bundle. So what is the difference between Big Bang Integration Testing and System Testing? Well, the former tests only the interactions between the units while the latter tests the entire system.

Software Testing Department of IT

Top Down is an approach to Integration Testing where top-level units are tested first and lower level units are tested step by step after that. This approach is taken when top-down development approach is followed. Test Stubs are needed to simulate lower level units which may not be available during the initial phases. Bottom Up is an approach to Integration Testing where bottom level units are tested first and upper-level units step by step after that. This approach is taken when bottom-up development approach is followed. Test Drivers are needed to simulate higher level units which may not be available during the initial phases. Sandwich/Hybrid is an approach to Integration Testing which is a combination of Top Down and Bottom Up approaches.

What is Scenario Testing? Scenario testing is done to make sure that the end to end functioning of software is working fine, or all the business process flows of the software are working fine. In scenario testing the testers put themselves in the end users shoes and figure out the real world scenarios or use cases which can be performed on the software by the end user. In scenario testing, testers take assistance from clients, stakeholders and developers to create test scenarios.

Scenario testing helps testers to explore how the software will work in the hands of an end user. Since scenario testing tests the business flow of the software, it helps in finding lot of defects which cannot be found with other types of testing.

Scenario testing is done by creating test scenarios which replicate the end users usage. A test scenario can be a independent test case or a series of test cases that follow each other. Test scenario is just a story which explains the usage of the software by any end user.

Importance of Scenario Testing: As you know that exhaustive testing of any software application is not possible because of the following reasons:

* Large number of data combinations. * Large number of possible paths in software.

It is because of this fact you always prioritize your testing efforts and focus on the most important areas, for that you use techniques like Boundary value analysis(BVA), Equivalence partitioning(EP), Risk based testing etc. however these techniques still do not guarantee bug free product.

By scenario testing you figure out the most important end-to-end transactions or the real use of the software applications which ensures that the software is working for the most common user

Software Testing Department of IT scenarios. It helps in finding lot of defects which cannot be found with other types of testing.

Scenario testing is very important for complex transactions and for studying end-to-end functioning of the program.

Why create Test Scenarios? Test Scenarios are created for following reasons;

Creating Test Scenarios ensures complete Test Coverage Test Scenarios can be approved by various stakeholders like Business Analyst, Developers, Customers to ensure the Application Under Test is thoroughly tested. It ensures that the software is working for the most common use cases. They serve as a quick tool to determine the testing work effort and accordingly create a proposal for the client or organize the workforce. They help determine the most important end-to-end transactions or the real use of the software applications. For studying the end-to-end functioning of the program, Test Scenario is critical. When not create Test Scenario? Test Scenarios may not be created when

The Application Under Test is complicated, unstable and there is a time crunch in the project. Projects that follow Agile Methodology like Scrum, Kanban may not create Test Scenarios. Test Scenario may not be created for a new bug fix or Regression Testing. In such cases, Test Scenarios must be already heavily documented in the previous test cycles. This is especially true for Maintenance projects.

How to create a Test Scenario; As a tester, you can follow these five steps to create Test Scenarios-

Step 1: Read the Requirement Documents like BRS, SRS, FRS, of the System Under Test (SUT). You could also refer uses cases, books, manual, etc. of the application to be tested.

Step 2: For each requirement, figure out possible users actions and objectives. Determine the technical aspects of the requirement. Ascertain possible scenarios of system abuse and evaluate users with hacker's mindset.

Step 3: After reading the Requirements Document and doing your due Analysis, list out different test scenarios that verify each feature of the software.

Software Testing Department of IT

Step 4: Once you have listed all possible Test Scenarios, a Traceability Matrix is created to verify that each & every requirement has a corresponding Test Scenario

Step 5: The scenarios created are reviewed by your supervisor. Later, they are also reviewed by other Stakeholders in the project.

Tips to Create Test Scenarios;

 Each Test Scenario should be tied to a minimum of one Requirement or User Story as per the Project Methodology.  Before creating a Test Scenario that verifies multiple Requirements at once, ensure you have a Test Scenario that checks that requirement in isolation.

Software Testing Department of IT

Unit-4

System and Acceptance Testing

System Testing

System testing is the type of testing to check the behavior of a complete and fully where to buy generic modafinil integrated software product based on the software requirements specification (SRS) document. The main focus of this testing is to evaluate Business / Functional / End-user requirements.

This is black box type of testing where external working of the software is evaluated with the help of requirement documents & it is totally based on Users point of view. For this type of testing do not required knowledge of internal design or structure or code.

This testing is to be carried out only after System Integration Testing is completed where both Functional & Non-Functional requirements are verified.

In the integration testing testers are concentrated on finding bugs/defects on integrated modules. But in the Software System Testing testers are concentrated on finding bugs/defects based on software application behavior, software design and expectation of end user.

Why system testing is important: a) In Software Development Life Cycle the System Testing is perform as the first level of testing where the System is tested as a whole. b) In this step of testing check if system meets functional requirement or not. c) System Testing enables you to test, validate and verify both the Application Architecture and Business requirements. d) The application/System is tested in an environment that particularly resembles the effective production environment where the application/software will be lastly deployed.

Generally, a separate and dedicated team is responsible for system testing. And, System Testing is performed on staging server which is similar to production server. So this means you are testing software application as good as production environment.

Different Hierarchical levels of testing:

As with almost any technical process, software testing has a prescribed order in which things should be done. Different levels of testing are used in the testing process; each level of testing aims to test different aspects of the system. The following is lists of software testing categories arranged in sequentially organize.

Software Testing Department of IT

Hierarchical levels of testing

Unit testing – Testing is done in the development process while developer completes the unit development. The object of this testing is to verify correctness of the module. The purpose of unit testing is to check that as individual parts are functioning as expected. Basically Unit testing is typically carried out by the developer.

Integration testing – System Integration Testing is started after the individual software modules are integrated as a group. A typical software project consists of multiple modules & these are developed by different developers. So in integration testing is focuses to check that after integrating modules Is two modules are communicating with each other or not. It is critical to test every module‘s effect on the entire program model. Most of the issues are observed in this type of testing.

System testing – This is the first time end to end testing of application on the complete and fully integrated software product before it is launch to the market.

Acceptance testing – User acceptance is a type of testing performed by the Client to certify the system with respect to the requirements that was agreed upon. This is beta testing of the product & evaluated by the actual end users. The main purpose of this testing is to validate the end to end business flow.

Entry Criteria for System Testing:

 Unit Testing should be finished.  Integration of modules should be fully integrated.  As per the specification document software development is completed.

Software Testing Department of IT

 Testing environment is available for testing (similar to Staging environment)

Types of System Tests:

What is Acceptance Testing?

Once the System Testing process is completed by the testing team and is signed-off, the entire Product/application is handed over to the customer/few users of customers/both, to test for its acceptability i.e., Product/application should be flawless in meeting both the critical and major Business requirements. Also, end-to-end business flows are verified similar as in real-time scenario.

The production-like environment will be the testing environment for Accepting Testing (Usually termed as Staging, Pre-Prod, Fail-Over, UAT environment).

Software Testing Department of IT

This is a black-box testing technique where only the functionality is verified to ensure that the product meets the specified acceptance criteria (no need for design/implementation knowledge).

Why Acceptance Tests?

Though System testing has been completed successfully, the Acceptance test is demanded by the customer. Tests conducted here are repetitive, as they would have been covered in System testing.

Then, why is this testing is conducted by customers?

This is because:

 To gain confidence in the product that is getting released to the market.  To ensure that the product is working in the way it has to.  To ensure that the product matches current market standards and is competitive enough with the other similar products in the market.

Types of Acceptance testing:

1) User Acceptance Testing (UAT)

UAT is to assess whether the Product is working for the user, correctly for the usage. Specific requirements which are quite often used by the end-users are primarily picked for the testing purpose. This is also termed as End-User Testing.

The term ―User‖ here signifies the end-users to whom the Product/application is intended and hence, testing is performed from the end-users perspective and from their point of view.

2) Business Acceptance Testing (BAT)

This is to assess whether the Product meets the business goals and purposes or not.

BAT mainly focuses on business benefits (finances) which are quite challenging due to the changing market conditions/advancing technologies so that the current implementation may have to undergo changes which result in extra budgets.

3) Contract Acceptance Testing (CAT)

This is a contract which specifies that once the Product goes live, within a predetermined period, the acceptance test must be performed and it should pass all the acceptance use cases.

Contract signed here is termed as Service Level Agreement (SLA), which includes the terms where the payment will be made only if the Product services are in-line with all the requirements, which means the contract is fulfilled.

Software Testing Department of IT

Sometimes, this contract may happen before the Product goes live. Either the ways, a contract should be well defined in terms of the period of testing, areas of testing, conditions on issues encountered at later stages, payments, etc.

4) Regulations/Compliance Acceptance Testing (RAT)

This is to assess whether the Product violates the rules and regulations that are defined by the government of the country where it is being released. This may be unintentional but will impact negatively on the business.

Usually, the developed Product/application that is intended to be released all over the world, has to undergo RAT, as different countries/regions have different rules and regulations defined by its governing bodies.

If any of the rules and regulations are violated for any country, then that country or the specific region in that country will not be allowed to use the Product and is considered as a Failure. Vendors of the Product will be directly responsible if the Product is released even though there is a violation.

5) Operational Acceptance Testing (OAT)

This is to assess the operational readiness of the Product and is a non-functional testing. It mainly includes testing of recovery, compatibility, maintainability, technical support availability, reliability, fail-over, localization etc.

Difference between System Testing and Acceptance Testing:

System Testing Acceptance Testing

1. System testing is end to end testing 1. Acceptance testing is functionality testing performed to check if the software can I buy performed to check if the software meets the provigil online meets the specified customer requirements. requirements.

2. Acceptance testing is performed by 2. System testing is performed by developers independent set of testers and also the and testers. stakeholders, clients.

3. System Testing can be both functional and 3. Acceptance testing is pure functional testing. non functional testing

4. In System testing , we test how the system is 4. In Acceptance testing we check if the system behaving a whole, the functionality and is meeting the business needs of the performed are checked. organization, usability of the product.

Software Testing Department of IT

5. It is performed with demo data and not the 5. It is performed with the actual real time data production data. ,production data.

6. In this testing we test the software for 6. Here we test the software for the user needs complete specification including hardware and and if user needs are met in the developed software, memory and number of users. software.

7. System Testing comprises of System Testing 7. Acceptance testing comprises of alpha and System Integration testing. testing and beta testing.

8. System testing is performed before the 8. Acceptance testing is performed after the Acceptance testing. System testing.

9. Acceptance testing involves functional 9. System testing involves non functional testing that is boundary value analysis, testing that is performance load and stress equivalence portioning and decision table testing. testing.

10. In System Testing , since it is performed by 10. Acceptance Testing contains more of group of testers, it would contain more negative positive test cases. test cases.

11. The defects found in system testing can be 11. The defects found in acceptance testing are fixed based on priorities. taken as failure product.

12. Here we test the system for all the possible 12. Here we check the system for random dummy inputs. inputs.

What is Functional Testing?

Functional Testing is the type of testing done against the business requirements of application. It is a black box type of testing.

It involves the complete integration system to evaluate the system‘s compliance with its specified requirements. Based on the functional specification document this type of testing is to be carried out. In actual testing, testers need to verify a specific action or function of the code. For functional testing either manual testing or automation tools can be used but functionality testing would be easier using manual testing only. Prior to non Functional testing the Functional testing would be executed first.

Five steps need to be keeping in mind in the Functional testing:

Software Testing Department of IT

1. Preparation of test data based on the specifications of functions 2. Business requirements are the inputs to functional testing 3. Based on functional specifications find out of output of the functions 4. The execution of test cases 5. Observe the actual and expected outputs

To carry out functional testing we have numerous tools available, here is the list of Functional testing tools.

In the types of functional testing following testing types should be cover:

 Unit Testing  Smoke testing  Sanity testing  Integration Testing  Interface Testing  System Testing  Regression Testing  UAT

What is non Functional Testing?

The non Functional Testing is the type of testing done against the non functional requirements. Most of the criteria are not consider in functional testing so it is used to check the readiness of a system. Non-functional requirements tend to be those that reflect the quality of the product, particularly in the context of the suitability perspective of its users. It can be started after the completion of Functional Testing. The non functional tests can be effective by using testing tools.

The testing of software attributes which are not related to any specific function or user action like performance, scalability, security or behavior of application under certain constraints.

Non functional testing has a great influence on customer and user satisfaction with the product. Non functional testing should be expressed in a testable way, not like ―the system should be fast‖ or ―the system should be easy to operate‖ which is not testable.

Basically in the non functional test is used to major non-functional attributes of software systems.

Functional Vs Non-Functional Testing:

Functional Testing Non-Functional Testing

Functional testing is performed using the Non-Functional testing checks the functional specification provided by the client Performance, reliability, scalability and other and verifies the system against the functional

Software Testing Department of IT requirements. non-functional aspects of the software system.

Non functional testing should be performed Functional testing is executed first after functional testing

Manual Testing or automation tools can be Using tools will be effective for this testing used for functional testing

Business requirements are the inputs to Performance parameters like speed, scalability functional testing are inputs to non-functional testing.

Functional testing describes what the product Nonfunctional testing describes how good the does product works

Easy to do Manual Testing Tough to do Manual Testing

Examples of Functional testing are Examples of Non-functional testing are

 Unit Testing  Performance Testing  Smoke Testing  Load Testing  Sanity Testing  Volume Testing  Integration Testing  Stress Testing  White box testing  Security Testing  Black Box testing  Installation Testing  User Acceptance testing  Penetration Testing  Regression Testing  Compatibility Testing  Migration Testing

What is Performance Testing?

Performance testing, a non-functional testing technique performed to determine the system parameters in terms of responsiveness and stability under various workload. Performance testing measures the quality attributes of the system, such as scalability, reliability and resource usage.

Performance Testing Techniques:

 Load testing - It is the simplest form of testing conducted to understand the behaviour of the system under a specific load. Load testing will result in measuring important business critical transactions and load on the database, application server, etc., are also monitored.  Stress testing - It is performed to find the upper limit capacity of the system and also to determine how the system performs if the current load goes well above the expected maximum.  Soak testing - Soak Testing also known as endurance testing, is performed to determine the system parameters under continuous expected load. During soak tests the parameters

Software Testing Department of IT

such as memory utilization is monitored to detect memory leaks or other performance issues. The main aim is to discover the system's performance under sustained use.  Spike testing - Spike testing is performed by increasing the number of users suddenly by a very large amount and measuring the performance of the system. The main aim is to determine whether the system will be able to sustain the workload.

Performance Testing Process:

Attributes of Performance Testing:

 Speed  Scalability  Stability  Reliability

Factors of Software Testing:

For designing Test Cases the following factors are considered:

1. Correctness 2. Negative 3. User Interface

Software Testing Department of IT

4. Usability 5. Performance 6. Security 7. Integration 8. Reliability 9. Compatibility

Correctness : Correctness is the minimum requirement of software, the essential purpose of testing. The tester may or may not know the inside details of the software module under test e.g. control flow, data flow etc.

Negative : In this factor we can check what the product it is not supposed to do.

User Interface : In UI testing we check the user interfaces. For example in a web page we may check for a button. In this we check for button size and shape. We can also check the navigation links.

Usability : Usability testing measures the suitability of the software for its users, and is directed at measuring the following factors with which specified users can achieve specified goals in particular environments.

1. Effectiveness : The capability of the software product to enable users to achieve specified goals with the accuracy and completeness in a specified context of use.

2. Efficiency : The capability of the product to enable users to expend appropriate amounts of resources in relation to the effectiveness achieved in a specified context of use. oftware Testing Methodologies: Learn QA Models

What is Software Testing Methodology?

Software Testing Methodology is defined as strategies and testing types used to certify that the Application Under Test meets client expectations. Test Methodologies include functional and non-functional testing to validate the AUT. Examples of Testing Methodologies are Unit Testing, Integration Testing, System Testing, Performance Testing etc. Each testing methodology has a defined test objective, test strategy, and deliverables.

Note: Since Software Testing is an integral part of any Development Methodology, many companies use the term Development Methodologies & Testing Methodologies colloquially. Hence Testing Methodologies could also refer to Waterfall, Agile and other QA models as against the above definition of Testing Methodologies. Discussion on various testing types does not add value to the readers. Hence, we will discuss the different development models.

In this tutorial, you will learn-

 Waterfall model

Software Testing Department of IT

 Iterative development  Agile methodology  Extreme programming  Which Software Methodology to choose?  How to setup software testing methodologies?

Waterfall Model

What is it?

In the waterfall model, software development progress through various phases like Requirements Analysis, Design etc - sequentially.

In this model, the next phase begins only when the earlier phase is completed.

What Is The Testing Approach?

The first phase in the waterfall model is the requirements phase in which all the project requirements are completely defined before starting the testing. During this phase, the test team brainstorms the scope of testing, test strategy and drafts a detailed test plan.

Only once the design of software is complete, the team will move on to execution of the test cases to ensure that the developed software behaves as it expected.

In this methodology, the testing team proceeds to the next phase only when the previous phase is completed.

Advantages

Software Testing Department of IT

This software Engineering model is very simple to plan and manage. Hence, projects, where requirements are clearly defined and stated beforehand, can be easily tested using a waterfall model.

Disadvantages

In the waterfall model, you can begin with the next phase only once the previous phase is completed. Hence, this model cannot accommodate unplanned events and uncertainty.

This methodology is not suitable for projects where the requirements change frequently.

Iterative development

What is it?

In this model, a big project is divided into small parts, and each part is subjected to multiple iterations of the waterfall model. At the end of an iteration, a new module is developed or an existing module is enhanced. This module is integrated into the software architecture and the entire system is tested all together

What is the testing Approach?

As soon as iteration is completed, the entire system is subjected to testing. Feedback from testing is immediately available and is incorporated in the next cycle. The testing time required in successive iteration can be reduced based on the experience gained from past iterations.

Advantages

The main advantage of iterative development is the test feedback is immediately available at the end of each cycle.

Disadvantages

This model increases communication overheads significantly since, at the end of each cycle, feedback about deliverables, effort etc must be given.

Software Testing Department of IT

Agile methodology

What is it?

Traditional software development methodologies work on the premise that software requirements remain constant throughout the project. But with an increase in complexity, the requirements undergo numerous changes and continuously evolve. At times, the customer himself is not sure what he wants. Though the iterative model addresses this issue, it's still based on the waterfall model.

In Agile methodology, software is developed in incremental, rapid cycles. Interactions amongst customers, developers and client are emphasized rather than processes and tools. The agile methodology focuses on responding to change rather than extensive planning.

What Is The Testing Approach?

Software Testing Department of IT

Incremental testing is used in agile development methods and hence, every release of the project is tested thoroughly. This ensures that any bugs in the system are fixed before the next release.

Advantages

It is possible to make changes in the project at any time to comply with the requirements.

This incremental testing minimizes risks.

Disadvantages

Constant client interaction means added time pressure on all stakeholders including the client themselves, software development and test teams.

Extreme programming

What is it?

Extreme programming is a type of agile methodology which beliefs in short development cycles. A project is divided into simple engineering tasks. Programmers code a simple piece of software

Software Testing Department of IT and get back to the customer for feedback. Review points from the customer are incorporated and the developers proceed with the next task.

In extreme programming developers usually, work in pairs.

Extreme Programming is used in places where customer requirements are constantly changing.

What Is The Testing Approach?

Extreme programming follows a Test-driven development which is described as follows -

1. Add a Test Case to the test suite to verify the new functionality which is yet to be developed 2. Run all the tests and obviously the new test case added must fail since the functionality is not coded yet 3. Write some code to implement the feature/functionality 4. Run the test suite again. This time, the new test case should pass since the functionally has been coded

Advantages

Customers having a vague software design in mind could use extreme programming

Continuous testing and continuous integration of small releases ensure software code is delivered is of high quality

Disadvantages

Meetings amongst the software development team and clients add to time requirements.

Manual Testing

Manual testing includes testing a software manually, i.e., without using any automated tool or any script. In this type, the tester takes over the role of an end-user and tests the software to identify any unexpected behavior or bug. There are different stages for manual testing such as unit testing, integration testing, system testing, and user acceptance testing.

Testers use test plans, test cases, or test scenarios to test a software to ensure the completeness of testing. Manual testing also includes exploratory testing, as testers explore the software to identify errors in it.

Automation Testing

Automation testing, which is also known as Test Automation, is when the tester writes scripts and uses another software to test the product. This process involves automation of a manual

Software Testing Department of IT process. Automation Testing is used to re-run the test scenarios that were performed manually, quickly, and repeatedly.

Apart from regression testing, automation testing is also used to test the application from load, performance, and stress point of view. It increases the test coverage, improves accuracy, and saves time and money in comparison to manual testing.

What to Automate?

It is not possible to automate everything in a software. The areas at which a user can make transactions such as the login form or registration forms, any area where large number of users can access the software simultaneously should be automated.

Furthermore, all GUI items, connections with databases, field validations, etc. can be efficiently tested by automating the manual process.

When to Automate?

Test Automation should be used by considering the following aspects of a software −

 Large and critical projects  Projects that require testing the same areas frequently  Requirements not changing frequently  Accessing the application for load and performance with many virtual users  Stable software with respect to manual testing  Availability of time

How to Automate?

Automation is done by using a supportive computer language like VB scripting and an automated software application. There are many tools available that can be used to write

Software Testing Department of IT automation scripts. Before mentioning the tools, let us identify the process that can be used to automate the testing process −

 Identifying areas within a software for automation  Selection of appropriate tool for test automation  Writing test scripts  Development of test suits  Execution of scripts  Create result reports  Identify any potential bug or performance issues

Software Testing Tools

The following tools can be used for automation testing −

 HP Quick Test Professional  Selenium  IBM Rational Functional Tester  SilkTest  TestComplete  Testing Anywhere  WinRunner  LoadRunner  Visual Studio Test Professional  WATIR

Software Testing Department of IT

UNIT-5 Regression Testing

Regression testing is a testing that is done to verify that a code change in the software does not impact the existing functionality of the product.

This testing makes sure that the product works fine as previously with the newly added functionality or any change in the existing feature or once the bug fix is done. Previously executed test cases are re-executed in order to verify the impact of change. Regression Testing is a Software Testing type in which test cases are re-executed in order to check whether the previous functionality of the application is working fine and the new changes have not introduced any new bugs. This test can be performed on a new build when there is a significant change in the original functionality that too even in a single bug fix.

Regression means retesting the unchanged parts of the application.

Over the many batches, this question comes multiple times in various different ways. Some of them are:

Overview

Regression testing is like a verification method. Test cases are generally automated as test cases

are required to execute again and again and running the same test cases again and again manually is time consuming and tedious one too.

Example, Consider a product X, in which one of the functionality is to trigger confirmation, acceptance, and dispatched emails when Confirm, Accept and Dispatch buttons are clicked. Some issue occurs in the confirmation email and in order to fix the same, some code changes are done. In this case, not only the Confirmation emails need to be tested but Acceptance and Dispatched emails also needs to be tested to ensure that the change in the code has not affected them.

Software Testing Department of IT

Regression testing is not dependent on any programming language like Java, C++, C# etc. It is a testing method which is used to test the product for modifications or for any updates being done

Verifying that the bugs are fixed and the newly added features have not created any problem in the previous working version of the software.

Testers perform functional testing when a new build is available for verification.

Regression test should be a part of the release cycle and must be considered in the test estimation.

When to perform this test?

Regression testing is usually performed after verification of changes or new functionality. But this is not the case always. For the release that is taking months to complete, regression tests must be incorporated in the daily test cycle. For weekly releases, regression tests can be performed when the functional testing is over for the changes.

Regression test at its core is a retest of sorts. It is only for the special occasion that something in the application/code has changed. It might be code, design or anything at all that dictates the overall framework of the system.

A retest that is conducted in this situation to make sure that the said change has not made an impact on anything that was already working before is called Regression Test. The most common reasons why this might be conducted are because new versions of the code have been created (increase in scope/requirement) or bugs have been fixed.

Can regression testing be performed manually?

To begin with, Test execution is a simple act of using your Test cases and performing those steps on the AUT, supplying the test data and comparing the result obtained on the AUT with the expected result mentioned in your test cases. Depending on the comparison result, we set the status of the test case pass/fail. Test execution is as simple as that, there are no special tools necessary for this process.

Here goes- Lets us once again follow the classic approach- the what, why, how, who, where, when- the answering of the most common question words that make understanding any topic a breeze.

Software Testing Department of IT

Why the Regression Test?

Regression testing is initiated when a programmer fixes any bug or adds a new code for new functionality to the system.

There can be many dependencies in the newly added and the existing functionality.

It is a quality measure to check whether the new code complies with the old code so that the unmodified code is not getting affected. Most of the time the testing team has the task to check the last minute changes in the system. In such a situation, testing only affected application area is necessary to complete the testing process on time by covering all the major system aspects.

 This test is very important when there is a continuous change/improvement added in the application. The new functionality should not negatively affect the existing tested code.

 Regression testing is required to find the bugs that occurred because of a change in the code. If this testing is not done, the product might get critical issues in the live environment and that indeed can lead the customer into trouble.

Software Testing Department of IT

 While testing any online website, a tester reports an issue that the Price of the Product is not shown correctly i.e. it shows lesser price than the actual price of the Product, and it needs to be fixed soon.

 Once the developer fixes the issue, it needs to be re-tested and Regression testing is also required as verifying the price at the reported page would have got corrected but might be showing an incorrect price at the summary page where the total is shown along with the other charges or the mail sent to the customer still has the incorrect price.

So, Regression testing plays a big role and is very much required and important as well.

Types of Regression Testing

Given below are the various types of Regression :  Unit Regression  Partial Regression  Complete Regression

#1) Unit Regression:

Unit Regression is done during the unit testing phase and code is tested in isolation i.e. any dependencies on the unit to be tested are blocked so that the unit can be tested individually without any discrepancy.

#2) Partial Regression:

Partial regression is done to verify that the code works fine even when the changes have been done in the code and that unit is integrated with the unchanged or already existing code.

#3) Complete Regression:

Complete Regression testing is done when a change in code is done on a number of modules and also if the change impact of a change in any other module is uncertain. Product as a whole is regressed to check any changes because of the changed code.

What do we do in Regression Check?

 Re-run the previously conducted tests  Compare the current results with previously executed test results This is a continuous process performed at various stages throughout the software testing lifecycle.

Software Testing Department of IT

A best practice is to conduct a regression test after the sanity or smoke testing and at the end of functional testing for a short release.

In order to conduct effective testing, the regression test plan should be created. This plan should outline the regression testing strategy and the exit criteria. Performance testing is also a part of this test to make sure that the system performance is not affected due to the changes made in the system components.

Best practices: Run automated test cases every day in the evening so that any regression side effects can be fixed in the next day build. This way it reduces the release risk by covering almost all regression defects at an early stage rather than finding and fixing those at the end of the release cycle.

Regression Testing Techniques

Given below are the various techniques.  Retest all  Regression Test Selection  Test case Prioritization  Hybrid

#1) Retest all:

As the name itself suggests, the entire test cases in the test suite are re-executed to ensure that there are no bugs that have occurred because of a change in the code. This is an expensive method as it requires more time and resources when compared to the other techniques.

#2) Regression Test Selection:

In this method, test cases are selected from the test suite to be re-executed. Not the entire suite is re-executed. Selection of test cases is done on the basis of code change in the module.

Test cases are divided into two categories, one is Reusable test cases and another one is obsolete test cases. The reusable test cases can be used in future regression cycles whereas obsolete ones are not used in the upcoming regression cycles.

#3) Test Case Prioritization:

Test cases with high Priority are executed first than the ones with medium and low priority. Priority of test case depends on its criticality and its impact on the product and also on the functionality of the product which is used more often.

#4) Hybrid:

Software Testing Department of IT

The hybrid technique is a combination of Regression test selection and Test case Prioritization. Rather than selecting the entire test suite, select only the test cases which are re-executed depending on their priority.

How to Select Regression Test Suite?

Most of the bugs found in the production environment occur because of the changes did or bugs fixed at the eleventh hour i.e. the changes done at a later stage. The bug fix at the last stage might create other issues/bugs in the Product. That‘s why Regression checking is very important before releasing a Product.

Below is a list of test cases that can be used while performing this test:  Functionalities which are frequently used.  Test cases which cover the module where the changes have been done.  Complex test cases.  Integration test cases which include all the major components.  Test cases for the core functionality or feature of the Product.  Priority 1 and Priority 2 test cases should be included.  Test cases which frequently fail or recent testing defects were found in the same.

How to Perform Regression Testing?

Now that we have established what regression means, it is apparent that it is testing also – simply repeating in a specific situation for a specific reason. Therefore, we can safely derive that the same method applies for testing in the first place can be applied to this too.

Therefore, if testing can be done manually then regression testing can be too. The use of a tool is not necessary. However, as time goes on applications get piled on with more and more functionality which keeps increasing the scope of regression. To make the most of the time, this testing is most often automated. Given below are the various steps involved in performing this testing:  Prepare a Test suite for Regression considering the points mentioned in “How to select Regression Test suite”?  Automate all the test cases of the test suite.  Update the Regression suite whenever it is required like if any new defect which is not covered in the test case is found, and a test case for the same should be updated in the test suite so that the testing is not missed for the same next time. The regression test suite should be managed properly by continuously updating the test cases.  Execute the Regression test cases whenever there is any change in the code, the bug is fixed, new functionality is added, an enhancement to the existing functionality is done etc.  Create a test execution Report which includes the Pass/Fails status of the executed test cases. Example: Let me explain this with an example. Please examine the below situation:

Software Testing Department of IT

Release 1 statistics

Application Name XYZ

Version/release Number 1

No. of requirements (scope) 10

no. of test cases/tests 100

no. of days it takes to develop 5

No. of days it takes to test 5

no. of testers 3

Release 2 statistics

Application Name XYZ

Version/release Number 2

No. of requirements (scope) 10+ 5 new requirements

no. of test cases/tests 100+ 50 new

2.5 (since this half the no. of days it takes amount of work than to develop earlier)

5(for the existing 100 No. of days it takes TCs) + 2.5 (for new to test requirements)

Software Testing Department of IT

Release 2 statistics

no. of testers 3

Release 3 statistics

Application Name XYZ

Version/release Number 3

No. of requirements 10+ 5 + 5 new (scope) requirements

no. of test cases/tests 100+ 50+ 50 new

2.5 (since this half the no. of days it takes amount of work than to develop earlier)

7.5 (for the existing 150 No. of days it TCs) + 2.5 (for new takes to test requirements)

no. of testers 3

The following are the observations we can make from the above situation:  As the releases grow the functionality grows  The development time does not necessarily grow with releases, but the testing time does  No company/its management will be ready to invest more time in testing and less for development  We cannot even reduce the time it takes to test by increasing the test team size because more people means more money and new people also means lots of training and maybe also a compromise in quality as the new people might not be at par with the required knowledge levels immediately.  The other alternative clearly is to reduce the amount of regression. But that could be risky for the software product. For all these reasons, regression testing is a good candidate for automation testing, but it does not have to be done only that way.

Software Testing Department of IT

Basic Steps to Perform Regression Tests: Every time the software undergoes a change and a new version/release comes up, the following are the steps you can take to carry out this type of testing:

1. Understand what kind of changes have been made to the software 2. Analyze and determine what modules/parts of the software might be impacted – the development and BA teams can be instrumental in providing this information 3. Take a look at your test cases and determine if you will have to do a full, partial or unit regression. Identify the ones that will fit your situation 4. Schedule the time and test away!

Regression Testing in Agile

Agile is an adaptive approach which follows an iterative and incremental method. The product is developed in short iterations called sprint which lasts for 2- 4 weeks. In agile, there is a number of iterations, hence this testing plays a significant role as the new functionality or code change is done in the iterations. The regression test suite should be prepared from the initial phase and should be updated with each sprint.

In agile, Regression check is covered under two categories:  Sprint Level Regression  End to End Regression

#1) Sprint Level Regression :

Sprint level regression is done mainly for the new functionality or the enhancement that is done in the latest sprint. Test cases from the test suite are selected as per the newly added functionality or the enhancement that is done.

#2) End-to-End Regression :

End-to-End Regression includes all the test cases that are to be re-executed to test the complete product end to end by covering all the core functionalities of the Product.

As Agile has short sprints and it goes on, it is very much required to automate the test suite, the test cases are executed again and that too needs to be completed in a short span of time. Automating the test cases reduces the time of execution and defect slippage.

Regression Testing Tools

Automated Regression Test is the testing area where we can automate most of the testing efforts. We run all the previously executed test cases on a new build.

Software Testing Department of IT

This means that we have a test case set available and running these test cases manually is time- consuming. We know the expected results, so automating these test cases is time-saving and is an efficient regression test method. The extent of automation depends upon the number of test cases that are going to remain applicable over the time.

If test cases are varying from time to time, the application scope goes on increasing and then automation of regression procedure will be the waste of time.

Most of the regression test tools are record and playback type. You will record the test cases by navigating through the AUT (application under test) and verify whether the expected results are coming or not.

Examples of regression testing tools are:  Winrunner  QTP  AdventNetQEngine  Regression Tester  vTest  Watir  Selenium  actiWate  Rational Functional Tester  SilkTest  TimeShiftX Most of these tools are both functional and regression test tools.

Adding and updating regression test cases in an automation test suite is a cumbersome task. While selecting an automation tool for regression tests, you should check if the tool allows you to add or update the test cases easily.

In most cases, we need to update automated regression test cases frequently due to frequent changes in the system.

Recommended reading => Check here the list of top Regression Tools

Advantages

Given below are the various advantages of Regression test:  It improves the quality of the Product.  It ensures that any bug fix or enhancement that is done does not impact the existing functionality of the Product.  Automation tools can be used for this testing.

Software Testing Department of IT

 It makes sure that issues which are already fixed do not occur again.

Disadvantages

Though there are several advantages, there are some disadvantages as well. They are:  It has to be done for a small change in the code as well because even a small change in the code can create issues in the existing functionality.  If in case automation is not used in the Project for this testing, it will be a time consuming and tedious task to execute the test cases again and again.

Regression Of GUI application

It is difficult to perform a GUI (Graphical User Interface) regression test when the GUI structure is modified. The test cases written on old GUI either become obsolete or need to be modified. Re-using the regression test cases means GUI test cases are modified according to the new GUI. But this task becomes a cumbersome one if you have a large set of GUI test cases.

Difference between Regression and Re-testing

Re-testing is done for the test cases which fail during the execution and the bug raised for the same has been fixed whereas Regression check is not limited to the bug fix as it covers other test cases as well to ensure that the bug fix has not impacted any other functionality of the Product.

Regression Test Plan Template (TOC)

1. Document History 2. References 3. Regression Test Plan 3

1. Document History

Document history consists of a record of the first draft and all the updated ones in the below- given format.

Version Date Author Comment

1 DD/MM/YY ABC Approved

Updated for 2 DD/MM/YY ABC the added

Software Testing Department of IT

Version Date Author Comment

feature

2. References

References column keep a track of all the reference documents used or required for the Project while creating a test plan.

No Document Location

1 SRS document Shared drive

3. Regression Test Plan

Introduction This document describes the change/update/enhancement in the Product to be tested and the approach used for this testing. All the code changes, enhancements, updates, added features are outlined to be tested. Test cases used for unit testing and Integration testing can be used to create a test suite for Regression.

Purpose Purpose of Regression Test Plan is to describe what exactly and how testing would be performed to accomplish the results. Regression check is done to ensure that no other functionality of the product is hampered because of the code change.

Test Strategy Test Strategy describes the approach which will be used to perform this testing and that includes the technique that will be used, what will be the completion criteria, who will be performing which activity, who will write the test scripts, which regression tool will be used, steps to cover the risks like resource crunch, delay in production etc.

Features to be tested Feature/components of the product to be tested are listed here. In regression, all the test cases are re-executed or the ones which affect the existing functionality are chosen depending on the fix/update or enhancement done.

Resource Requirement 3.5.1. Hardware Requirement: Hardware Requirement is identified here like computers, laptop, Modems, Mac book, Smartphone etc.

Software Testing Department of IT

Software Requirement:

Software Requirement is identified like which Operating system and browsers will be required.

Test Schedule Test schedule defines the estimated time for performing the testing activities.

Example: How many resources will perform a testing activity and that too in how much time? Change Request CR details are mentioned for which Regression would be performed.

S.No CR Description Regression Test Suite

Entry/Exit Criteria 3.8.1. Entry Criteria for this testing: Entry criteria for the Product to start Regression check are defined.

For Example:  Coding changes/enhancement/addition of new feature should be completed.  Regression test Plan should be approved. 3.8.2. Exit Criteria for this testing: Here the exit criteria for Regression are defined.

For Example:  Regression testing should be completed.  Any new critical bugs found during this testing should be closed.  Test Report should be ready. Test Cases Regression Test cases are defined here.

Risk/Assumptions Any risk & assumptions are identified and a contingency plan is prepared for the same.

Regression testing is one of the important aspects as it helps to deliver a quality product by making sure that any change in the code whether it‘s a small or large does not affect the existing or old functionality.

Software Testing Department of IT

A lot of automation tools are available for automating the regression test cases, however, a tool should be selected as per the Project requirement. A tool should have the ability to update the test suite as the Regression test suite needs to be updated frequently.