How to Improve Software Testing Process / Practice

Improving the testing process is not the responsibility of test team only. It is a joint effort of Development & Testing team and Management to understand the health of existing testing process and identify the necessary measures to improve it.

Points for Software Testers:

1. Try to understand the logic behind the screen and try to break that logic. Understand the internal workings of code from developers during lunch time or tea breaks.
2. Analyse test results thoroughly. Try to identify root cause from functional perspective.
3. Break the application into smaller functional modules.
4. First write test cases for valid conditions, then cover invalid conditions.
5. While writing test cases, refer design documents as well.
6. As soon as you complete the test case writing, share test case with development team. It could result in time saving.
7. During test case writing phase, group test cases using impact analysis. It will help in effective regression testing in less time.
8. If you are new tester for a old development team, have a look on old bug reports of modules / project where development worked previously. Generally developers, repeat similar mistakes.
9. Test the application for both implicit as well as explicit requirements.
10. Never communicate bugs verbally. For any critical / show stopper bugs, have an immediate discussion & then document via mail and share it to relevant stack holders.

Difference Between System Testing and End to End Testing

System Testing: In System testing, we will test the functional, performance and usability of the software. This includes stress, usability and performance testing. For Example, if we are testing a web application, we will check if the website is performing correctly as per the software requirements or not.

End to End Testing:  End to end testing means testing the flow of the functionality of the software from start point to end point. For Example, checking whether the functionality of web application from starting to end.

Severity and Priority of Defects

Generally we have to set the Severity and Priority level for a Defect. Severity level will be set by the Testing Team and the Priority level will be set by the Development Team.

Severity : Severity means how much severe is the particular defect in the application (i.e.) how it affects the functionality of the application.

Severity levels: Trivial, Minor, Major, Critical, Block

Priority : Priority means the importance and urgency to fix the defect by the developers (i.e.) which defect should be fixed first and which should be fixed in later versions.

Priority Levels: Low, Medium, High, Urgent, Immediate.

The Severity and Priority levels must vary depends upon the company and the defect tracking tool used by the company.

Some E.G:

Low Priority: Spelling mistakes, grammatical errors, Textual Errors, Orphan pages, broken links, GUI errors,

High Priority: Wrong Functionality, Applications Crashes, Errors.

Practical Differences in Verification and Validation

No	Verification	Validation
1	Verification is a STATIC testing procedure.	Validation is DYNAMIC testing procedure.
2	It involves verifying the requirements, detailed design documents, test plans, walkthroughs and inspections of various documents produced during the development and testing process.	Validation involves actual testing of the product as per the test plan (unit test, integration test, system test and acceptance test etc).
3	It is a PREVENTIVE procedure.	It is a CORRECTIVE procedure.
4	Are we building the product RIGHT?	Are we building the RIGHT product?
5	It involves more than two to three persons and is a group activity.	It involves the testers and sometimes user.
6	It is also called Human testing, since it involves finding the errors by persons participating in a review or walk through.	It is also called Computer testing, since errors are found out by testing the software on a computer.
7	Verification occurs on Requirements, Design and code.	Validation occurs only on code and the executable application.
8	Verification is made both in the Executable and Non Executable forms of a work product	Validation is done only on Executable forms of a work product.
9	Verification finds errors early in the requirement & design phase and hence reduces the cost of errors.	Validation finds errors only during the testing stage and hence cost of errors reduced is less than Verification.
10	An effective tool for verification tool is a Checklist.	Various manual and automated test tools are available for Validation.
11	It requires cooperation and scheduling of meetings and discussions.	It is to check that the product satisfies the requirements and is accepted by the user.
12	Verification tasks include: 1) Planning 2) Execution	Validation tasks include: 1) Planning 2) Test Development 3) Test Execution 4) Test Maintenance
13	Verification activities include: 1) Requirements Verification 2) Functional design verification 3) Internal Design Verification 4) Code Verification	Validation activities include: 1) Unit testing 2) Usability testing 3) Function testing 4) System testing 5) Acceptance testing
14	Verification deliverables (work products) are: 1) Verification test plan 2) Inspection report 3) Verification test report	Validation deliverables are: 1) Test plan 2) Test Design Specification 3) Test Case Specification 4) Test Procedure Specification 5) Test log 6) Test incident report

Test Case Design - Effectiveness and Efficiency

A test that exercises the software in ways that we know will work proves nothing.

