01. Introduction to Software Testing_v19

8/18/2019 01. Introduction to Software Testing_v19

1/34

Confidential Page 1 of 34

Introduction to Software Testing – Level 1


2/34


Testing is a process of gathering information by making observations and comparing them to expectations. -Dale Emery

IntroductionIn our day-to-day life, when we go out, shopping any product such as vegetable, clothes, pens, etc., we docheck it before purchasing them for our satisfaction and to get maximum benefits. For example, when we intendto buy a pen, we test the pen before actually purchasing it, i.e. if it's writing, does the functionalities work, etc.So, be it the software, hardware, or any other product, testing turns to be mandatory.

Software testing is a process of verifying and validating whether the program is performing correctly with nobugs. It is the process of analyzing or operating software for the purpose of finding bugs. It also helps to identifythe defects / flaws / errors that may appear in the application code, which needs to be fixed. Testing not onlymeans fixing the bug in the code, but also to check whether the program is behaving according to the givenspecifications and testing strategies. There are various types of strategies such as white box testing, black boxtesting, gray box testing, etc.

Software development goes through a chain of process. It starts with requirement analysis phase and endswith the maintenance phase. There are two important phases of software development, namely coding andtesting phase. Testing phase is an important phase, as it verifies and validates, that the software has beendeveloped according to the requirements of the user. Software testing can be carried out using two methods:

Manual Scripted Testing: This is considered to be one of the oldest type, in which test cases are designedand reviewed by the team, before executing it.

Automated Testing: This applies automation in the testing, which can be applied to various parts of asoftware process such as test case management, executing test cases, defect management, and reportingof the bugs/defects.

This manual testing tutorial will help you to understand the basics of software testing in general and


3/34


manual testing in particular. Let's take a look at manual testing tutorial for beginners, but it will also prove to beof help for advanced learners, as it will prove to be of help in clearing certain concepts, which an advancedlearner may not be comfortable with.

What is Manual Testing?

Manual testing is the method used to check software for defects manually. In this type of testing, a tester wearsgarbs of an end-user. All features of software are tested to know, if the behavior of the software is exactlyaccording to the expectations of the customer. Normally, the tester has a test plan, which he uses for testing.Other than test plan, there are test cases written, which are used for implementing the test plan.

Manual Testing Tutorial

After the introduction to software testing, we will now turn towards software testing tutorial. This tutorial dealswith all basics of manual testing.

Stages of Manual Testing

The entire process of manual testing goes through four phases. First phase is known as unit testing . It is the job ofthe developer to test units of the code written by the developer himself. In some cases, the code may also be

tested by a peer. Integration testing is second phase of software testing. It is carried out, when big chunks ofcodes are integrated to form a bigger block of code. Either black box or white box testing is carried out in thisphase. The next phase is system testing phase. The software is tested for all possibilities to rule out any kind ofabnormality in the system. Normally black box testing technique is used in system testing phase. User acceptancetesting is per the last stage of manual testing. In this phase, software is tested keeping the end-user in mind.There are two types of acceptance testing, which are used, namely alpha testing and beta testing.


4/34


Need for Software Testing Strategies

The types of software testing, depends upon different types of defects. For example:

Functional testing is done to detect functional defects in a system. Performance testing is performed to detect defects when the system does not perform according to thespecifications.

Usability testing to detect usability defects in the system.Security testing is done to detect bugs/defects in the security of the system

Software Testing Life Cycle

Like the software development life cycle, the software also goes through a software testing life cycle. It is often

seen that software testing interview questions and answers revolve a lot around software testing life cycle. Thedifferent phases of software testing life cycle are:


5/34


Requirement Phase

Test Planning Phase

Test Analysis Phase

Test Design Phase

Test Verification andConstruction Phase

Test Execution Phase

Result Analysis Phase

Bug Tracking andReporting Phase

Rework Phase

Final Test andImplementation Phase

Image 1: Software Testing Life Cycle

http://www.buzzle.com/images/diagrams/software-testing/software-testing-life-cycle.jpg


6/34


Introduction to Software Testing Life Cycle

In every organization testing is an important phase in the development of a software product. However, the wayit is carried out differs from one organization to another. It is advisable to carry out the testing process from theinitial stages, with regard to the Software Development Life Cycle or SDLC to avoid any complications.

