Classic mistakes 1 research oriented development 2

Info icon This preview shows pages 62–76. Sign up to view the full content.

View Full Document Right Arrow Icon
Classic Mistakes 1. Research-oriented development 2. Using “low-cost” personnel 3. Lack of code control 4. Inadequate testing
Image of page 62

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Partitioning Programming Group like modules together based on system functionality Match skills to tasks at hand Plan thoughtful teams and review practices Metrics for assessing progress Separate out Development Testing Production
Image of page 63
Programmer Paradox More is not always better! After the “right” number of people are assigned to a programming task, adding more people slows down rather than speeds up completion of the project. Projects requiring a large team should be broken into a series of independent, smaller parts. Purpose of structure charts and program design
Image of page 64

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Testing Coverage Ideally, testing will exercise the system in all possible ways under all conceivable conditions Not possible, so use different criteria to judge how well our testing strategy “covers” the system Test plan Document describing the testing process Formalizes metrics, techniques and procedures Meets requirements (at all levels) Often contractual obligation
Image of page 65
Test Plan Test objectives Schedule and logistics Test strategies Test cases Procedure Data Expected result Procedures for handling problems Evaluation criteria Reporting methods
Image of page 66

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Image of page 67
Test Case Test case (part of test plan) Consists of data, procedure, and expected result Represents just one situation under which the system (or some part of it) might run Rigorous and methodical Early iterative development, then consistent application Example: Working with data entry for dates (MM/DD/YY)
Image of page 68

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Testing Functional testing techniques Tests the behavior of a system or program “Black box” testing Based on input and output ONLY Coverage criteria based on behavioral aspects
Image of page 69
Testing Structural testing techniques Tests how a program/system does something “White box” testing Based on statements embedded in the code Coverage criteria related to physical parts of the system
Image of page 70

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Testing Phases Unit testing: Does this piece work by itself? Integration testing: Do these two pieces work together? System testing: Do all the pieces work together? Alpha acceptance testing: Try it out with in- house “users” (simulated data) Installation testing: Can users install it and does it work in their environment? Beta acceptance testing: Try it out with real users, real data and real environments In development organization In user organization
Image of page 71
Image of page 72

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Anticipated Discovery Curve
Image of page 73
Unit Testing Focus on one unit – a program or a program module that performs a specific function that can be tested Black-box testing The test plan is developed directly from the program specification, program is opaque White-box testing The tester reviews the actual program code
Image of page 74

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Unit Testing Input domain testing: Pick test cases representative of the range of allowable input, including high, low, and average values Equivalence partitioning: Partition the range of allowable input so that the program is expected to
Image of page 75
Image of page 76
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}

What students are saying

  • Left Quote Icon

    As a current student on this bumpy collegiate pathway, I stumbled upon Course Hero, where I can find study resources for nearly all my courses, get online help from tutors 24/7, and even share my old projects, papers, and lecture notes with other students.

    Student Picture

    Kiran Temple University Fox School of Business ‘17, Course Hero Intern

  • Left Quote Icon

    I cannot even describe how much Course Hero helped me this summer. It’s truly become something I can always rely on and help me. In the end, I was not only able to survive summer classes, but I was able to thrive thanks to Course Hero.

    Student Picture

    Dana University of Pennsylvania ‘17, Course Hero Intern

  • Left Quote Icon

    The ability to access any university’s resources through Course Hero proved invaluable in my case. I was behind on Tulane coursework and actually used UCLA’s materials to help me move forward and get everything together on time.

    Student Picture

    Jill Tulane University ‘16, Course Hero Intern