We know that if we run the same test twice we learn very little second time round. If we know before we run a test, that it will almost certainly work, we learn nothing. If we prepare a test that explores a new piece of functionality or a new situation, we know that if the test passes we will learn something new - we have evidence that something works. If we test for faults in code and we try to find faults in many places, we increase our knowledge about the quality of the software. If we find faults, we can fix them. If we do not find faults, our confidence in the software increases.

Effective Tests: When we prepare a test, we should have some view on the type of faults we are trying to detect. If we postulate a fault and look for that, it is likely we will be more effective. In other words, tests that are designed to catch specific faults are more likely to find faults and are therefore more effective.

Efficient Tests: If we postulate a fault and prepare a test to detect that, we usually have a choice of tests. We should select the test that has the best chance of finding the fault. Sometimes, a single test could detect several faults at once. Efficient tests are those that have the best chance of detecting a fault.

By: Mann Bhammar

      Test Analyst

Object Identification in QTP

Generally for every object 20-25 properties description are available in QTP, it recognizes object uniquely using 2 or 3 important one.

QTP has default object identification configuration for every environment, if we feel that configuration is not sufficient for recognizing objects in our application, we can configure some more.

There are three type of Object Identification:

1. Normal Identification: Mandatory and Assistive Properties
2. Smart Identification: Base Filter and Optional Filter Properties
3. Ordinal Identifier: Location, Index and Creation Time (Only for Browser).

1. Normal identification:

First of all the QTP learns all the mandatory properties whether these are enough to identify the object uniquely. If it still can’t identify the object then it looks for assistive properties. Ordinal Identifier is used when mandatory and assistive properties are failed to identify the object.

2. Smart Identification:

Smart identification is an optional feature, if we feel normal identification is not sufficient for any object, and then we configure Smart Identification for that object, in order to avoid Ordinal Identifier.

After normal identification if QTP is not satisfied then it goes to smart identification. In smart identification 2 types of properties available, first QTP learns all base filter properties at a time and thinks whether these properties are sufficient for identifying the object uniquely. If it feels sufficient, then it stops learning otherwise it goes Optional Filter Properties and learns one by one. Still it feels not satisfied finally it goes to Ordinal Identifier.

3. Ordinal Identifier: For more information on ordinal identifier click here....

By: Mann Bhammar
      Test Analyst

Difference between wait and sync in QTP

Wait:-Wait statements instruct QuickTest to wait a specified amount of time before proceeding to the next step.

syntax: Wait(10)
Here the QTP will wait for 10 sec and after that it will proceed for the execution of the next step

Sync:
This method is only available for Web.
This method can be used to synchronize the test execution with a new web page that has to appear in the browser.
This method is used when QTP is not sure how long it is going to take to load page

Regular Expressions in QTP

Regular expressions enable QTP to identify objects and text strings with varying values. You can use regular expressions only for values of type string.

It can be used when:

• Defining the property values of an object in dialog boxes or in programmatic descriptions.
• Parameterizing a step.
• Creating checkpoints with varying values.

We can define a regular expression for a constant value, a Data Table parameter value, an Environment parameter value, or a property value in Descriptive programming. 

We can define a regular expression in standard checkpoint to verify the property values of an object; we can set the expected value of an object's property as a regular expression so that an object with a varying value can be verified.

We can define the text string as a regular expression, when creating a text checkpoint to check that a varying text string is displayed on our application, For XML checkpoints we can set attribute or element values as regular expressions. 

In QTP, when working with Regular Expressions and varying object descriptions can be handled by using Descriptive Programming.

E.G:  Let assume in my Gmail Account I have one unread mail into my Inbox(2) and once I read one mail now it is Inbox(1). In this scenario we will use Regular Expression as shown in script.

'DP for Inbox(2)

cm_d("text").value = "Inbox.*"     ‘.* is used as Regular Expression

If Link(cm_d).Exist(2) Then

    Link(cm_d).Click

            else

            msgbox "Link not present"

End If

By Mann Bhammar

     Test Analyst

What is IIS?

IIS stands for Internet Information Services. It’s a group of Internet servers (including a web or hypertext Transfer Protocol server and a File Transfer Protocol) with additional capabilities for   Microsoft’s Windows NT and Windows 2000 server operating systems.

IIS is used to make the computer as a web server. If we want to have a web server for developing dynamic website or want to publish web site on our own server then we install the IIS. IIS is used on windows platform. For other platform we have different web servers (Example: Apache for Linux)