Software Testing Life Cycle Phases

Software testing has its own life cycle that meets every stage of the SDLC. The software testing life cycle diagramcan help one understand its various phases. They are:

Requirement Stage Test Planning Test Analysis Test Design Test Verification and Construction Test Execution Result Analysis Bug Tracking

Reporting and Rework Final Testing and Implementation Post Implementation


7/34


Requirement Stage This is the initial stage of the software testing life cycle process. In this phase the developers take part inanalyzing the requirements for designing a product. The role of software testers is also necessary in this phase asthey can think from the 'users' point of view which the developers may not. Thus a team of developers, testersand users can be formed, to analyze the requirements of the product. Formal meetings of the team can be held inorder to document the requirements which can further be used as software requirements specification or SRS.

Test Planning Test planning means to predetermine a plan well in advance to reduce further risks. A well-designed test plandocument plays an important role in achieving a process-oriented approach. Once the requirements of theproject are confirmed, a test plan is documented. The test plan structure is as follows:

Introduction: This describes the objective of the test plan. Test Items: The items that are required to prepare this document will be listed here such as SRS, project

plan. Features to be tested: This describes the coverage area of the test plan, that is, the list of features to be

tested; that are based on the implicit and explicit requirements from the customer. Features not to be tested: The incorporated or comprised features that can be skipped from the testing

phase are listed here. Features that are out of scope of testing, like incomplete modules or those on lowseverity, for example, GUI features that don't hamper the process can be included in the list.

Approach: This is the test strategy that should be appropriate to the level of the plan. It should be inacceptance with the higher and lower levels of the plan.

Item pass/fail criteria: Related to the show stopper issue. The criteria used has to explain which test itemhas passed or failed.

Suspension criteria and resumption requirements: The suspension criteria specifies the criteria that is to beused to suspend all or a portion of the testing activities, whereas resumption criteria specifies when testingcan resume with the suspended portion.


8/34


Test deliverable: This includes a list of documents, reports, charts that are required to be presented to thestakeholders on a regular basis during the testing process and after its completion.

Testing tasks: This phase lists the testing tasks that need to be performed. This includes conducting the

tests, evaluating the results and documenting them based on the test plan designed. This also helps usersand testers to avoid incomplete functions and prevent waste of resources. Environmental needs: The special requirements of the test plan depending on the environment in which

the application has to be designed are listed here. Responsibilities: This phase assigns responsibilities to people who can be held responsible in case of a risk. Staffing and training needs: Training on the application/system and on the testing tools to be used needs to

be explained to the staff members who are responsible for the application. Risks and contingencies: This emphasizes on the probable risks and various events that can occur and what

can be done in such situations. Approval: This decides who can approve the process as complete and allow the project to proceed to thenext level that depends on the level of the plan.

Test Analysis Once the test plan documentation is done, the next stage is to analyze what types of software testing should becarried out at the various stages of SDLC.

Test Design Test design is done based on the requirements of the project documented in the SRS. This phase decides whethermanual or automated testing is to be done. In automation testing, different paths for testing are to be identifiedfirst and writing of scripts has to be done if required. An end-to-end checklist that covers all the features of theproject is necessary in the test design process.

Test Verification and Construction In this phase, the test plan, test design and automated test script are completed. Stress and performance testingplans are also completed at this stage. When the development team is done with a unit of code, the testing team


9/34


10/34


11. Priority: Priority of fixing the bug.12. Status: This field displays current status of the bug.

Reporting and Rework Testing is an iterative process. The bug that is reported and fixed by the development team, has to undergo thetesting process again to assure that the bug found has been resolved. Regression testing has to be done. Once theQuality Analyst assures that the product is ready, the software is released for production. Before release, thesoftware has to undergo one more round of top-level testing. Thus testing is an ongoing process.

Final Testing and Implementation This phase focuses on the remaining levels of testing, such as acceptance, load, stress, performance and recoverytesting. The application needs to be verified under specified conditions with respect to the SRS. Variousdocuments are updated and different matrices for testing are completed at this stage of the software testing lifecycle.

Post Implementation Once the test results are evaluated, the recording of errors that occurred during the various levels of the softwaretesting life cycle, is done. Creating plans for improvement and enhancement is an ongoing process. This helps toprevent similar problems from occurring in the future projects. In short, planning for improvement of the testingprocess for future applications is done in this phase.

