How testing is directly affected by the SDLC choice:

·       Documentation availability to test against

·       Time to test

·       Time to automate ore produce effective automation

·       Knowledge and understanding of the application as we plan our tests

·       Amount of regression testing

Waterfall Model

·       The waterfall model is a sequential softwore development model

·       Transition beween phases is done by a formal review

·       The review is a checkpoint to see that you are on the right track

·       Testing is not inherent to every phase of the Waterfall model

·       Constant testing from the design, implementation and verification phases is required to validate the phases preceding them

·       Testing phase: Only after coding phase, software testing begins. Different testing methods are available to detect the bugs that were committed during the previous phases. A number of testing tools and methods are already available for testing purposes

Spiral Model

·       Planned and structured releases

·       Ususlly has documentation to test against

·       Each spiral iteration can be thought of as a “mini-waterfall”; there are defined testing phases

·       Previous releases must be regression tested

V-model

·       Verification: Checks that a deliverable is complete (Contains all requires information, follows standards; verify a procedure)

·       Validation: Checks that the deliverables satisfy requirement specified in the previous stage or an earlir stage, and that the business case is met (Validate a function or requirement)

·       Testing: Ensures that the specification is properly assembled and implemented (Test to see if it works)

·       In testing, these are important changes in software development from the V-model:

o   Write the test cases at requirements review

o   Unit testing

Concurrent Model

·       Planning is concurrent to design; design is concurrent to development – everything is happening at the same time

·       The whole project is not well planned or well stuctured

·       Planning, design and development are most dynamic. Product is in constant change. Very difficult to test; impossible to effectively plan testing project

·       Often no documentation to test against

·       Testing is ad hoc

·       Coverage usually cannot be measured. Structured regression testing is impossible

·       Bugs  will be missed because of so much change and so little planning

·       Risk analysis and reporting is crucial

Agile Model

·       Delivery cycles are short. Development is very focused. Diagrams, use case, user stories, index cards, or discussions of functionality serve as “documentation” to test against

·       Agile projects usually have more unit testing by developers

·       Dynamic nature of development needs structured regression testing

·       Testing is often ad hoc, but focused

·       Dynamic style or projects include much change but the change is discussed and side-effects noted

Development Phase: A time block within SDLC. There are a number of activities that have to be done in this time block

Examples of some Test Phases:Unit Test, Integration Test, System Test, User Acceptance Test, Release Test and Maintenance Test

Development Milestone:A significant event in the software developing process in which, the software moves from one phase to another. The milestone let us know where the application is in SDLC

Criteria:Built or created from the standard of the project

Quality Assurance:A process for providing adequate assurance that the software products and processes in the product life cycle conform to their requirements and adhere to their established plans

Quality Control:A set of activities designed to evaluate a developed working product

Testing:The process of executing a system with the intent of finding defects including test planning prior to the execution of the test cases

The key difference to remember is that

·       Quality Assurance is interested in the process whereas

·       Testing and Quality Control are interested in the product

Having a testing component in your development process demonstrates a higher degree of quality (as in QA)

Requirement-based Testing

·       Requirement-based Testing is:

o   Testing the requirement

o   Testing the specifications

o   Testing the produce based in the information in the requirement and spec document

·       The primary goal of Requiremrnt-based Testing is Requirement Validation. It is not expermental, behavioral, exploratory or a bug-finding exercise in nature. It validates

·       The “Mechanical Approach” for Test development:

o   Analyza requirements

o   Gather more information

o   Make at least a test case for every requirement

o   Execute the test cases

Exploratory Testing

·       Exploratory Tesing can have many names: ad hoc, Discovery, Error Guessing…

·       The primary goal of exploratory testing is to uncover new defects in the product on-the-fly

·       The task is finding ways to creatively design experiments, exploring, experimenting, going from a known place to an unknown place

·       Exploratory Tesing is not requirement-driven but it is intense testing. The goal is to probe for weak areas of the program. Some various error conditions should be checked are:

o   Out of boundary

o   Null input and overflow (storage of the sum)

o   Non-numeric

o   Hardware and memory error handling

o   …

