Software Testing by Nithinbob

8/13/2019 Software Testing by Nithinbob

1/25

2. FUNDAMENTALS OF TESTING [25m]TESTING:Testing is a process to check whether the software meets the user requirements

or not. Hence there is a testing corresponding to every phase of development.

When testing is done, the reason for failure is identified and defects are found.

TESTING v/s DEBUGGING:TESTING DEBUGGING

Testing is done to find the defects Debugging is done to find cause of

defect.

Tester can test the software and they

need to able to describe when the

defects have occurred and what

happened after it occurs.

It involves finding out which part of

the code is causing defect, modify that

code and check whether the defect has

been removed or not.

Tester can only find out the failure Debugging involves correction of code

as per the test cases.

TESTING v/s BEBUGGING: To check the effectiveness of the software, sometime the bugs are

intentionally introduced in the software, this is known as bebugging.

Testing is the main concept that can be used to find defects. Bebugging involves inputting a wrong value and checking that it is

showing error msg or not.


2/25

VERIFICATION VALIDATION: VALIDATION is to check whether the software meets the customer

expectations.

Are we building the right product.

VERIFICATION is to check whether the software conforms to specificationsIt is done in various phase while developing the software.

Are we building the product right.

SIGNIFICANCE OF TESTING: As a result of communication gap between the user and requirement

analyst, the software would not have been developed as per the user needs

Due to the communication gap between the developers, when a largenumber of developers work on the project, the complete functionality

required would not have been implemented.

The individual programmer should be expert in coding. otherwise it maylead to defective code.

After the developer has developed the software, the software must be testedby the test engineer before delivering it.

Software must ensure that security, privacy and safety of user and userdata are taken care by rigorous testing.

The software should be developed in hurry and quality should bemaintained because of the clients pressure.

Due to the clients budget problem, the developer will compromise with thequality of the software.


3/25

TESTING CHOICES:A software/IT organization has two choices to do testing.

Inhouse testing. Out sourcing testing.

In inhouse testing,

The intellectual property will not be given out to 3rdparty. The management will have total control over time and budget. Test engineer can interact with the developer on need basis.

In Outsourcing,

It will be having a large number of human resource environments. It results in lot of cost saving. Testing is done faster in this method.

WHO DOES THE TESTING? Depending on the complexity of the project and critically of the

application, test team size will be different.

Larger organization can afford to have dedicated test teams for eachproject.

But smaller organizations will either make another development team totest or test engineers are recruited on part time or contract basis.

When the developer needs to do testing, then he must consider thesetesting.

UNIT OR COMPONENT TESTING(smallest testing procedure)


4/25

INTEGRATION TESTING(interface b/w the modules) BUDDY TESTING(2 people sit together n does testing) When an independent test engineer wants to test the software he must

consider these points,

He should have an excellent knowledge of the application domain andalso study all the work products like SRS, design document etc.

To review the code he should be familiar with the programminglanguage and the source code.

Test engineer need to contact and interact with the developer to come outwith a good testing strategy.

Test engineer need to tell the developer that their software has problemsbut in a very polished way.

V-MODEL:

USER NEEDS

SRS DOCUMENT

DESIGN

UNITs/COMPONENT

MODULE TESTING

SYSTEM TESTING

ACCEPTANCE TEST


5/25

The user needs are converted into user requirements. Based on the user requirement, the SRS document has to be prepared. Base on that SRS document, the design is carried out and the design

document is made.

Based on the design, the different modules are designed and eachmodule is further divided into units/components.

Each unit/component should be coded and tested. The components are integrated into modules and these modules are

tested.

Then the modules are integrated into system and a system testing is doneto ensure that the software is as per the user requirement.

Then the Acceptance testing is done to check whether the software meetsthe entire user requirement.

After the software has been installed, operational testing should be doneto check user side errors that may occur when the software is used.

TESTING THE SYSTEM:The system testing is done to ensure that the software is as per the user

requirement.

Functional requirement. Nonfunctional requirement.

Functional requirement specify what the software does, here the results are

obtained through the software have to be compared with the existing

requirement document.

Nonfunctional requirement are generally divided into 3 types,


6/25

Product requirements. Process requirements. External requirements.

The engineer will choose which of these nonfunctional requirements are

suitable for the software and only those will be mentioned in SRS document.

TESTING STRATEGIES:There are two types of testing,

Static testing. Dynamic testing.

In static testing,

The code is checked without executing it. Static testing is done throughcode reviews which are carried out formally and informally.

The programmer and its team must study the code and check for errorsAnd he must ensure that the software is as per the user requirements.

In dynamic testing,

The code is executed and tested. The code is compiled executed with the help of inputs. Is the actual result match with the expected result then the software

considered as ok.

This can detect more errors than the static testing where in static testingcode is tested without executing it.


7/25