Software Testing Strategy

There are three software testing types, under which all software testing activities are carried out. They are:

White Box Testing Strategy : Testing of internal structure of the software is known as white box testing.


11/34


Black Box Testing Strategy : This testing strategy is used to test different functionalities of the software,which is being developed.

Gray Box Testing Strategy : The software is tested to find defects of any kinds, whether in code or in

structure.There are other types of software testing, which are used to test a product to ensure that the software meetsrequirements of the end-user. They include:

Functional Testing Smoke Testing Usability Testing Validation Testing Compatibility Testing

Sanity Testing Exploratory Testing Security Testing Regression Testing Recovery Testing Performance Testing (This includes 2 sub-types - Load Testing and Stress Testing)

Software Testing Techniques

Software testing methodologies are divided into static testing techniques and dynamic testing techniques . Software review and static analysis by using tools are methods, which come under static testing techniques.Specification based testing techniques, structure based testing techniques and experience based testing


12/34


techniques are all included under dynamic testing technique.

Example: Equivalence partitioning is one of the important strategy used in specification based testing technique.

Bug Life Cycle

The aim of entire software testing activity is to find defects in the software, before it is released to the end-userfor use. A Bug life cycle starts after a tester logs a bug.

Phases in the bug life cycle are:


13/34


Image 2: Bug Life Cycle

New

Open

Assign

Test

Deferred

Rejected

Duplicate

Verified

Reopened

Closed

http://www.buzzle.com/images/diagrams/software-testing/dfc-defect-life-cycle.jpg


14/34


The duration or time span between the first time that the bug is found is called 'New' and closed successfully(status: 'Closed'), rejected, postponed or deferred is called 'Bug/Error Life Cycle'.

Right from the first time any bug is detected till the point when the bug is fixed and closed, it is assigned variousstatuses which are New, Open, Postpone, Pending Retest, Retest, Pending Reject, Reject, Deferred, and Closed.

There are seven different life cycles that a bug can pass through:

Cycle I A tester finds a bug and reports it to the Test Lead. The test lead verifies if the bug is valid or not. Test lead finds that the bug is not valid and the bug is 'Rejected'.

Cycle II

A tester finds a bug and reports it to the Test Lead.

The test lead verifies if the bug is valid or not. The bug is verified and reported to the development team with status as 'New'. The development leader and team verify if it is a valid bug. The bug is invalid and is marked with a status of

'Pending Reject' before passing it back to the testing team. After getting a satisfactory reply from the development side, the test leader marks the bug as 'Rejected'.

Cycle III A tester finds a bug and reports it to the Test Lead. The test lead verifies if the bug is valid or not. The bug is verified and reported to the development team with status as 'New'.


15/34


The development leader and team verify if it is a valid bug. The bug is valid and the development leaderassigns a developer to it, marking the status as 'Assigned'.

The developer solves the problem and marks the bug as 'Fixed' and passes it back to the Developmentleader.

The development leader changes the status of the bug to 'Pending Retest' and passes it on to the testingteam for retest.

The test leader changes the status of the bug to 'Retest' and passes it to a tester for retest. The tester retests the bug and if it is working fine, the tester closes the bug and marks it as 'Closed'.

Cycle IV A tester finds a bug and reports it to the Test Lead. The test lead verifies if the bug is valid or not.

The bug is verified and reported to the development team with status as 'New'. The development leader and team verify if it is a valid bug. If the bug is valid, the development leaderassigns a developer for it, marking the status as 'Assigned'.

The developer solves the problem and marks the bug as 'Fixed' and passes it back to the Developmentleader.

The development leader changes the status of the bug to 'Pending Retest' and passes it on to the testingteam for retest.

The test leader changes the status of the bug to 'Retest' and passes it to a tester for retest.

The tester retests the bug and the same problem persists, so the tester after confirmation from test leaderreopens the bug and marks it with a 'Reopen' status. And then, the bug is passed back to the developmentteam for fixing.

Cycle V A tester finds a bug and reports it to the Test Lead. The test lead verifies if the bug is valid or not. The bug is verified and reported to the development team with status as 'New'.


16/34


The developer tries to verify if the bug is valid but fails to replicate the same scenario as it was at the timeof testing, and asks for help from the testing team.

