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 Testing is done to find the defects DEBUGGING Debugging is done to find cause of defect. Tester can test the software and they It involves finding out which part of need to able to describe when the the code is causing defect, modify that defects have occurred and what code and check whether the defect has been removed or not. Debugging involves correction of code as per the test cases.

happened after it occurs. Tester can only find out the failure

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.

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 specifications. It 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 large number 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 may lead to defective code. After the developer has developed the software, the software must be tested by the test engineer before delivering it. Software must ensure that security, privacy and safety of user and user data are taken care by rigorous testing. The software should be developed in hurry and quality should be maintained because of the clients pressure. Due to the clients budget problem, the developer will compromise with the quality of the software.

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 3rd party. 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 each project. But smaller organizations will either make another development team to test or test engineers are recruited on part time or contract basis. When the developer needs to do testing, then he must consider these testing. UNIT OR COMPONENT TESTING(smallest testing procedure)

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 and also study all the work products like SRS, design document etc.

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

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

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

V-MODEL:

USER NEEDS

ACCEPTANCE TEST

SRS DOCUMENT

SYSTEM TESTING

DESIGN

MODULE TESTING

UNITs/COMPONENT

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 each module 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 done to ensure that the software is as per the user requirement.

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

After the software has been installed, operational testing should be done to 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,

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, In static testing, The code is checked without executing it. Static testing is done through code reviews which are carried out formally and informally. The programmer and its team must study the code and check for errors. And 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 testing code is tested without executing it. Static testing. Dynamic testing.

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 check the functionality as well as performance of the software. We need to give the inputs in such a way that each and every line of the code 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 Test inputs
Executable code

Exit Test results

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

Select test case

Execute test case

Analyze test 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 possible bugs.

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.

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.

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 user requirements. SRS documents have to be checked as per the functional and

nonfunctional 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 through code reviews which are carried out formally and informally. The programmer and its team must study the code and check for errors. And 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 testing code 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 invalid inputs are given. Negative testing also ensures that it is showing appropriate error message to 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.

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. And

functionality of the modules is also tested. Structural testing involves, Each and every statement is executed and tested at least once as per the user requirement. Here inputs are given in such a way that it is going to check all part of the 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 some basic 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 the software has been checked as per the user requirements.

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 two hardware components. S/w to s/w interface: is to ensure the interconnection between 2 different softwares. H/w to s/w interface: is to ensure that how the hardware interact with a software. 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 are given. 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.

The environment required for beta testing where exact h/w and s/w configurations 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.

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 a thief. During this test, test engineers concentrate on following factors, Authorization: whether a valid user is accessible or not and an invalid user is preventable or not. Access control: whether a valid used has permission to use specific service or not. Encryption: is to convert the conversation between client and the server to prevent third party access.

4.STATIC TESTING TECHNIQUES [25m]

ADVANTAGE OF STATIC TESTING:
Incorrect specifications and missing specifications can be found at an early stage of development and hence lot of rework has been reduced. Incorrect design can be found early and hence life cycle time is reduced. Specifications can be checked against the code so that if some requirements are not implemented, they are detected early. It ensures that code is also as per the user requirement.

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

Time effort and cost factors are checked to reduce the estimation and to increase 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 important points discussed during the meeting. MODERATOR: responsibility is to complete the meeting without any harmful arguments between the author and reviewers. MANAGER: manager is one who identifies and plans review meeting.

3] PLAN THE MEETING: Once the review team is ready, then following activities starts, PREPARATORY ACTIVITIES: the relevant document about objectives and agendas of project is distributed to every member of the team. ACTUAL REVIEW MEETING: in this meeting, a designated person will explain the product and necessary issues are discussed. REWORK: action points are defined and errors are rectified by the author.

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.

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.

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.

C CODING GUIDELINES:
Some guidelines for C programming is, For every project there should be a folder that contains all code 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. the source

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.

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 in the group will not catch any type of bug. In this technique all the inputs are divided into valid and invalid inputs. For example, For a program that takes 3 numbers as input and checks whether the number form 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.

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 of data. It is a test case design technique that complements equivalence

partitioning. Rather than selecting any element from class of data, BVA leads to the selection 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.

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.

ON

OFF

1 digit 2 digit s

Conversation Establish Call

3 digit s

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 1st digit and disconnect. TC 3: go offline, dial 2nd digit and disconnect. TC 4: go offline, dial 3rd digit and disconnect. TC 5: go offline, dial 3 digits, disconnect after conversation.

STRUCTURAL TESTING:
STRUCTURAL TESTING AT MODULE LEVEL: In structural testing, when the units are integrated into modules then the 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 only savings, fixed, and current account which is derived. STRUCTURAL TESTING AT SYSTEM LEVEL: When you interconnect modules and develop the complete system, you will know how the modules are interconnected and hence using that information, testing is done.