A Test Script is a set of instructions (written using a scripting/programming language) that is performed on a system under test to verify that the system performs as expected. Test scripts are used in automated testing.

Sometimes, a set of instructions (written in a human language), used in manual testing, [...]]]> Test Script Definition, Explanation, Example:

A Test Script is a set of instructions (written using a scripting/programming language) that is performed on a system under test to verify that the system performs as expected. Test scripts are used in automated testing.

Sometimes, a set of instructions (written in a human language), used in manual testing,  is also called a Test Script but a better term for that would be a Test Case.

Some scripting languages used in automated testing are:

• JavaScript
• Perl
• Python
• Ruby
• Tcl
• Unix Shell Script
• VBScript

There are also many Test Automation Tools/Frameworks that generate the test scripts for you; without the need for actual coding. Many of these tools have their own scripting languages (some of them based on a core scripting languages). For example, Sikuli, a GUI automation tool, uses Sikuli Script which is based on Python. A test script can be as simple as the one below:

def sample_test_script (self):

type ("TextA")

click (ImageButtonA)

assertExist (ImageResultA)

A test execution engine and a repository of test scripts (along with test data) are collectively known as a Test Harness.

NOTES:

VERY SHORT DEFINITION

Agile testing is a method of software testing that follows the principles of agile [...]]]> This article on Agile Testing assumes that you already understand Agile software development methodology (Scrum, Extreme Programming, or other flavors of Agile). Also, it discusses the idea at a high level and does not give you the specifics.

VERY SHORT DEFINITION

Agile testing is a method of software testing that follows the principles of agile software development.

MANIFESTO FOR AGILE SOFTWARE TESTING

This is adapted from agilemanifesto.org and it might look a little silly to copy everything from there and just replace the term  development with testing but here it is for your refreshment. You need to however realize that the term development means coding, testing and all other activities that are necessary in building a valuable software.

We are uncovering better ways of testing
 software by doing it and helping others do it.
 Through this work we have come to value:

Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

That is, while there is value in the items on
 the right, we value the items on the left more.

AGILE TESTING VALUES EXPLAINED

• Individuals and interactions over processes and tools: This means that flexible people and communication are valued over rigid processes and tools. However, this does not mean that agile testing ignores processes and tools. In fact, agile testing is built upon very simple, strong and reasonable processes like the process of conducting the daily meeting or preparing the daily build. Similarly, agile testing attempts to leverage tools, especially for test automation, as much as possible. Nevertheless, it needs to be clearly understood that it is the testers who drive those tools and the output of the tools depend on the testers (not the other way round).
• Working software over comprehensive documentation: This means that functional and usable software is valued over comprehensive but unusable documentation. Though this is more directed to upfront requirement specifications and design specifications, this can be true for test plans and test cases as well. Our primary goal is the act of testing itself and not any elaborate documentation merely pointing toward that goal. However, it is always best to have necessary documentation in place so that the ‘picture’ is clear and the ‘picture’ remains with the team if/when a member leaves.
• Customer collaboration over contract negotiation: This means that the client is engaged frequently and closely in touch with the progress of the project (not through complicated progress reports but through working pieces of software). This does put some extra burden on the customer who has to collaborate with the team at regular intervals (instead of just waiting till the end of the contract, hoping that deliveries will be made as promised). But this frequent engagement ensures that the project is heading toward the right direction and not toward the building of a frog when a fish is expected.
• Responding to change over following a plan: This means accepting changes as being natural and responding to them without being afraid of them. It is always nice to have a plan beforehand but it is not very nice to stick to a plan, at whatever the cost, even when situations have changed. Lets say you write a test case, which is your plan, assuming a certain requirement. Now, if the requirement changes, you do not lament over the wastage of your time and effort. Instead, you promptly adjust your test case to validate the changed requirement. And, of course, only a FOOL would try to run the same old test case on the new software and mark the test as FAIL.

PRINCIPLES BEHIND AGILE MANIFESTO

Behind the Agile Manifesto are the following principles which some agile practitioners unfortunately fail to understand or implement. We urge you to go through each principle and digest them thoroughly if you intend to embrace Agile Testing. On the right column, the original principles have been re-written specifically for software testers.

THE RECURRING QUESTION

So what happens to all the traditional software testing methods and artifacts? Do we throw them away?

THE ANSWER

Naaah! You will still need all those software testing methods and artifacts (but at varying scales of priority and necessity). You will, however, need to completely throw away that traditional attitude and embrace the agile attitude.

As of end of 2011 Q3, our site has active email subscriptions from the following domains (listed alphabetically):

This data is from Google FeedBurner.

We do NOT publicize or sell personal email addresses of our subscribers.