The tester also fails to regenerate the scenario in which the bug was found. And finally, the developerrejects the bug marking it as 'Rejected'.

Cycle VI

After confirmation that the data is unavailable or certain functionality is unavailable, the solution and retest ofthe bug is postponed for indefinite time and it is marked as 'Postponed'.

Cycle VII

If the bug does not stand importance and needs to be postponed, then it is given a status as 'Deferred'.

This was about the various life cycles that a bug goes through in software testing. And in the ways mentionedabove, any bug that is found ends up with a status of Closed, Rejected, Deferred or Postponed.

Software Testing Models


17/34


There are different software testing models, which the software testing team can choose from. Each of thesemodels have different methods, as they are based on different principles. A number of factors are taken intoconsideration, before a particular model is chosen. The different models that are used are:

Waterfall Model in Testing Validation and Verification Model Spiral Model Rational Unified Process (RUP) Model Agile Model Rapid Application Development (RAD) Model

What is a Test Case?

Simply put, a test case is a scenario made up of a sequence of steps and conditions or variables, where test inputsare provided and the program is run using those inputs, to see how it performs. An expected result is outlinedand the actual result is compared to it. Certain working conditions are also present in the test case, to see howthe program handles the conditions.Every requirement or objective that the program is expected to achieve, needs at least one test case. Realistically,it definitely takes more than one test case to determine the true functionality of the application being tested. Themechanism used to judge the result of the test case, i.e. whether the program has failed or passed the test, is

called a test oracle.

Test cases, at root level, are used to measure how a program handles errors or tricky situations such as if oneinput is incorrect or if both inputs are incorrect. They are also expected to expose hidden logical errors in theprogram's code that have gone undetected.Typical Structure of a Test case


18/34


A formal written test case can be divided into three main parts:

Information Information consists of general information about the test case such as a case identifier, case creator info, testcase version, formal name of the test case, purpose or brief description of the test case and test casedependencies. It should also include specific hardware and software requirements (if any) and setup orconfiguration requirements.

Activities This part consists of the actual test case activities such as the environment that should exist during testing,activities to be done at the initialization of the test, activities to be done after test case is performed, step-by-stepactions to be done while testing and the input data that is to be supplied for testing.

Results Results are the outcomes of a performed test case. Result data consists of information about expected results,which is the criteria necessary for the program to pass the test and the actual recorded results.

Test Case Format

Two sample formats for writing test cases are:


19/34


Detailed

TestCase Id

Purpose

TestCreate

d By

TestEnvironmen

t Prerequisite

s

TestProcedur

e TestData

Expected Result

ActualResult

Verdict:Pass/Fai

l Comment

s

Serialnoassigned totestcase

Briefideaaboutcase

Nameof testcreator

Software orhardware inwhich thetest case isexecuted

Conditionsthat shouldbe fulfilledbefore thetest isperformed

Steps tobeperformed in test

Inputs,variables anddata

Whattheprogramshoulddo

Whatisactually done

Status ofthe test

Notes ontheprocedure

Simple

Step No. Serial no of step

Step or Activity Detailed operation or procedure

Criteria for Success Expected result

Status Whether the code passed the test or not

Designing test cases can be time-consuming in a testing schedule, but they are worth the time spent becausethey can prevent unnecessary retesting or debugging or at least lower the rate of such operations. Organizationscan take the test case approach in their own context and according to their own perspectives. Some follow ageneral approach while others may opt for a more detailed and complex approach. It is important for you todecide between the two extremes and decide what would work best for you.


20/34


Software Testing Types in detail

Black Box Testing : It explains the process of giving the input to the system and checking the output, withoutconsidering how the system generates the output. It is also known as Behavioral Testing.

Functional Testing : The software is tested for the functional requirements. This checks whether the application isbehaving according to the specification.

Performance Testing : This testing checks whether the system is performing properly, according to the user'srequirements. Performance testing depends upon the Load and Stress Testing, that is internally or externallyapplied to the system.

Load Testing: In this type of performance testing, the system is raised beyond the limits in order to checkthe performance of the system when higher loads are applied.

Stress Testing: In this type of performance testing, the system is tested beyond the normal expectations oroperational capacity.

Usability Testing : This is also known as 'Testing for User Friendliness'. It checks the ease of use of an application.

