Empty Bug(c)ket: June 2012

VB Basics

® The HTML <script> tag is used to insert a VBScript into an HTML page.

® VBScript code is written within paired SCRIPT tags.

® Beginning and ending SCRIPT tags surround the code. The LANGUAGE attribute indicates the scripting language. You must specify the language because browsers can use other scripting languages.

® You can use SCRIPT blocks anywhere in an HTML page. You can put them in both the BODY and HEAD sections. However, you will probably want to put all general-purpose scripting code in the HEAD section in order to keep all the code together. Keeping your code in the HEAD section ensures that all code is read and decoded before it is called from within the BODY section.

® One notable exception to this rule is that you may want to provide inline scripting code within forms to respond to the events of objects in your form.

A Sample VBScript :

<html>
<body>
<script type="text/vbscript">
document.write("Hello World!")
</script>
</body>
</html>

v VB Script features by category:

® Array handling

® Assignments

® Comments

® Constants/Literals

® Control flow

® Conversions

® Dates/Times

® Declarations

® Error Handling

® Expressions

® Formatting Strings

® Input/output

® Literals

® Math

® Miscellaneous

® Objects

® Operators

® Options

® Procedures

® Rounding

® Script Engine ID

® Strings

® Variants

Test Plan: Review and Approval

v Hold Review meetings with all the involved stake holders

v Invite all the stake holders who are impacted by the plan to the review meeting

v Before Review meets, send out the plans vide Email with ample time for the audience to go through the plan

v Try to limit the audience according to project depth

v Address the concerns raised in that forum and try resolving them on the spot

v Incorporate the changes which come out of the review meeting, version it and re-circulate it as the final version

v Lack of response could also mean no one has read the plan too

v Track till sign-off is received from the client side (or as appropriate – as defined in the roles and responsibilities)

Test Plan: Tips and Guidelines

v Lengthy plans which could tire the reader and the audience during a review meeting

v Multiple test plans for the subprojects in a project with data overlapping

v Usage of needless Jargons and irrelevant terms for the target audience

v Absence of references which may lead to lack of clarity of the document

v Missing out proper definition of roles and responsibilities

v Inadequate preparation which may leave a lot of sections to be under discussion

v Incomplete Documentation due to lack of information

v Use drafts to stimulate discussion

v Build the test plan with necessary information like Software being Tested, Test Objectives and risks

v Have a single master plan for the various Test activities involved in your project to avoid information redundancy

v Keep the Test Plan practical, focused and short

v The writing style matters, Avoid passive verbs. Don’t say that something is to be done, Instead mention exactly who is to do what and when

v As a rule of thumb, when using TBD, it is desirable to record who's responsible for resolution of the TBD and a target completion date

v Define the roles and responsibilities clearly

v Keep Jargon, buzz words and so forth limited to those appropriate for the audience

v Maintain a reference section to promote clarity

v Ensure that standards / templates followed for the sake of it does not lead to loss of focus, credibility and relevance

v Use the Test Plan as an opportunity to communicate with the test team, development colleagues and the management.

Master Test Plan

® Consolidated plan which has the entire details of all levels of testing; such as

® Mostly applicable in very large application

® A separate test plan will be drafted for each test phase

® Contains a high-level overview of the testing effort from Client’s perspective and processes

• Unit Test Plan

• Approach / Plan for testing each and every module / unit of application code

• Integration Test Plan

• Plan for testing if related programs / modules / Units of code are interfaced properly or not.

• Validates the system’s integrity according to the design specification

• System Testing

• Defines the organizations (overall and specific), activities, resources, and planning processes deemed to be necessary

• Has the approach for the entire system to be tested both functionally and non-functional testing such as Performance, Compatibility etc

• Acceptance Testing

• Has the plan of how the testing will be conducted at the customer end before the product is set to be go-live.

• Addresses the environment, responsibility for writing the test scripts, SLAs for acceptance, metrics etc

Test Plan

What is Planning?

® An act of formulating a program for a definite course of action

® The act or process of drawing up plans or layouts for some project or enterprise

® The process of thinking about what you will do to achieve some specific goal

What is a Test Plan?

® A test plan is a document detailing a systematic approach to testing a system such as a machine or software. The plan typically contains a detailed understanding of what the eventual workflow will be.

Why Plan?

® Helps reduce the necessary time and effort of achieving the goal

® A plan is like a map, you can always see how much you have progressed towards your project goal and how far you are from your destination.

® Helps management to clarify, focus, and research their project's development and prospects.

® Offers a benchmark against which actual performance can be measured and reviewed.

Best Example for Batch Testing

Payroll processing of company which involves sequential execution of the batch jobs

» This does not need any user inputs. The only input required is the month which can be predefined in an input file. Rest of the data such as the pay structure etc. is available in the database.

» The output of this process, namely the salary of employee, is not required real time. This process needs to be carried out only once a month during a specific day.

» This deals with high volume of salary transaction records of all the employees.

» The process is quite intensive and may interfere with the performance of other online applications deployed on the same server. So it is scheduled to be run at night.

Batch Testing

Business processes which require intervention from users in terms of input data, decisions etc. are developed as online applications for e.g., Login page – required user to enter ID and Password
Batches typically deal with large volume of data with many transactions in a predefined sequence due to the dependency on each other
They also require most of the system resources due to which they are typically scheduled to be executed during off business hours
There is no user interface unlike applications testing. The inputs are provided through defined files or configurations and output is verified in the database or output files
The test steps are minimal since there is no navigation across screens as in applications
The verifications points are many at the end of a single batch and requires validation across many different tables for verification of expected results
Dependency on the transactions needs to be taken into consideration while planning. Jobs need to be sequentially run to ensure each job receives the necessary input from the previous job appropriately
Appropriate error notifications and audit trails to be tested
Business processes which do not require any intervention from users and are not real time based on user demand are developed as batch applications. For e.g., payroll processing for employees in a company

Empty Bug(c)ket

Pages

Wednesday, June 27, 2012