WHY TESTING IS DIFFICULT: While testing we need to give all possible inputs to make sure that it is

going to find out the errors.

We need to test the software for both valid and invalid inputs and checkthe functionality as well as performance of the software.

We need to give the inputs in such a way that each and every line of thecode is tested.

We need to give inputs randomly and check that the software never fails. We need to test the software as a normal user using it and check whether

the necessary error message, help etc are provided. We need to test the software in different environment.

TEST CASES: A test case consisting of test inputs. It has mainly 4 criteria, Test inputs. Entry criteria. Expected result. Exit criteria. Test inputs include giving input to a system. Entry criteria involve condition before the inputs are executed. Exit criteria involve condition after the inputs are executed.

Entry Exit

Test inputs Test results

Executable

code


8/25

Number of test cases is selected and it is executed, then the test result iscompared with the actually expected result.

For example, we consider a program that inputs a filename. Input type: file1.txt Entry criteria: file1 should not exist in the current directory. Expected result: file1 should be saved in the current directory. Exit criteria: the program should terminate without any errors and the

file should be available in current directory.

Designing test case is still a creative activity to find out the all possiblebugs.

MANUAL v/s AUTOMATED TESTING:In manual testing the job of the test engineer is as follows,

Form and study the specification design to test . Design test cases. For each test case, ensure that the necessary test setup is made and all the

user needs are met.

Give the test inputs. Check whether the test result is matching with the expected output. If it is not correct, then there is a defect, so enter the defect details in

database.

Select test case Execute test case Analyze test

result


9/25

Repeat the entire process for all the test cases. The disadvantage of manual testing is the repeating process. The automated testing is a software testing tool which is going to test the

software with the help of testing condition.

3. TESTING LEVELS AND TYPES [25m]LEVELS OF TESTING:Testing levels are divided into many levels and those are,

Unit/component test Integration test System test Acceptance test Testing in actual environment

In unit/ component testing,

It is the smallest entity in the software. Every unit has to be tested and executed separately to check whether it is

as per the user requirement or not.

Unit testing can only be done by the development engineers.In module testing,

A module is an independent entity in software. When the units are integrated into modules, each module has to be tested

as per the user requirements.


10/25

In integration testing,

The interface between the modules is checked. Integration test has to be done step by step.

In system testing,

The complete design of the software has to be checked as per the userrequirements.

SRS documents have to be checked as per the functional andnonfunctional requirements given by the clients.

In acceptance testing,

It is done at the client/user side. Here the test engineer should test the software in actually user

environment.

STATIC v/s DYNAMIC TESTING:Static testing,

The code is checked without executing it. Static testing is done throughcode reviews which are carried out formally and informally.

The programmer and its team must study the code and check for errorsAnd he must ensure that the software is as per the user requirements.

In dynamic testing,

The code is executed and tested. The code is compiled executed with the help of inputs.


11/25

Is the actual result match with the expected result then the softwareconsidered as ok

This can detect more errors than the static testing where in static testingcode is tested without executing it.

POSITIVE v/s NEGETIVE TESTING: Positive testing ensures that the project is working as we planned. In positive testing the valid inputs are given to ensure it is as per the user

requirement.

Negative testing ensures that the software does not fail when invalidinputs are given.

Negative testing also ensures that it is showing appropriate error messageto the user when it is used.

In this case, testing becomes a destructive process.

TOPDOWN v/s BOTTOMUP TESTING: Top down design approach will starts testing from the top level of the

application.

And goes on down ward till the last component of the software is tested. Bottom up approach will start testing the bottom module like units and

components and goes to next level.

Then interconnection b/w modules are tested. Design documents are tested and it goes on until the top level is tested.


12/25

FUNCTIONAL v/s STRUCTURAL TESTING: Testing the various functionality of the software as per the user

requirement is known as functional testing.

In functional testing what does the software do is tested. Andfunctionality of the modules is also tested.

Structural testing involves,

Each and every statement is executed and tested at least once as per theuser requirement.

Here inputs are given in such a way that it is going to check all part ofthe code.

Each path is executed once. Each function should be called once.

TYPES OF TESTING:SMOKE TESTING:

When the modules are integrated and software is ready to use, then somebasic functionality of the software is tested.

BLACK BOX TESTING: In black box testing, the functionality of the software is tested without

considering the implementation and execution.

In this testing, we must ensure that each and every functionality of thesoftware has been checked as per the user requirements.


13/25

WHITE BOX TESTING: In white box testing each and every part of the code is tested. We must ensure that every statement has been executed at least once. It also specifies the internal logic of the program.

INTERFACE TESTING: It is done to ensure that the interface / interconnection between the two

modules are correct.

H/w to h/w interface: it is done to ensure the interface between the twohardware components.

S/w to s/w interface: is to ensure the interconnection between 2 differentsoftwares.

