Written by Sanjay Kumar

1
Extreme Programming Software Development

• Written by Sanjay Kumar

2
Extreme Programming Model

• Extreme Programming evolved from Spiral Model.
• Extreme Programming improves a software project
  in five essential ways like communication,
  simplicity, feedback, respect, and courage.
• Instead of moving down in a linear way
  communication, simplicity, feedback, respect, and
  courage.
• They keep their design simple and clean. They
  get feedback by testing their software starting
  on day one.
• It is a not a structured approach to testing.
  Every small success deepens their respect for the
  unique contributions of each and every team
  member
• Brings high quality into the development of our
  products.

3
Steps in the Extreme Programming
Quality is guaranteed at each project steps.
4
Stage Containment

• This term is used to identify problems existing
  in the product being developed before proceeding
  to the following stage.
• More errors than defects.
• Cost and effort for fixing problems is minimized.

Detailed Design
Component Test
Assembly Test
Defect Origin
Analyze
Design
Prod Test
Deploy
Defect Discovered
Detailed Design
Component Test
Assembly Test
Analyze
Design
Prod Test
Deploy
With Stage Containment
5
Without Stage Containment

• More defects than errors.
• Fixes become more expensive and difficult.

Detailed Design
Component Test
Assembly Test
Defect Origin
Analyze
Design
Prod Test
Deploy
Defect Discovered
Detailed Design
Component Test
Assembly Test
Analyze
Design
Prod Test
Deploy
6
Without Stage Containment
Detailed Design
Component Test
Assembly Test
Defect Origin
Analyze
Design
Prod Test
Deploy
Defect Discovered
Detailed Design
Component Test
Assembly Test
Analyze
Design
Prod Test
Deploy
Worst Case!
7
Entry and Exit Criteria

• Entry Criteria
• The Term Entry Criteria refers to the input
  conditions required from the previous processes
  to support a specific stage.
• Exit Criteria
• The term Exit Criteria refers to the output
  conditions required by a specific process to
  determine its thoroughness and correct
  completion.
• The Exit Criteria for one stage can constitute
  part of the Entry Criteria for the following
  stage.

8
The Five Key Deliverables of Test Planning
Deliverable Description
Test Approach Explains the objectives and scope of the test Documents entry/exit criteria and key dates
Test Scenarios Provides high-level descriptions of functionality to be tested
Test Conditions and Expected Results Describes all items and results that must be covered to fulfill each Test Scenarios
Test Cycle Control Sheet Groups test scripts into logical categories (or cycles) documents when and by whom each cycle will be executed.
Test Scripts Provides step-bystep instructions and detailed results for a test executor to follow during test execution
9

• Unit testing
• The most micro scale of Testing
• A unit smallest testable software component
• Objects and methods
• Procedures / functions
• Performed by Programmer
• A tester can help.
• Requires detailed knowledge of the internal
  program design and code.
• The units are tested in isolation.
• Ensures the component is working according to
  the detailed design/build specifications of the
  module.
• Not to be confused with debugging.
• Also known as component, module, or program
  testing.

10

• Integration Testing
• Testing of more than one (tested) unit together
  to determine if they function correctly.
• Focus on interfaces
• Communication between units
• It is done using the integration test design
  prepared during the architecture design phase.
• Helps assembling incrementally a whole system,
  ensuring the correct flow of data from the
  first through the final component.
• Done by developers/designers and testers in
  collaboration
• Also called Interface Testing or Assembly
  Testing.

11

• System testing
• Testing the system as a whole - Black-box type
  testing that is based on overall requirements
  specifications covers all combined parts of a
  system.
• Ensures that system meets all functional and
  business requirements.
• Focus
• Verifying that specifications are met
• Validating that the system can be used for the
  intended purpose
• The system test design is derived from the
  system design documents and is used in this
  phase.
• It can involve a number of specialized types of
  tests to check performance, stress, documentation
  etc. Sometimes testing is automated using testing
  tools.
• Done by Independent testing group

12

• Acceptance testing
• To determine whether a system satisfies its
  acceptance criteria and business requirements or
  not.
• Similar to System testing in that the whole
  system is checked, but the important difference
  is the change in focus.
• Done by real business users.
• It enables the customer to determine whether to
  accept the system or not.
• Also called as Beta Testing, Application Testing
  or End User Testing.
• Approach
• Should be performed in real operating
  environment .
• Customer should be able to perform any test
  based on their business processes.
• Final Customer sign-off.

13
Benefits of Extreme Programming

• Faults are prevented and it stops fault
  multiplication.
• Avoids the downward flow of defect.
• Lower defect Resolution cost due to earlier
  detection.
• Improved quality and reliability.
• Reduction in the amount of Re-work.
• Improved Risk Management
• Validation and Verification at each level of
  stage containment
• Allows testers to be active in the project early
  in the projects lifecycle. They develop critical
  knowledge about the system.

14
Introduction of Exploratory testing

• While the software is being tested, the
  tester learns things that together with
  experience and creativity generate new good tests
  to run. His comes under black box testing
  technique. Exploratory testing is particularly
  suitable if requirements and specifications are
  incomplete or tailored the process, or if there
  is lack of time. And experienced tester easily
  gets the defects. Find holes in requirements
  exploratory tester usually report many errors
  caused by wrong requirements or documentation.

15
Advantages and Disadvantages of Exploratory
testing

• Advantage of Exploratory testing
• 1. Checks application usability with the
  help of exploratory testing.2. Find holes in
  requirements.3. Helpful with a lack of
  documentation, requirements, test cases, etc
• Disadvantage of exploratory testing1. We
  do not need test scenarios, unit tests, test
  automation, etc. We have skilled testers.2. Poor
  detection of minor issues.3. Exploratory testers
  can get into a routine.

16
Final Checklist

• 1 Create System and Acceptance Tests 2
  Start Acceptance test Creation 3 Identify
  test team 4 Create Workplan 5 Create test
  Approach 6 Link Acceptance Criteria and
  Requirements to form the basis ofacceptance test
  7 Use subset of system test cases to form
  requirements portion ofacceptance test 8
  Create scripts for use by the customer to
  demonstrate that the system meets requirements
  9 Create test schedule. Include people and all
  other resources. 10 Conduct Acceptance Test
  

17
11 Create Workplan 14 Determine resource
requirements 15 Identify productivity tools
for testing 16 Determine data requirements
17 Create test Approach 19 Identify any
facilities that are needed 20 Obtain and
review existing test material 21 Create
inventory of test items 22 Identify Design
states, conditions, processes, and procedures
23 Identify all functional requirements 25
Start test case creation 27 Identify logical
groups of business function for new sysyem
18
34 Begin test Preparation 36 Obtain test
support resources 37 Outline expected results
for each test case 38 Obtain test data.
Validate and trace to test cases 39 Prepare
document environmental set up procedures. Include
back up and recovery plans 41 End Test
Preparation phase 42 Conduct System Test
43 Execute test scripts 44 Compare actual
result to expected 45 Prepare maintenance
phase input 47 Re-execute test group after
problem repairs 48 Create final test report,
include known bugs list 49 Obtain formal
signoff
19
Exit Criteria for testing
1. When all the test cases are executed2. When
User acceptance testing is complete3. Hardware
and software are not available at the
timeindicated in the test schedule or project
schedule4. When Source code contain one or more
critical defect thatlimits the testing
process.5. When testing budget is complete6.
According to the test schedule7 When release
factor is near or when deadline is reached8.When
all major Bugs are resolved.
20
Thank You!