IIS takes a request from user and executes the required files and sends result back to the user. It also provides the services of SMTP (Simple Mail Transport Protocol). We can send emails using SMTP.

When to use Descriptive Programming in QTP ?????

• When object (properties) are dynamic. Ex: “Logout << Username >> or You are Signed in as << User >>
• When Object Repository is getting very large.
• When you don’t want to use Object Repository. As the OR is being shared and used by other scripts, and you don’t want to change the properties in shared OR.
• When there is no object repository. Ex: When the application is still in development and we are building an automation framework parallel to the SDLC.
• When same objects repeat in every page. Ex: Links like Logout, Help, Contact FAQ’s are present in every page of your web application and adding these repetitive objects to repository is not a good option.

By: Mann Bhammar

      Test Analyst

Fundamental Test Process in Software Testing

Fundamental Test Process:

It involves planning, specification, execution, recording and checking for completion.

·         Specification:

It involves designing test cases and test conditions using Test techniques identified at the planning stage. It is important to determine the expected results prior to test execution.

Test Techniques

1.       Formal technical review:

      A formal technical review is conducted by the software quality assurance group.  It examines only a small part of the software project. Only one developer is responsible for the artifact. The artefact is examined on various levels. It includes things like function and logic as well as implementation. It ensures that all artifacts of the project developed in a uniform manner. Typically a review will last 2 hours. The review may consist of walk-through s, code inspections or any other examination. Since the purpose of a review is to find errors, a review can be difficult to control

2.       Code walk-through :

      A source code walk through often is called a technical code walk through or a peer code review. The typical scenario finds a developer inviting his technical lead, a database administrator, and one or more peers to a meeting to review a set of source modules prior to production implementation. Often the modified code is indicated after the fact on a hard copy listing with annotations or a highlighting pen, or within the code itself with comments. 

        A code walk through is an effective tool in the areas of quality assurance and education. The developer is exposed to alternate methods and processes as the technical lead and database administrator suggest and discuss improvements to the code. The technical lead is assured of an acceptable level of quality and the database administrator is assured of an acceptable level of database performance. The result is better performance of the developer, his programs, and the entire application. 

       Despite all the benefits of source code walk through s, few organizations implement and enforce them as a shop standard. Many excuses are given, but each has a practical solution.

·         Execution:

It involves running the specified test on a computer system either manually or by using an automated test tool.

·         Recording:

       It involves keeping good records of the test. The tested versions, the tested specifications of software and the test specifications are recorded along with the actual outcome of each test.

·         Successful tests detect faults:

        A successful test is one that detects a fault and may cause a delay.

·         Completion or exit criteria:

      Completion or exit criteria are used to determine when testing is complete. It may be defined in terms of cost, time, faults found or coverage criteria.

·         Coverage criteria:

       Coverage criteria are defined in terms of items that are exercised by test suites, such as branches, user requirements, most frequently used transactions etc

Functional (Black Box) Testing and Structural (White Box) Testing

Functional Part is a software testing approach in which: 

• This is done by Testers.
• Functional Testing is also known as Black Box Testing or behavioural testing.
• The tester will have a user perspective in mind.
• It focuses on the functional part of the application.
• He doesn’t know how the program works in back end.
• He will only concentrate in input and output of the application or product.
• The tester acts as if he/she is the final user of the program.

On other hand Structural Part, is a software testing approach in which: 

• Structural Testing is also known as white-box testing or Glass Box testing.
• The tester will have a developer perspective in mind or this is done by Developer.
• Sometime tester acts as a developer of the program who knows the internal structure of the program very well.
• He or she will know how the program works behind the scene, with knowing the Internal Knowledge of the product /Application.
• Its main focus is on the structural part means in coding/programming part.
• Structural is mainly focused on internal code whereas functionality is verified with respect to SRS. 

Please also refer below table for more understanding.

Differences between Black Box Testing and White Box Testing:

Criteria	Black Box Testing	White Box Testing
Definition	Black Box Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is NOT known to the tester	White Box Testing is a software testing method in which the internal structure/ design/ implementation of the item being tested is known to the tester.
Levels Applicable To	Mainly applicable to higher levels of testing: Acceptance Testing and System Testing	Mainly applicable to lower levels of testing: Unit Testing & Integration Testing
Responsibility	Generally, independent Software Testers	Generally, Software Developers
Programming Knowledge	Not Required	Required
Implementation Knowledge	Not Required	Required
Basis for Test Cases	Requirement Specifications	Detail Design

By: Mann Bhammar

       Test Analyst