Regression Testing : Regression testing is one of the most important types of testing, which checks whether asmall change in any component of the application affects the unchanged components or not. This is done by re-executing the previous versions of the application.

Smoke Testing : It is used to check the testability of the application, and is also called 'Build Verification Testing orLink Testing'. That means, it checks whether the application is ready for further testing and working, withoutdealing with the finer details.


21/34


Sanity Testing : Sanity testing checks for the behavior of the system. This is also called Narrow Regression Testing.

Parallel Testing : Parallel testing is done by comparing results from two different systems like old vs new ormanual vs automated.

Recovery Testing : Recovery testing is very necessary to check how fast the system is able to recover against anyhardware failure, catastrophic problems or any type of system crash.

Installation Testing : This type of software testing identifies the ways in which installation procedure leads toincorrect results.

Compatibility Testing : Compatibility testing determines if an application under supported configurationsperforms as expected, with various combinations of hardware and software packages.

Configuration Testing : This testing is done to test for compatibility issues. It determines minimal and optimalconfiguration of hardware and software, and determines the effect of adding or modifying resources such asmemory, disk drives, and CPU.

Compliance Testing : This checks whether the system was developed in accordance with standards, procedures,

and guidelines.

Error-Handling Testing : This determines the ability of the system to properly process erroneous transactions.

Manual-Support Testing : This type of software testing is an interface between people and application system.

Inter-Systems Testing : This method is an interface between two or more application systems.


22/34


Exploratory Testing : Exploratory testing is similar to ad-hoc testing, and is performed to explore the softwarefeatures.

Volume Testing : This testing is done when huge amount of data is processed through the application.

Scenario Testing : Scenario testing provides a more realistic and meaningful combination of functions, rather thanartificial combinations that are obtained through domain or combinatorial test design.

User Interface Testing : This type of testing is performed to check, how user-friendly the application is. The usershould be able to use the application, without any assistance by the system personnel.

System Testing : This testing conducted on a complete, integrated system, to evaluate the system's compliancewith the specified requirements. This is done to check if the system meets its functional and non-functionalrequirements and is also intended to test beyond the bounds defined in the software / hardware requirementspecifications.

User Acceptance Testing : Acceptance testing is performed to verify that the product is acceptable to thecustomer and if it's fulfilling the specified requirements of that customer. This testing includes Alpha and Betatesting.

Alpha Testing: Alpha testing is performed at the developer's site by the customer in a closed environment.This is done after the system testing.

Beta Testing: This is done at the customer's site by the customer in the open environment. The presence ofthe developer, while performing these tests, is not mandatory. This is considered to be the last step in thesoftware development life cycle as the product is almost ready.

White Box Testing : It is the process of giving the input to the system and checking, how the system processes theinput to generate the output. It is mandatory for a tester to have the knowledge of the source code.


23/34


Unit Testing : Unit testing is done at the developer's site to check whether a particular piece / unit of code isworking fine. It tests the unit of the program as a whole.

Static and Dynamic Analysis : In static analysis, it is required to go through the code in order to find out anypossible defect in the code. Whereas, in dynamic analysis, the code is executed and analyzed for the output.

Statement Coverage : It assures that the code is executed in such a way that every statement of the application isexecuted at least once.

Decision Coverage : This helps in making decision by executing the application, at least once to judge whether itresults in true or false.

Condition Coverage : In this type of software testing, each and every condition is executed by making it true andfalse, in each of the ways, at least once.

Path Coverage : Each and every path within the code is executed at least once to get a full path coverage, which isone of the important parts of the white box testing.

Integration Testing : Integration testing is performed when various modules are integrated with each other to

form a sub-system or a system. This mostly focuses in the design and construction of the software architecture.This is further classified into Bottom-Up Integration and Top-Down Integration testing.

Bottom-Up Integration Testing: Here the lowest level components are tested first and then the testing ofhigher level components is done using 'Drivers'. The entire process is repeated till the time all the higherlevel components are tested.


24/34


Top-Down Integration Testing: This is totally opposite to bottom-up approach, as it tests the top levelmodules and the branch of the modules are tested step by step using 'Stubs', until the related modulecomes to an end.

Security Testing : Testing that confirms, how well a system protects itself against unauthorized internal orexternal, or willful damage of code; means security testing of the system. Security testing assures that theprogram is accessed by the authorized personnel only.

