acceptance testing seng 301

Size: px

Start display at page:

Download "acceptance testing seng 301"

Mavis Lucas
8 years ago
Views:

1 acceptance testing seng 301

2 Warning Your project mark will depend heavily on your automated acceptance tests.

3 Types of testing acceptance testing functional testing integration testing load testing performance testing regression testing scalability testing security testing unit testing usability testing...

4 Types of testing acceptance testing functional testing integration testing load testing performance testing regression testing scalability testing security testing unit testing usability testing...

5 Unit testing Testing of individual software components. Where components can refer to modules, classes, methods, procedures, etc. The idea is to ensure that the pieces are individually working as they are intended to work. Tip: the goal of testing is to discover bugs, so your strategy in writing unit tests should be to break the code you are writing tests for. You should consider the edge cases, boundary conditions, etc...

The idea is to ensure that the pieces are individually working as they are intended to work.

6 Acceptance testing Testing to allow the customer to determine whether or not to accept the software product. Each automated acceptance test (as you are expected to create for the course project) checks that the software meets some aspect of a particular user requirement.

Each automated acceptance test (as you are expected to create for

7 Acceptance testing: Scenarios A postulated sequence of events. Each requirement will embody a number of scenarios. Some scenarios may be successful others may be failures. Tip: plan your acceptance testing strategy by considering all relevant scenarios for each requirement.

Some scenarios may be successful others may be failures.

8 Acceptance testing: Scenarios A postulated sequence of events. Each requirement will embody a number of scenarios. Some scenarios may be successful others may be failures. Tip: plan your acceptance testing strategy by considering all relevant scenarios for each requirement.

9 Documenting your tests for the course project Each test should be accompanied by source code comments such as: // This test all scenarios implied by requirement N1 class TestRequirement1 extends TestCase { // scenario 1: <describe scenario here> void testscenario1() {... } // scenario 2: <describe scenario here> void testscenario2() {... } // etc

class TestRequirement1 extends TestCase { // scenario 1: <describe scenario here> void

10 Exercise: What scenarios need to be considered when writing acceptance tests for this requirement? What is the intended outcome for each of those scenarios? S1 By comment search [A] When the search term is of the form comment:<term>, SvnExplore outputs all commits that have the specified term in its commit message. Term matching is done in a case insensitive manner. A supplied search term does not have to match a complete word. For example, the term fix would match the word fixed in the commit message.

S1 By comment search [A] When the search term is of the form comment:<term>, SvnExplore outputs all commits that have the

11 Unit tests vs. Acceptance Tests

12 Unit Organized around the code (classes and methods) Acceptance Organized around the requirements and scenarios

13 Unit tests are organized around classes and methods // unit tests for the Parser class class TestParser extends TestCase { // test the paresepath method void testparsepath() {... } // test the pareselogentry method void testparselogentry() {... } } // etc

// test the paresepath method void testparsepath() {.

14 Acceptance tests are organized around requirements and scenarios // This test all scenarios implied by requirement N1 class TestRequirementN1 extends TestCase { // scenario 1: the supplied xml file has no real entries void testwithinitialxmlfile() {... } // scenario 2:... void test...() {... }

extends TestCase { // scenario 1: the supplied xml file has no real

15 Unit Organized around the code (classes and methods) Acceptance Organized around the requirements and scenarios Test as specific a code unit as possible (e.g., a method) and as isolated as possible Test a complete scenario (generally exercising much more of the code)

16 Unit Organized around the code (classes and methods) Acceptance Organized around the requirements and scenarios Test as specific a code unit as possible (e.g., a method) and as isolated as possible Test a complete scenario (generally exercising much more of the code) Written for developers Written from the end user perspective

, a method) and as isolated as possible Test a complete scenario (generally

17 Regression testing Tests to make sure that your code does not regress. Regress (verb): return to a previous, less developed state. All of the tests you write (unit, acceptance,...) can be considered part of the your regression test suite. These can be run to help ensure that, after a change is made, the code still works correctly. Note that for some projects running all of the tests may take many hours.

All of the tests you write (unit, acceptance,.

18 Regression testing Tests to make sure that your code does not regress. Regress (verb): return to a previous, less developed state. All of the tests you write (unit, acceptance,...) can be considered part of the your regression test suite. These can be run to help ensure that, after a change is made, the code still works correctly. Note that for some projects running all of the tests may take many hours.

Quality Assurance Training Program

Quality Assurance Training Program Introduction/Summary: This 5-day course focuses on understanding and developing various skills required by QA Developer, preparing to use various tools and techniques