TESTING Prof. Slivovsky TESTING PHILOSOPHY Robust Ability of a - - PDF document

testing
SMART_READER_LITE
LIVE PREVIEW

TESTING Prof. Slivovsky TESTING PHILOSOPHY Robust Ability of a - - PDF document

TESTING Prof. Slivovsky TESTING PHILOSOPHY Robust Ability of a system to handle unusual conditions that stress its design considerations 1 PARETO PRINCIPLE Effort Effect 20% 20% 80% 80% 20% of the input accounts for 80% of the output


slide-1
SLIDE 1

1

  • Prof. Slivovsky

TESTING

TESTING PHILOSOPHY

Robust Ability of a system to handle unusual conditions that stress its design considerations

slide-2
SLIDE 2

2

20% 80%

Effect

80% 20%

Effort PARETO PRINCIPLE 20% of the input accounts for 80% of the output COMPONENTS OF A TEST PLAN

¡ Strategies

§ A, I, S, T (analysis, inspection, similarity, test) § Unit, integration, function, system, acceptance § Regression

¡ Resources

§ Hardware, software, data, personnel, facilities

¡ Constraints, assumptions, risks ¡ Schedule, personnel, deliverables ¡ Project team responsibilities

[1, 2]

slide-3
SLIDE 3

3

TESTING FRAMEWORK

¡ Unit Testing

§ Validates each and every software subroutine, function, database, tables § Identifies logic/function errors early

¡ Integration Testing

§ Continually test as you integrate components and increase complexity § Validates interface compatibility § Approach with a mix of top-down and bottom-up testing [1, 2]

TESTING FRAMEWORK

¡ Acceptance Testing

§ Demonstrates the system's ability to meet specifications

¡ Regression Testing

§ Conducted upon implementation of any system/software changes and dependent on the scope and/or impact of the changes [1, 2]

slide-4
SLIDE 4

4

APP CRASH TESTING

¡ Normal conditions ¡ Long Run Time ¡ Random/Unexpected Input

[3]

MECHANICAL LIFE CYCLE TESTING

¡ Operational life expectancy requirement of 10 years ¡ Unfeasible to run a test for a decade ¡ Accelerate testing by increasing stress on system/component for shorter duration (e.g., cycles/sec, temperature, etc.)

slide-5
SLIDE 5

5

Test Case Name: Test_Name Requirement: requirement/user story/use case Component: object/function/procedure/component under test Setup: Safety: Procedure: steps to run test Pass Criteria: Expected Results: Observed Results: Status: pass, conditional pass, fail

TEST CASE SKELETON

¡ Test plan draft: DVP+R spreadsheet plus two detailed test cases ¡ Design Sprint #5: Complete Test Plan (DVP+R and detailed test cases) and testing results/analysis ¡ DVP+R skeleton, due dates/upload links on PolyLearn

ASSIGNMENTS

slide-6
SLIDE 6

6

RESOURCES

¡ “Some Resources for Learning how to Test Android Apps,” available at https://www.philosophicalhacker.com/post/some- resources-for-learning-how-to-test-android-apps/ ¡ ASME Standards & Certifications: Examples of Use of Codes and Standards for Students in Mechanical Engineering and Other Fields, (available at: go.asme.org/SCStudent)

REFERENCES

  • 1. ISO/IEC/IEEE 29119-2013 Software Testing
  • 2. IEEE SA 829-2008 IEEE Standard for Software and

System Test Documentation

  • 3. Brandon Landis, “The Ultimate Guide To Snapchat In

2016 – Strategy, Tutorials, Case Studies, And More”, (available at: https://responster.com/blog/snapchat-guide)