Mutation Testing : In mutation testing, the application is tested for the code that was modified after fixing aparticular bug/defect.

Check list for Software Tester

We will try to set a baseline that should help any software tester in his/her day-to-day activities. The followingchecklists are defined in the most generic form and do not promise to cover all processes that you are required togo through and follow during your work. There may be some processes which are completely missed out fromthe lists or it may also contain processes which you don't need to follow in your form of work.

First Things First


25/34


Check the scripts assigned to you: This is the first and foremost process in the list. There is no specific logicused to assign scripts to testers who should execute them all, but you may come across practices whereyou will be assigned a script based on your workload for the day or your skill to understand and execute itin the least possible time.

Check the status/comments of the defect in the Test Report Tool: Once you unveil a bug, it's veryimportant to keep track of the status of it as you will have to retest the bug once it is fixed by a developer.Most of the time, the general practice is to confirm if any fix to a bug is successful as it also makes sure thatthe tester can proceed with other tests involving the deeper side of that particular functionality.Sometimes, it also addresses issues related to understanding of functionality of the system, for example: atester registering a defect, which is not an actual bug as per the programming/business logic. Then in thatcase, a comment from the developer might help in understanding the mistake committed by the tester.

Checks while Executing Scripts Update the test data sheet with all values which are required such as user name, functionality, test code,

etc. Use naming conventions defined as testing standards to define a bug appropriately. Take screen prints for the script executed using naming conventions and provide test data that you used

for the testing. The screen prints will help other testers and developers to understand how the test wasexecuted and it will also serve as a proof for you. If possible, try to explain the procedure you followed,choice of data and your understanding, etc.

If your team is maintaining any type of tracking sheet, do not forget to update all the tracking sheets forthe bug, its status, time and date found, severity, etc.

If you are using a test reporting tool, do not forget to execute the script in the tool. Many test reportingtools require scripts to be executed in order to initiate the life cycle of a bug. For example: a test directorneeds a script to be executed till the step where the test script failed, other test steps before the failed teststep are declared as 'passed'.

Update the tracking sheets with current status, status in reporting tools, etc., if it is required to be updatedafter you execute the script in the reporting tool.


26/34


Check if you have executed all the scripts properly and updated the test reporting tool. After you complete your day's work, it is better to do a peer-to-peer review. This step is very important and

often helps in finding out missing steps/processes.Checks while Logging Defects

First of all, confirm with your test lead if the defect is valid. Follow the appropriate naming conventions while logging defects. Before submitting the defect, get it reviewed by Work Lead/Team Lead. Give appropriate description and names in the defect screen prints as per naming conventions. After submitting defects, attach the screen prints for the defect on Test Reporting Tool. Note down the defect number/unique identifier and update the test tracking sheet with appropriate

information.

Maintain a defect log, defect tracking sheet, screen prints dump folder etc., for a backup.

Checks for Blocking and Unblocking Scripts Blocking or unblocking of a script relates to a bug which affects execution of a script. For example: if there is a bugon login screen, which is not allowing anyone to enter the account after entering valid username and passwordand pressing the 'OK' button, there is no way you can execute any test script which requires the account screenthat comes after the login screen.

Confirm with your test lead/work lead if the scripts are really blocked due to an existing bug. Block scripts with an active defect (Defect status: New/Assigned/Fixed/Reopen). Update the current script/defect in the test reporting tool and tracking sheets with the defect

number/unique identifier, which is blocking the execution of the script or testing of the defect. If a defect is retested successfully, then unblock all scripts/defects blocked by it.


27/34


At the end of day, send an update mail to your Team Lead/Work Lead which should include the following: Scripts executed (Number) Defects raised/closed (Number) If any comments are added on defects Issues/queries if any

Steps for Software Testing

Along with finding defects in the software, software testing aims to verify and validate the software, so that itcomplies with the business and technical requirements, works exactly as it is expected to and can beimplemented again, when the existing factors do exist. Although software testing can be implemented at anypoint of time in the software development life cycle, it is normally implemented after the development stage hascome to an end. Till the software development process is underway, it is the developers, who carry out thetesting process, commonly referred to as white box testing. After the software has been handed over to thetesting team, starts the black box testing. This brings us to what are the essential steps of software testing. Let'sfind out.

