Database Connection in VB

Dim con, rs
Set con=createObject("ADODB.Connection")
Set rs=createObject("ADODB.Recordset")
con.provider="microsoft.jet.oledb.4.0"
con.open"d:\database.mdb"
rs.open "select*from Table1" ,con

Test Strategy

Test Strategy

The test strategy is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required. The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team. The test plan may include test cases, conditions, test environment, list of related tasks, pass/fail criteria and risk assessment.

A detailed master strategy should cover the following:

Project Scope

Restate the business objective of the application and define the scope of the testing. The statement should be a list of activities that will be in scope or out of scope. A sample list would include:

* List of software to be tested

* Software configurations to be tested

* Documentation to be validated

* Hardware to be tested

Test Objectives

The system under test should be measured by its compliance to the requirements and the user acceptance criteria. Each requirement and acceptance criteria must be mapped to specific test plans that validate and measure the expected results for each test being performed. The objectives should be listed in order of importance and weighted by Risk.

Features and Functions to be tested

Every feature and function must be listed for test inclusion or exclusion, along with a description of the exceptions. Some features may not be testable due to a lack of hardware or lack of control etc. The list should be grouped by functional area to add clarity. The following is a basic list of functional areas:

* Backup and recovery

* Workflow

* Interface design

* Installation

* Procedures (users, operational, installation)

* Requirements and design

* Messaging

* Notifications

* Error handling

* System exceptions and third-party application faults

Testing Approach

The approach provides the detail necessary to describe the levels and types of testing. The basic V-Model shows what types of testing are needed to validate the system.

More specific test types include functionality, performance testing, backup and recovery, security testing, environmental testing, conversion testing, usability testing, installation and regression testing. The specific testing methodology should be described and the entry/exit criteria for each phase noted in a matrix by phase. A project plan that list the resources and schedule for each testing cycle should also be created that maps the specific testing task to the overall development project plan.

Testing Process and Procedures

The order of test execution and the steps necessary to perform each type of test should be described in sufficient detail to provide clear input into the creation of test plans and test cases. Procedures should include how test data is created, managed and loaded. Test cycles should be planned and scheduled based on system availability and deliverable dates from development. All application and environmental dependencies should be identified along with the procedures necessary to gain access to all the dependent systems.

Test Compliance

Every level of testing must have a defined set of entry/exit criteria which is used to validate that all prerequisites for a valid test have been met. All mainstream software testing methodologies provide an extensive list of entry/exit criteria and checklist. In addition to the standard list, additional items should be added based on specific testing needs. Some common additions are, environmental availability, data availability, and validated code which is ready to be tested. Each level of testing should define specific pass/fail acceptance criteria, to ensure to ensure that all quality gates have been validated and that the test plan focuses on developing test that validate the specific criteria defined by the user acceptance plan.

Testing Tools

All testing tools should be identified and their use, ownership and dependencies defined. The tools category includes manual tools, such as templates in spreadsheets and documents as well as automated tools for test management, defect tracking, regression testing and performance/load testing. Any specific skill sets should be identified and compared against the existing skills identified for the project to highlight any training needs.

Defect Resolution

A plan to address the resolution of failed tests needs to be created that lists the escalation procedures to seek correction and retest of the failed tests along with a risk mitigation plan for high-risk test. Defect tracking should include basic metrics for compliance based on number and type of defect found.

Roles and Responsibilities

A matrix listing the roles and responsibilities of everyone involved in the testing activities, along with the anticipated amount of their time allocated to the project, must be prepared.

Process Improvement

The entire testing process should be focused on process improvement. The strategy should list ways to monitor progress and provide constant feedback. This feedback can serve to enhance the process, deliverables and metrics used in the testing. Root cause analysis should be performed on all reported defects to help isolate the true nature of the problem and prevent unnecessary repeat offenses.

Deliverables

All deliverables should be defined and their location specified. Common deliverables are test plans, test cases, test scripts, test matrix and a defect log.

Schedule

All testing activities should be combined into one master testing schedule. The schedule should include an estimate of time for each task and the dependences for each. Testing resources should be assigned to each task and quality gates should be listed to insure oversight of the entire process.

Environmental Needs

All the requirements of the testing environment need to be listed. Common ones include a description of the environment's use, management, hardware and software, specific tools needed, data loading and security requirements.

Resource Management

The skills of all personnel involved in the testing effort need to be assessed and the gaps noted so that a comprehensive training program can be designed. Specialty skills that will not be filled with in-house staff will require job descriptions and budgeting.

Risk and Contingencies

