Practical Software Testing Part2 - WordPress.com · WRITING TESTS –EASY WAYS Application: Adder...

35
SOFTWARE TESTING PRACTICAL A WORKSHOP BY

Transcript of Practical Software Testing Part2 - WordPress.com · WRITING TESTS –EASY WAYS Application: Adder...

SOFTWARE TESTING

P R A C T I C A L

A W O R K S H O P B Y

{ }2 Unit

Test case design

A test case in software engineering is a set of conditions or variables under which a tester will determine whether an application or software system is working correctly or not.

http://en.wikipedia.org/wiki/Test_case

Test case does have a corresponding with Use case.

Normally a test case has:

–ID

–Description

–Input

–Expected output.

A Test case either ‘passes’ or ‘fails’.

A Feature Test Plan is usually a set of Test cases.

WHAT IS A TEST CASE?

{ }2 Exercise

Test design (group)

WRITING TESTS – EASY WAYS

Application: Adder application which takes two 2-digit no.s and

displays the sum.

Reference: 'Testing Computer Software' book by Cem Kaner, Jack

Falk and Hung Q. Nguyen.

? 2

? 3

5

? _

EQUIVALENCE CLASS PARTITION

The concept comes from

Mathematics where we

break Set into sub-sets

based upon some criteria.

Now assuming that one

element from subset of a

Set is equivalent to other

member of same subset,

we have one Test case

represent one subset.

• CRUD (Create, Read, Update, Delete)

• SFDiPOT (Structure, Function, Data,

Interfaces, Platform, Operation, Time)

• HICCUPPS (History, Image,

Comparable Products, Claims, User

needs, Product, Purpose, Statutes)

• “You are here”

WRITING TESTS EVEN EASIER - HEURISTICS

END OF UNIT 2

SOFTWARE TESTING

P R A C T I C A L

A W O R K S H O P B Y

{ }3 Automated Testing

BREAKING THE MISSION

1 Software Test Automation

2 How to Automate?

3 Hands-on maneuvering of x-unit tools

4 Implications of Automation

Test Automation

• Software Test Automation

• Controls test execution comparing actual and expected

outcomes

• Software Tester

• writes test scripts and executes with another

software to test the software

• Automated tests once developed, can be run repeatedly

http://www.tutorialspoint.com/software_testing/

Rationale for Test Automation • Manual execution of test plans for regression testing is laborious and time

consuming.

• Test automation is handy for products with long maintenance life

• It can test the application from performance, load and stress point of view.

• Saves time and money compared to error-prone manual testing.

• Improvises test accuracy, coverage and productivity.

• Continuous Integration Testing

What to Automate???

Choosing an automation tool

Creating a testing infrastructure for automation

Designing of test cases

Development of scripts

Execution of Scripts

Analysis of Results

Sharing the results with team Maintenance of Scripts

Automation Tools• Different tools with respective features are there:

• API Testing

• Junit , Nunit

• GoogleTest

• Visual Studio Test Suite

• GUI Testing

• SilkTest

• TestComplete

• Performance Testing

• LoadRunner

• WebLoad

NUnit

• NUnit is a unit testing framework for the .NET Language

• NUnit promotes the idea of "first testing then coding“

• NUnit is an open source framework which is used for

writing & running tests

• Provides annotations, assertions and test runners

Environment for NUnit• Microsoft Visual Studio 2010

• .NET 4.0

• NUnit 2.6.0

xUnit Design

Code to Test

Test Code

Test Runner

Unit Tests in NUnit

• Unit Test is code that ensures another part of code (method) works as

expected.

• Unit tests can be written using a test framework such as Nunit.

• Unit test can be characterized with a known input and an expected output.

• Input corresponds to pre-condition and expected output corresponds to post-

condition.

• Each requirement may have two test cases: positive and negative ones.

Writing Tests using NUnit

• Let’s write our first test……..

Automating Adder Application

• Application: Adder application which takes

two 2-digit no.s and displays the sum.

? 2

? 3

5

Adder Application Test Scenarios -I

Adder Application Test Scenarios -II

NUnit Features• Assertions

• Equal, Null, True [with respective vice versa]

• Annotations of Nunit• [Test]

• [Test Fixture]

• [SetUp] - before each test method is called

• [Teardown] - after each test method is run

• [TestFixtureSetUp] - performed once prior to executing all tests in fixture

• [TestFixtureTearDown] - performed once after all tests are completed

• [ExpectedException]

• [Ignore()]

Parameterized Tests

• Help in running the same tests over and over again

using different values

• Nunit offers the same feature via[TestCase(12,3,4)]

[TestCase(12,2,6)]

[TestCase(12,4,3)]

public void DivideTest(int n, int d, int q)

{

Assert.AreEqual( q, n / d );

}

Generating Test Documentation[TestFixture, Description("Fixture description")]

public class SomeTests

{

[Test, Description("Test description here")]

public void DocTest()

{

/* ... */

}

}

Do and Don’t of Test Automation• Smoke Testing

• Run with every build to make go/no-go decision on deeper testing.

• Regression Testing • Assures that a change, bug fixes or new functionality , did not introduce new bugs

• Data Driven Testing • Testing the operations with their related data sets in a framework

• Exception or Negative Testing • Forcing error conditions in the system.

• Functional Testing • Testing that operations perform as expected for relatively stable application

• Testing on different Operating Systems/Environments

• Repetitive tasks

Do and Don’t of Test Automation

• Exploratory testing

• Usability testing

• Documentation Testing

• Graphics Testing

• For Features which are under changes/unstable

Software Testing, A research Perspective

• Automated Tools for Reliability calculation of Critical system

• Test Case Generation for Regression testing

• Test Case prioritization technique

• Software testing in offshore culture with agile models

• Testing of e-Governance applications.

END OF UNIT 3

{ }4 Unit

Wrap Up

1. “Quality is value to some person (who matters)” (Gerald M.

Weinberg)

2. Software is imaginary and you only see it when it is built.

3. Finding test cases and documenting them are separate processes.

4. Use heuristics to design test cases.

5. It is never possible to 100% automate tests.

6. Technology facing tests are best suited for automation.

7. Regression testing cannot find new bugs and can only check that

things are working as before.

8. Exploring new areas guarantee more bugs and mitigating risks.

9. Testing is a role.

10. Business people, Programmers and Testers all test. Testers test

more.