DISCUSSION

219343: Software Testing

   

The BIG picture

● Process– Design test cases

– Review with PM and developers

– When the product is ready, perform the testing

– Test progress report

– Defect management

TEST PREPARATION

TEST EXECUTION

   

Smoke test

● Test for very basic functionality.– Can it run?

– Can user (fill in your own)?● For library: “perform check out and return”● For calendar: “make an appointment”● For restaurant: “book a table”● For media sharing: “post a content”

   

Failing the smoke test

● If the system fails the smoke test, there is little point in performing other tests.

   

Test early, test often

● Daily builds, daily smoke test.

● Better: can you run smoke test every time someone commits to the code base?– Continuous Integration

   

Other tests?

● Yes.

● When do test design, think about this?– “If the software passes all these tests, is it ready for the 

user?”

   

Key points: completeness

● No, we don't want to completely test the software.

● But test cases should cover most of the blind spots.– (Again depending on the priorities of the use cases)

   

Test cases alone are not enough

● Also, test cases only focus on one specific use case.

● Very often, bugs appear when many operations come together.– Load the doc, print it, works

– Load the doc, edit it, print it, FAILED!

   

Test scenarios

● A test scenario focuses more on “business use case” (series of related use cases).

● Consists of many test cases.

   

Non­functional requirements

● Also needs testing 

● (we'll learn how to do load/performance test today)

   

Key points: verification

   

Observation:test coverage

● More important features should be tested extensively.– Don't spend too much time testing registration but not 

enough time for (fill in your own important feature).

   

Observation: precondition

   

Observation:test database