Planning for risk in advance and ways to mitigate it are essential for a robust strategy. A risk assessment that is prioritized by severity of risk and covers technology, resource, schedule and environmental issues should feed a detailed plan to mitigate each red flag.

Approvals and Workflow

All items on the critical path must go through an approval cycle. The procedures for approval and escalation must be well defined and assigned to resources prior to the start of the testing.

Security Testing

Security Testing

As more and more vital data is stored in web applications and the number of transactions on the web increases, proper security testing of web applications is becoming very important. Security testing is the process that determines that confidential data stays confidential (i.e. it is not exposed to individuals/ entities for which it is not meant) and users can perform only those tasks that they are authorized to perform (e.g. a user should not be able to deny the functionality of the web site to other users, a user should not be able to change the functionality of the web application in an unintended way etc.).

Some key terms used in security testing

Before we go further, it will be useful to be aware of a few terms that are frequently used in web application security testing:

What is “Vulnerability”?
This is a weakness in the web application. The cause of such a “weakness” can be bugs in the application, an injection (SQL/ script code) or the presence of viruses.

What is “URL manipulation”?
Some web applications communicate additional information between the client (browser) and the server in the URL. Changing some information in the URL may sometimes lead to unintended behavior by the server.

What is “SQL injection”?
This is the process of inserting SQL statements through the web application user interface into some query that is then executed by the server.
What is “XSS (Cross Site Scripting)”?
When a user inserts HTML/ client-side script in the user interface of a web application and this insertion is visible to other users, it is called XSS.

What is “Spoofing”?
The creation of hoax look-alike websites or emails is called spoofing.

Security testing approach:

In order to perform a useful security test of a web application, the security tester should have good knowledge of the HTTP protocol. It is important to have an understanding of how the client (browser) and the server communicate using HTTP. Additionally, the tester should at least know the basics of SQL injection and XSS. Hopefully, the number of security defects present in the web application will not be high. However, being able to accurately describe the security defects with all the required details to all concerned will definitely help.

1. Password cracking:

The security testing on a web application can be kicked off by “password cracking”. In order to log in to the private areas of the application, one can either guess a username/ password or use some password cracker tool for the same. Lists of common usernames and passwords are available along with open source password crackers. If the web application does not enforce a complex password (e.g. with alphabets, number and special characters, with at least a required number of characters), it may not take very long to crack the username and password.

If username or password is stored in cookies without encrypting, attacker can use different methods to steal the cookies and then information stored in the cookies like username and password.

2. URL manipulation through HTTP GET methods:

The tester should check if the application passes important information in the query string. This happens when the application uses the HTTP GET method to pass information between the client and the server. The information is passed in parameters in the query string. The tester can modify a parameter value in the query string to check if the server accepts it.

Via HTTP GET request user information is passed to server for authentication or fetching data. Attacker can manipulate every input variable passed from this GET request to server in order to get the required information or to corrupt the data. In such conditions any unusual behavior by application or web server is the doorway for the attacker to get into the application.

3. SQL Injection:

The next thing that should be checked is SQL injection. Entering a single quote (‘) in any textbox should be rejected by the application. Instead, if the tester encounters a database error, it means that the user input is inserted in some query which is then executed by the application. In such a case, the application is vulnerable to SQL injection.

SQL injection attacks are very critical as attacker can get vital information from server database. To check SQL injection entry points into your web application, find out code from your code base where direct MySQL queries are executed on database by accepting some user inputs.

If user input data is crafted in SQL queries to query the database, attacker can inject SQL statements or part of SQL statements as user inputs to extract vital information from database. Even if attacker is successful to crash the application, from the SQL query error shown on browser, attacker can get the information they are looking for. Special characters from user inputs should be handled or escaped properly in such cases.

4. Cross Site Scripting (XSS):

The tester should additionally check the web application for XSS (Cross site scripting). Any HTML e.g. <HTML> or any script e.g. <SCRIPT> should not be accepted by the application. If it is, the application can be prone to an attack by Cross Site Scripting.

Attacker can use this method to execute malicious script or URL on victim’s browser. Using cross-site scripting, attacker can use scripts like JavaScript to steal user cookies and information stored in the cookies.

Many web applications get some user information and pass this information in some variables from different pages.

E.g.: http://www.examplesite.com/index.php?userid=123&query=xyz

Attacker can easily pass some malicious input or <script> as a ‘&query’ parameter which can explore important user/server data on browser.

Important: During security testing, the tester should be very careful not to modify any of the following:

·         Configuration of the application or the server

·         Services running on the server

·         Existing user or customer data hosted by the application