H/w to s/w interface: is to ensure that how the hardware interact with asoftware.

Human computer interface: where all GUI elements are tested.GORILLA TESTING:

Gorilla testing is used to test the software by pressing some keys randomly. Gorilla testing is done just like an animal which is using the software

and does not knows anything about the software.

It is used to check whether any defects occur when wrong inputs aregiven.

BETA TESTING: Beta testing is done by the client/ user in the absence of developer team. It is mainly based on the usability and performance of the software. In beta test, following test plans are made, The number of beta test suites.


14/25

The environment required for beta testing where exact h/w and s/wconfigurations has to be specified.

The help line has to be specified and worked out. Whether the beta test service is priced or free. Beta testing is actually done when development and testing is finished

and final defects and problems need to be found by the test engineer as a

user as before the final release.

STRESS TESTING: Stress testing is done to evaluate the system beyond the limits of specified

requirements. It mainly focuses on how the software behaves in extreme conditions.

CONFORMANCE TESTING: Conformance testing ensures that the project meets all the standards that

are defined by some of the standard bodies.

The standards are specified to provide,

Interoperability among different vendors. Safety to the user. Compatibility with the government regulation. Special feature like disabling the software. Privacy to the user. Security to the user.

Testing the software for conformance of standards is a highly specialized

activity.


15/25

SECURITY TESTING: Security testing is done to ensure that the software can defend all the

attacks or not.

It is highly specialized activity so you need to think like a thief to catch athief.

During this test, test engineers concentrate on following factors,

Authorization: whether a valid user is accessible or not and an invaliduser is preventable or not.

Access control: whether a valid used has permission to use specific serviceor not.

Encryption: is to convert the conversation between client and the serverto prevent third party access.

4.STATIC TESTING TECHNIQUES [25m]ADVANTAGE OF STATIC TESTING:

Incorrect specifications and missing specifications can be found at anearly stage of development and hence lot of rework has been reduced.

Incorrect design can be found early and hence life cycle time isreduced.

Specifications can be checked against the code so that if somerequirements are not implemented, they are detected early.

It ensures that code is also as per the user requirement.


16/25

It ensures that all the coding guidelines are followed so that themaintainability of the software becomes easier.

Time effort and cost factors are checked to reduce the estimation and toincrease the productivity along with quality.

FORMAL REVIEW PROCESS:A formal review is done by the project manager based on the work product.

The review process consisting of following steps,

1] DEFINE REVIEW OBJECTIVE:Review objective ensures that it is,

To detect errors. To detect the defect and discuss how to rectify them. To assign responsibility to a person for rectifying the defects.

2] IDENTIFY THE REVIEW TEAM:The project manager has to review a team consisting of,

AUTHOR: author of the project is specified. REVIEWERS: two or more reviewers have to be set who has an expert

knowledge over any kind of software.

SECETORY: to maintain and store all meeting details and importantpoints discussed during the meeting.

MODERATOR: responsibility is to complete the meeting without anyharmful arguments between the author and reviewers.

MANAGER: manager is one who identifies and plans review meeting.


17/25

3] PLAN THE MEETING:Once the review team is ready, then following activities starts,

PREPARATORY ACTIVITIES: the relevant document about objectives andagendas of project is distributed to every member of the team.

ACTUAL REVIEW MEETING: in this meeting, a designated person willexplain the product and necessary issues are discussed.

REWORK: action points are defined and errors are rectified by theauthor.

MAKING REVIEW SUCCESFULL: Review is done to find the defects, not to find out who did the mistake. The moderator has to ensure that members discuss issues but not argue. The team members should not get emotionally attached to their work. The objectives of the review meeting should be defined. The review team should have expertise persons.

Every member of the team should be prepared for meeting review. Checklists and coding guidelines are specified. Project manager should provide the necessary documents for meeting. The review should help in improving overall software development.

CHECKLISTS:The lists that are used to check all the requirement specification of the

software.

The check list has to be prepared and the work product should be checked by

the review team.


18/25

SRS CHECKLISTS: Is there any ambiguity in the SRS document because of the natural

languages?

Are the user requirement is covered in the document or not. Is every functional and nonfunctional requirement is specified in the

document or not.

It is easy to make changes in the SRS document. Is that SRS is usable during the remaining stages of development. Is SRS is validated by the client or not.

DESIGN CHECKLIST: Is every functional requirement is specified or not. Are the performance requirements are met. Are the design constraints are met or not. Are the external interface is specified.

Is error handling taken care. Is the help engine designed and integrated. Are the chosen algorithm is correct. Are data structures are identified.

GUI CHECKLISTS: Is the application starting when the icon is double clicked. Is the application starting twice when the application icon is double

clicked twice.

Is every window having the correct title.


19/25

Do all the screens have good look and feel. If a wrong input is given to the application, and then is an error message

is displayed.

Does each push button have a short cut key.

