Book Image

Learning Software Testing with Test Studio

By : Rawane Madi
Book Image

Learning Software Testing with Test Studio

By: Rawane Madi

Overview of this book

Test Studio is Telerik's QA solution for automating your manual testing. With Test Studio's standalone edition or Visual Studio plugin, you can rule out the possibility of unreliable test execution and UI recognition, non indicative test results and reports, dispersed test repository, low code coverage, and unaffordable learning curves. With no code, this tool provides an intuitive IDE to effortlessly create maintainable tests. If you are looking for a solution to automate testing for your web, desktop, or mobile application, you can now benefit from Test Studio's rich automation features. "Learning Software Testing with Test Studio" will illustrate how to reliably automate test cases when it is time to relinquish manual testing habits. This book is all about less theory and more hands-on examples to present a complete manual and automated solution for your ASP .NET, WPF, Silverlight or iOS apps. This book gets you started directly with automation in Test Studio by exploiting its recording powers through series of concrete test cases built around the equipped applications. Each chapter starts with a typical automation problem which is then approached using Test Studio specialized automation features. You will learn how to create record and playback functional, performance, and load tests. Furthermore, we will see how to insert verification steps, logical constructs, convenient logging operations, and how to convert test scripts in order to implement keyword and data-driven architectures. To endow your tests with additional flexibility, each recorded automation feature will be approached from its coded perspective through the usage of the underlying ArtOfTest Test Studio automation library. This book also illustrates how Test Studio can automate pre-conditions, test result inputting, and the capturing of system states during manual test case execution in order to keep the tester's attention focused on the important details.
Table of Contents (18 chapters)
Learning Software Testing with Test Studio
About the Author
About the Reviewers

Testing concepts

The following is a conceptual overview of some fundamental testing terminologies and principles. These are used in day-to-day testing activities and will be directly referred to in the chapters when explaining the business case for our examples.

Test case

A test case is a scenario that will be executed by the tester or by an automation tool, such as the Test Studio for any of the software testing purposes, such as uncovering potential errors in the system. It contains:

  • Test case identifier: This identifier uniquely distinguishes a test case.

  • Priority: The priority holds a value to indicate the importance of a test case so that the most important ones are executed first and so on.

  • Preconditions: The preconditions describe the initial application state in which the test case is to be executed. It includes actions that need to be completed before starting the execution of the test case, such as performing certain configurations on the application, or other details about the application's state that are found relevant.

  • Procedure: The procedure of a test case is the set of steps that the tester or automated testing tool needs to follow.

  • Expected behavior: It is important to set an expected behavior resulting from the procedure. How else would you verify the functionality you are testing? The expected behavior of a test case is specified before running a test, and it describes a logical and friendly response to your input from the system. When you compare the actual response of the system to the preset expected behavior, you determine whether the test case was a success or a failure.

Executing a test case

When executing a test case, you would add at least one field to your test case description. It is called the actual behavior and it logs the response of the system to the procedure. If the actual behavior deviates from the expected behavior, an incident report is created. This incident report is further analyzed and in case a flaw is identified in the system, a fix is provided to solve the issue. The information that an incident report would include are the details of the test case in addition to the actual behavior that describes the anomalous events. The following example demonstrates the basic fields found in a sample incident report. It describes a transaction carried out at a bank's ATM:

  • Incident report identifier: ATM-398

  • Preconditions: User account balance is $1000

  • Procedure: It includes the following steps:

    1. User inserts a card.

    2. User enters the pin.

    3. Attempts to withdraw a sum of $500.

  • Expected behavior: Operation is allowed

  • Actual behavior: Operation is rejected, insufficient funds in account!

  • Procedure results: Fail

The exit criteria

The following definition appears in the ISTQB (International Software Testing Qualification Board) glossary:

"The set of generic and specific conditions, agreed upon with the stakeholders, for permitting a process to be officially completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding parts of the task, which have not been finished. Exit criteria are used to report against and to plan when to stop testing. [After Gilb and Graham]"

The pesticide paradox

Software testing is governed by a set of principles out of which we list the pesticide paradox. The following definition appears in the ISTQB glossary:

If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new defects. To overcome this, "pesticide paradox", the test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects.

Element recognition

Element recognition is a pillar of automated test execution as the tool used can't perform an action on an object unless it recognizes it and knows how to find it. Element identification is important in making the automated scripts less fragile during execution. This topic will be reflected in this book.