·         Additionally, a security test should be avoided on a production system.

The purpose of the security test is to discover the vulnerabilities of the web application so that the developers can then remove these vulnerabilities from the application and make the web application and data safe from unauthorized actions.

Test Effort Estimation

Test Effort Estimation

Test engineering managers use many different methods to estimate and schedule their test engineering efforts. Different organizations use different methods depending on the type of projects, the inherent risks in the project, the technologies involved etc. Most of the time, test effort estimations are clubbed with the development estimates and no separate figures are available.

Ad-hoc method

The test efforts are not based on any definitive timeframe. The efforts continue until some pre-decided timeline set by managerial or marketing personnel is reached. Alternatively, it is done until the budgeted finances run out. This is a practice prevalent in extremely immature organizations and has error margins of over 100% at times.

·         Percentage of development time

The fundamental premise here is that test engineering efforts are dependent on the development time / effort. First, development effort is estimated using some techniques such as LOC or Function Points. The next step is using some heuristic to peg a value next to it. This varies widely and is usually based on previous experiences. This method is not defendable since it is not based on any scientific principles or techniques. Schedule overruns could range from 50 – 75% of estimated time. This method is also by far the most used.

·         From the Function Point estimates

Capers Jones estimates that the number of test cases can be determined by the function point estimate for the corresponding effort. The formula is

Number of Test Cases = (Function Points)^1.2

The actual effort in person-hours is then calculated with a conversion factor obtained from previous project data. The disadvantage of using FP is that they require detailed requirements in advance. Another issue is that modern object-oriented systems are designed with Use Cases in mind and this technique is incompatible with them.

Request for Quality Center Material

Hi All,

If you need Quality Center material, kindly request here. And don't forget to mention your Email id.

Regards,

Pranjul

Request for VB Script Material

Hi All,


If you need VB Script material, kindly request here. And don't forget to mention your Email id.


Regards,
Pranjul

QTP - Keyword Driven Test Automation Framework

Keyword Driven Test Automation Framework for Web-based applications

In this approach, the endeavor is to build a lot of application independent reusable keyword components so that they can directly used for another web application without spending any extra effort. With this framework in place, whenever we need to automate a web based application, we would not need to start from scratch, but use the application independent keyword components to the extent possible and create application specific components for the specific needs.

Framework Structure

The framework consists of the following components.

• Function Library

• Object Repository

• Database

• Application Scenario Files

• Initialization VB Script                              

• Sequence File

• Driver Script

• Test Case List File

The directory structure in which these components are arranged is as shown below.

Keyword Driven Test Automation Framework

a. Function Library

In this approach, all the coding logic is in the form of user defined VB script functions. All of these functions are stored in function libraries (vbs file). There is absolutely no Scripting done outside of the function library except for the Driver Script. For each application, there are two function libraries, one which contains all the application independent functions (or common functions) and another that has application specific functions. While developing scripts for an application, the endeavor would be make use of the application independent functions as much as possible. In case, some functionalities require application specific functions, create them and put them in the application specific function library.

The common function library has a function (ExecuteScenarioFile) which reads the keywords, objects and other parameters from the Scenario File (described later in this document) and makes calls to appropriate functions in the function library. This is the only function which is called from outside of the function library (this function is called from the Driver Script).

Some of the common functions that can be created for web applications are as given below:

1. Close all browser windows and launch a new instance of browser.

2. Click on a Web Button with all error handling.

3. Enter data in a Web Edit object with all error handling.

4. Import data from MS Access to run time data table.

5. Verify text on a Web page with all error handling.

All the function library files (.vbs files) are kept in the Function Library folder in the directory structure.

b. Object Repository

Each application automated has a different object repository file and there is only one object repository for each application. All the object repository files (.tsr files) are kept in the Object Repository folder in the directory structure.

c. Database

All the test data is stored in MS Access database. The database structure is designed in such a way that there is more or less one table for each screen on the application. Almost every table has Test Case Id as one of the columns and is either the only primary key or one of the primary key columns. The Test Case Id represents a record or the data used for iteration. The database might have 100 sets of data, but the user might want to execute only 10 of them. The Test Case Id helps in this situation by providing the user with the option to select only certain sets of data.

The connection to this database is established from QTP by creating a System DSN for the database and using this DSN in the script. Ideally, we might want to have one database file created for each application. But, we can also have one database for multiple applications to save disk space.

All the database files (.mdb files) are kept in the Database folder in the directory structure.

d. Application Scenario Files