WEBSITE CHECKLISTS: Does the website works exactly in the same way for all the web browser. Is every link is checked. Is the content getting downloaded in max 10 seconds. Is there a site map. Is there a search option. Is accessibility to disabled provided?

CODING GUIDELINES:PROGRAMMING STYLE:Every programmer has to follow certain guidelines while doing the coding.

The code should be easy to understand. Names of variable, functions and files should not be cryptic but

meaningful.

Function size should be within 40 to 50 lines. Module size should be limited as per the coupling. Deep nesting should be avoided. There should be no magic numbers.


20/25

C CODING GUIDELINES:Some guidelines for C programming is,

For every project there should be a folder that contains all the sourcecode files.

The backup of the project folder should be made. Every file should contain a header that gives the copyright information,

name of the file, author.

All the variables, functions, structures should have meaningful names. Online document should be relevant.

JAVA CODING GUIDELINES: Backup policy should be adopted. For every project there should be a folder that contains all the source code

files.

All the names of directories and files should be meaningful. The header should be in javadoc format. Naming the parameter should be meaningful. Document should give clear picture. Such as purpose of the class, the types

of parameter, development and maintainance.


21/25

5. DYNAMIC TESTING [25m]

EQUIVALENCE PARTITIONING:In this technique all the positive (valid) and negative (invalid) inputs are

given in a test case to ensure that all requirements of client is met.

A group of tests forms an equivalence class if,

All these tests test the same thing. If one of the tests in the group catches a bug, then all the tests in the

group will catch the bug.

If one of the tests in the group does not catches a bug, then all the tests inthe group will not catch any type of bug.

In this technique all the inputs are divided into valid and invalidinputs.

For example,

For a program that takes 3 numbers as input and checks whether the numberform a triangle or not.

In the above problem, the equivalence classes are,

EQUIVALENCE CLASS 1:

The equivalence class 1 contains all the possible valid inputs which are

defined by the test cases.

So if one test case in equivalence class 1 shows exact ouput then every test case

should get the exact output.


22/25

EQUIVALENCE CLASS 2:

The equivalence class 2 contains all the possible invalid inputs which are

defined by the test cases.

So if one test case in an equivalence class 2 fails then every test case should get

failed.

BOUNDRY VALUE ANAALYSIS: We will write the test cases based on the boundary values that are

specified and from which the defects can be identified.

It is a black box testing method which divides the program into class ofdata.

It is a test case design technique that complements equivalencepartitioning.

Rather than selecting any element from class of data, BVA leads to theselection of test cases at the edge of class.

For example,

For a program where marks has to be inputted. The boundary value for marks is 0 to 100. Here the input which is within 0 to 100 should be accepted. And inputs below 0 and above 100 should not be accepted.


23/25

CAUSE EFFECT ANALYSIS:In this method, for each cause (input) an action (effect) has to be declared.

And based on this input and action, the cause effect graph is drawn.

For example, consider withdrawal form verification in a bank account.

CAUSE 1: account number is correct. CAUSE 2: signature on the withdrawal form matches with that in the

bank database.

CAUSE 3: enough money is available in the account. ACTION 1: give money to the customer. ACTION 2: inform the customer that enough money is not there in the

account.

ACTION 3: call the police and inform that it is fraud case.And all the possible test cases for the above problem is shown below,

TC1: Correct account number, signature matches, enough money. TC2: Correct account number, signature matches, not enough money. TC3: Correct account number, signature does not matches, enough

money.

TC4: Invalid account number, signature matches, enough money.

STATE TANSITION DIAGRAMS (STD): This diagram is used to indicate the different states of a system. The STD helps in choosing the various test cases and ensures that each

and every state is tested.


24/25

The above STD specifies, In PBX call office, when we dial correct 3 digit number,

the call is established and conversation is carried out.

Some of the test cases for this example are as follows,

TC 1: go offline and disconnect. TC 2: go offline, dial 1stdigit and disconnect. TC 3: go offline, dial 2nddigit and disconnect. TC 4: go offline, dial 3rddigit and disconnect. TC 5: go offline, dial 3 digits, disconnect after conversation.

ON

Establish

Call

Conversation

OFF

1

digit

2

digit

3

digit


25/25

STRUCTURAL TESTING:STRUCTURAL TESTING AT MODULE LEVEL:

In structural testing, when the units are integrated into modules thenthe modules are tested for its performance over other modules.

Here the modules structure is considered mainly. For example consider software for banking. Here account is an abstract

class and savings, fixed, and current account are the derived class.

For above example, the structural testing will create objects for onlysavings, fixed, and current account which is derived.

STRUCTURAL TESTING AT SYSTEM LEVEL:

When you interconnect modules and develop the complete system, you willknow how the modules are interconnected and hence using that

information, testing is done.

Software Testing by Nithinbob

Documents