Note Scope of Testing Although software testing aims to find defects in the software, it is important to note, that testing cannot assurethat the software will work perfectly under all circumstances. It will only assure that the software will workperfectly under certain predetermined conditions. It is in the scope phase that it is decided upon, 'what is thesoftware supposed to do'. It is important that the testing team understands the aim of the software. This will helpin understanding the real time scenario, where the software is exactly going to be used. The documents createdbefore the development process started should be analyzed and business rules have to be understood for thesame. If there is any variance found in the document, the same should be raised during the meeting with thedevelopment team. Along with all the other tasks, there an important factors, which should not be forgottenwhile deciding the scope of testing. It is the stage when software testing stop. Else there are chances, that the


28/34


testing process will go in a never ending loop.

Decide Testing Approach Once the scope has been decided upon, the next stage of software testing is to decide the testing approach, thatis going to be used. The methods and tools, which need to be used for the process are decided upon. At thisstage, it is important to take the client assumptions and various dependencies and limitations into consideration.

Decide Testing Tasks Now that the testing approach has been decided upon, the next step is to decide the tasks, that have to becompleted in each testing phase. The documents to be delivered to the internal client (development team andstakeholders) and to the external client (end user) have to be decided upon. Giving the documents to the internaland external client keeps them in loop about the happenings.

Estimate Time and Budget The next step is to estimate the time and budget necessary for the entire software testing lifecycle as well as foreach of the phase of the cycle. In case any of the budget is overshooting, measures can be taken to curb themand get them on track.

Identify the Testing Phases Now starts the actual task of testing the software. Normally, start and end date of each of the testing phase is

identified, along with the phases that may overlap. It is in this phase that different software testingmethodologies are used to test the software. Each of the methodology used has a different aim, while testing thesoftware. This helps in testing maximum aspects of the software. The exit criteria for each of the phase isidentified as well, so that the testing process can be stopped after the exit criteria has been met. When bugs havebeen identified in the software, the same are reported to the Testing Manager. The Manager creates a reportalong with the conditions in which the bug was reported. This is then forwarded to the development team, whostudy the bugs. They may accept some of the bugs and reject some of the bugs. After which they normally give


29/34


the time necessary for fixing the bugs. Once the bugs are fixed, the software is sent back to the testing team forfurther testing.

Decide Testing Environment The different hardware and software requirements necessary for testing the software should be identified inadvance. Normally, wide range of test environment are decided upon. For example, if it is a software intended foruse on the internet, then the software is tested on all the prominent browsers. There are times, when thesoftware may work perfectly fine on one browser, but may show errors, when it is run on another browser.

Decide Retesting Strategy If there is a problem with the software, it is sent back to the development team. When the problem has beenfixed, the testing team has to test the software. The strategy to retest the software has to be place for the same.

Decide Regression Testing Strategy Often it happens, that one defect is fixed and another defect is created. The aim of regression testing is to ensurethat no more new bugs have been introduced in the software and the software is working perfectly.

Closure of Testing Activities After the exit criteria has been met, start the test closer activities. In this step, the key outputs are captured,

results, log, documents related to the project are put together. All of these go a long way and often prove to be ofhelp for the future projects.

End-to-End vs. System Testing

When end-to-end testing is carried out, it is the flow of activities in the system starting from scratch to the end ofthe system which are tested. On the other hand, in system testing, the system as a whole is tested to find defects,


30/34


if any, in the system. In most cases, end-to-end testing is carried out after changes have been made to thesystem, while system testing is carried out towards the end of the software development, where the applicationis validated against the requirements of the end user. To explain the difference between end-to-end testing andsystem testing further, we can take an example. If an email page is being tested, the starting point in end-to-endtesting is logging into the page, while the end point is when you log out of the page. On the other hand, systemtesting is when you work through entire system, like logging into the system, sending an email, opening an email,replying to an email, forwarding the email, etc., and finally logging out of the system. Any defects in moving fromone component to another and the working of the component itself is the aim of system testing. Therefore, end-to-end testing is often considered to be a subset of system testing.

Software Testing Artifacts

Software testing process can produce various artifacts such as:

Test Plan: A test specification is called a test plan. A test plan is documented so that it can be used to verify andensure that a product or system meets its design specification.

Traceability matrix: This is a table that correlates or designs documents to test documents. This verifies that thetest results are correct and is also used to change tests when the source documents are changed.