An application scenario file is a spreadsheet which contains keywords, objects and other parameters arranged in the desired order to form a test scenario. It is from this file that QTP reads information and performs actions on the application. This spreadsheet also serves as test scenario documentation, thanks to the easy to understand and English like keywords. Therefore, we do not need to have separate effort spent for test case documentation thereby saving time, effort and cost. It is this feature that makes the keyword driven framework so powerful.

The snapshot below shows how an application scenario file looks.

The application scenario file makes it very easy for the functional SME to create an automated test by selecting keywords from the dropdown without any programming knowledge.

The brains behind the keywords are the user defined functions which are called to make it work for the SME. Let us understand this with an example, the keyword “Enter data” is used to enter data into any field (WebEdit, WebList or WebCheckBox) on any web page by passing appropriate objects and parameters to the keyword. This is possible because of a function created to read the keyword, objects and parameters from the application scenario file and make calls to appropriate WebEdit, WebList and Web Check Box functions. So, we can make a keyword reusable by making its building blocks (user defined functions) reusable.

Therefore, the key to saving automation effort while following this approach is to create as many common web functions as possible, so that they can be reused to the maximum extent.

Each application has an application folder and all the application scenario files (.xls files) belonging to that application are kept in the corresponding application folder.

e. Sequence File

Sequence File is a like configuration file which contains information required to do the initialization settings to the Driver QTP Script for a particular application. The Sequence File is in the form of a spreadsheet which has an entry for each application and settings data such as Application Scenario file name, object repository name, function library name, test case list for execution, the data source, script development work area and script execution work area. Each application has a “Run” or “Ignore” flag against it to say which application scenario is to be executed. The Initialization VB Script (explained in the next section) uses this spreadsheet to decide the application & scenario to be executed, to get information about the Application Scenario file and do the initialization settings for an application.

The snapshot below shows how a sequence file looks.

The Sequence File (.xls file) is kept directly under the root directory.

f. Initialization VB Script

The Initialization VB Script is the starting point of script execution. It launches QTP, sets the work area as development or production based on the user input and does the following settings to the Driver Script.

• Set Work Area based on user input.

• Set the application scenario file for the current run.

• Set object repository.

• Set function libraries.

• Set data source.

• Set the test case list.

After doing the above settings, it opens the Driver Script in read only mode for the user to start execution. With this, the control is passed on to the Driver Script.

The Initialization VB Script (.vbs file) is kept directly under the root directory.

Note: The significance of the Initialization VB Script is that it allows the user to run the same script to do the initialization settings for different web based applications.

g. Driver Script

Driver script is a QTP test script which drives the script execution after taking control from the Initialization VB Script. Strictly speaking; this is the only script which is present as a QTP test script and not in the function library. As mentioned in section a, this test script calls the function “ExecuteScenarioFile” which reads the keywords, objects and other parameters from the Scenario File and makes calls to appropriate functions in the function library. The beauty of this framework is that all the script execution is covered by a single test and single QTP action.

The Driver Script is kept directly under the root directory.

h. Test Case List File

Test Case List File contains the list of Test Case Ids (explained in section c on Database) to be executed in the current run. As mentioned in section c, this provides the user with the option to select only a subset of the data in the database for execution of the current run.

The Test Case List File is kept directly under the root directory.

Tips on developing Strong & Robust Automation

·         Framework - The key to develop a strong & robust keyword driven automation framework is a challenge for any testing organization. To make this happen and realize the benefits of using it, the following guidelines are to be considered while developing the framework using the approach mentioned in this document.

·         Centralized Automation Team - One of the factors that stand out as a clear benefit in using this approach is the ability to reuse keyword components across applications thereby saving a lot of time, effort and cost. However, this calls for a lot of coordination between people doing automation in different projects. Therefore, it makes sense to have a centralized automation team working for different projects.

·         Coordination Between Function and Automation Teams – Though this approach provides the functional SMEs with more flexibility to design the business flow to create automated tests, the Automation Teams still need to work closely with the functional SMEs to make them understand what each keyword does, how the object names map with the logical names in the object repository and the database structure. This calls for good coordination between both the teams.

·         Creating right functions – The heart of the framework is the logic behind the functions in the function library. The way you design a function can make or break the whole framework. So, it is very important for the Automation Team to do proper analysis before creating functions. The endeavor should be to make the functions as generic as possible so that they can be reused across applications

·         Script Maintenance – Even though changes in the application can be taken care of by updating the application scenario spreadsheet, it would be a good practice for the automation Team to make sure that all of their functions are still good for use. Though this may not be a huge effort as in traditional automation frameworks, it might call for some work here and there.