·       Exploratory Tesing is the testing appoach which can produce the highest number of bugs

Regression Testing

·       Most common type of work we do!

·       Re-run

·       Quality Control-not testing, not bug finding

·       Expensive

·       First to automate

·       Regression Testing: The testing that is performed after making a functional improvement or repair to the program

·       Regression Purpose:

o   Selective re-run the test cases to verify that the modifications have not caused any unintended effects and  that system still complies with its specified requirements

o   Re-run the test cases to make sure that the bugs marked as fixed by developers are really fixed

·       Re-test all test cases can be done using automated testing tools

·       Some of the most popular strategies for selecting regression test suites:

o   Retest all: Rerun all test cases. Simple but impossible in the time that we have in our everyday practice

o   Restest Risky Use Cases: Choose baseline tests to re-run by risk heuristics

o   Retest by Profile: Choose baseline tests to re-run by allocating time in proportion to operational profile

o   Retest Changed Segment: Choose baseline tests to re-run by comparing code changes

Smoke Testing

·       A smoke test is a collection of written tests that are performed on a system prior to being accepted for further testing, also known as build verification test

·       This is a “shallow and wide” approach to the application. The tester “touches” all areas of the application without getting too deep, looking for answers to basic questions like, “Can I launch the test item at all?”, “Does it open to a window?”, “Do the buttons on the window do things?”.

·       There is no need to get down to field validation or business flows. If you get a “No” answer to basic questions like these, then the application is so badly broken, there’s effectively nothing there to allow further testing

·       These written tests can either be performed manually or using an automated tool

Test Phases: A test phase is a time block often derived from the  SDLC phases. Within each SDLC phase, there might be more than one test phase. Each test phase has different in each section. Testing staff participates in ongoing project management activities

Test Design Methods/Techniques:A test design method is a systematic procedure in which you create tests to be executed. A test type or test appoach may use one or more test design methods

Test plan:A management document outlining risks, priorities, and schedules for testing. A document prescribing the approach to be taken for intended testing activites

Test Case: A test that (ideally) executes a single well defined test objective (i.e., a specific bahavior of a  feature under a specific condition)

There are 3 commojn paradigms in testing engineering: glass-box testing, black-box testing, white-box tetsting

·       In glass box testing, the tester user his/her knowledge of the  source code to create test cases

·       Black box tests execute the running program, without reference to the underlying code. This is testing from the customer’s view rather than from the programmer’s

·       Gray-box testing consists of methods and tools derived from the knowledge of the application internals and the environment with which it interacts, that can be applied in black-box testing to enhance testing productivity, bug finding and bug analyzing efficiency

Why write test case?

·       Accountability

·       Reproducibility

·       Tracking

·       Automation

·       To find bugs

·       To verify that tests are being executed correctly

·       Use as a Training Tool for new testers

·       For compliance

·       To measure test coverage

Manual Testing

·       Manual Testing is performed by carrying out all the actions manually against the application under test (AUT), step by step and revealing whether a particular step was completed successfully or failing

·       Manual Testing is always a part of any testing effort. It is especially useful in the initial phase of software development, when the software and its user interface are not stable enough, thus test automation does not make sence

Automated Testing

·       Using of software to control the execution of tests, and the comparison of actual outcomes with the expected (specified) outcomes

·       Setting up test-preconditions, and other test control and test reporting functions

·       Commonly, test automation involves automating a manual process already in place that uses a formalized testing process

·       Software tetsing assisted by software tools that enable test engineers to pre-prescribe test cases: (1) the input data and the interfaces of the UAT which will receive the data, (2) the expected/referenced output data value, (3) where to extract the output data from the UAT interfaces, and which output data will be compared against the referenced output data to determine passed/failed. At run-time, the software tools will read the pre-prescribed test cases, execute them, analyze and evaluate the results to determine passed/failed automatically. Common application of automated testing includes, but not limited to functional and/or regression testing

Coverage measures of the amount of testing done of a certain type. Since tetsing is done to find bugs, coverage is a measure of your effort to detect a certain class of potentail errors

Coverage = (# of tests to execute) / (total # of tests)