Test Case: Test cases and software testing strategies are used to check the functionality of individual componentsthat are integrated to give the resultant product. These test cases are developed with the objective of judging theapplication for its capability or feature.

Test Data: When multiple sets of values or data are used to test the same functionality of a particular feature in


31/34


the test case, the test values and changeable environmental components are collected in separate files andstored as test data.

Test Script: The test script is the combination of a test case, test procedure and test data.

Test Suite: Test suite is a collection of test cases.

Measuring Software Testing

There arises a need for measuring the software, both, when the software is under development and after thesystem is ready for use. Though it is difficult to measure such an abstract constraint, it is essential to do so. Theelements that cannot be measured cannot be controlled. There are some important uses of measuring thesoftware:

Software metrics help in avoiding pitfalls such as:

1. Cost overruns2. In identifying where the problem has raised3. Clarifying goals

It answers questions such as:

1. What is the estimation of each process activity?2. What is the quality of the code that has been developed?3. How can the underdeveloped code be improved?

Some of the common software metrics are:


32/34


Code Coverage Cyclamate complexity Cohesion Coupling Function Point Analysis Execution time Source lines of code Bug per lines of code

Manual Testing FAQ's

1. Validation vs. Verification Verification answers the question, Am I building the product right, while validation answers the question, Am Ibuilding the right product. To explain it further, verification is carried out at the end of every phase to ensure thatthe software has been developed in accordance with the conditions set up at the beginning of the said phase. Onthe other hand, validation is carried throughout the software development life cycle, to ensure that all therequirements are satisfied.

2. What is severity and priority?

Impact the defect has on working of the system is called severity. It is the tester, who decides severity of thedefect found in the system. Priority, however, is used to describe level of importance of the defect from customeror business standpoint. The developer is the one, who will decide priority of the defect logged in.

3. Tell me in short about requirement testing? Requirement testing has an important role to play in entire software testing process. In this testing methodmissing, vague, incomplete and wrong requirements are tracked down, because if the software is made with


33/34


wrong, incomplete or wrong requirements, then the software may not serve the purpose it was developed for. Itensures incomplete requirements do not make their way into the software.

4. Explain boundary value analysis in brief. It is an integral part of black box testing, where tests are carried out using values on the boundary. It can eitherbe a maximum value or a minimum value permitted for that input or output. It helps in analyzing, if the systemperforms in the desired manner for both ends of the spectrum.

5. Differentiate between Usability and Functional testing. In usability testing, application is tested to find, if there are errors pertaining to functioning of the software. Forexample, if software gives erroneous messages, which can confuse the user is a part of usability testing.Functional testing is carried out to find, if the software performs an action it is not supposed to. A classic examplecan be when the software accepts an erroneous username and/or password and logs into the system.

6. What is a Test Strategy? This is a document, which is used to define the test approach for a particular software. It is decided using systemrequirement specification document. In the initial phase, test plan is drawn using this document, however, sincethe document is not updated at regular interval, it may not prove to be useful in case there is a change in systemrequirement specification.

7. Explain in short a 'test case' It is in a test case, that desired behavior of the software is described. It includes input, expected output alongwith the action as well as the actual output. Different parameters, which are essentially a part of a test case aretest case objective, test conditions, input data, test case name, etc. Test cases are normally prepared at thebeginning of the development cycle to ascertain that requirements specification document does not have aproblem.


34/34


8. Explain: a test suite Several test cases put together is known as test suite. Often a test suite is designed for every component ofsoftware under test. Post condition of the first test case becomes the precondition of subsequent test case.

9. Differentiate between Load and Volume Testing. As the name suggests, load testing checks whether the system works as it is supposed to work, when load on thesystem increases. Increased load can either be due to increase in number of users at the same time or it can bedue to numerous transactions taking place on the system simultaneously.

10. Distinguish between regression testing and retesting.

Regression testing is testing the software after changes have been made to it, in order to ensure no new bugshave been introduced in the software. The added advantage of regression testing is that any undiscovered bugsmay also come to fore. Retesting on the other hand is running the same set of test cases on the system, whichfailed during the last round of tests, after changes were carried out to the software. This helps in verifyingcorrective actions taken on the software.

01. Introduction to Software Testing_v19

Documents

Transcript of 01. Introduction to Software Testing_v19