A brief overview of Testing

Why do we need to test anyway?

• Living documentation of the expected behavior of the system
• To build confidence that software works and still works after making a change
• Reduce cost by finding bugs early
• A method to document requirements and verify solution meets the requirements
• Quality assurance including behavior, performance, etc

Questions to think about?

• When you make a change, how do you currently determine if the change does what it is supposed to?
• ... that it didn't break something else?
• ... where do you document that this is a new requirement?
• ... how much time will the next programmer have to spend to be able to verify that your requirement still works after his or her new change?

Types of Functional Testing

• Unit Testing - tests of methods or classes, but not across them.
• Regression Testing - typically uses unit tests to verify functionality still works as expected
• System Testing - testing across classes and methods. This is general higher level and tests more of how the system behaves vs the requrements rather than implementation.
• Integration Testing - tests across classes and methods; it stri
• Acceptance Testing - done by the end user to give their stamp of approval

Types of Non-Functional Testing

• Performance Testing - load testing essentially
• Usability Testing - is the user interface easy to use and understand
• Security Testing -can it be hacked, is confidential data encrypted, etc

Black Box Testing Testing that assumes you don't know the implementation of what is in the box. In this type of testing you have inputs and outputs, but you don't know how inputs are mapped to outputs. In this scenario you think of the box as something you bought or got from someone else, and don't really know how it works, just what it is supposed to do. Examples are: Use case testing, White Box Testing Testing that assumes you DO know the implementation of what is in the box. In fact, the purpose of the test is to make sure that all paths of execution in the box are tested (or at least the ones that can break if you subscribe to Extreme Programming techniques). Typically boundaries, ranges of values, control flow, data flow, and other code execution testing is the focus. Examples are: Unit Testing Test Driven Development Is an approach to design better software. Test Driven Development (TDD) starts the development cycle with gathering requirements, but then quickly moving to writing test cases that document the requirement and force the designer to think about exactly what the system is supposed to do. It takes automated unit testing and regression testing and makes them a basis for all development activities. This means that when adding new functionality a test is written first, it will fail this test at first, then as it is implemented it will eventually pass the test. The best part is now refactoring can take place because we have regression testing already in place to verify by refactoring that we did not break anything. This promotes clean, clear, modularized code because if you can test the code it is likely that it is modular and easier to maintain.