JAN15 STQA

JAN15 STQA

1ai) V-model

  ii) why V-model is an appropriate model to be tested in ST compared SDLC

     Construction and test activities are separated but equal.”V” illustrates the testing aspects verification and validation. There are different testing levels in which each level performs tests “against” their corresponding development phase. The test steps in the right branch of the model are to be understood as phases of test execution.

§        Suited for Restricted Projects: Due to the stringent nature of the V-Model and its linear design, implementation, and testing phases, it’s perhaps no wonder that the V-Model has been heavily adopted by the medical device industry in recent years. In situations where the project length and scope are well-defined, the technology is stable, and the documentation & design specifications are clear, the V-Model can be a great method.

§       Ideal for Time Management: Along the same vein, V-Model is also well-suited for projects that must maintain a strict deadline and meet key milestone dates throughout the process. With fairly clear and well-understood stages that the whole team can easily comprehend and prepare for, it is relatively simple to create a time line for the entire development life cycle, while generating milestones for each stage along the way. Of course, the use of BM in no way ensures milestones will always be met, but the strict nature of the model itself enforces the need to keep to a fairly tight schedule.

b) Different error, fault and fail. Example for each.

Error	Fault/Defect	Fail
Human action that produces an incorrect result	A flaw in the component/system that can cause the component/system to fail to perform its required function	Deviation of the component /system from its expected delivery, service or result
A programmer commits an error by reusing a piece of software which is not intended in the context of the current project	After the programmer has reused the piece of code in the wrong context, the software contains defect	The Ariane 5 rocket crashes on its own first mission.

c) The defect of clustering- testing effort shall be focused proportionally to the expected and the observed defect density of modules. A small number of modules often contains the most of the defects discovered during pre-release testing/responsible for most of the operational failures.

Absent-of-error fallacy- A system without failures does not imply that the system will meet the user’s expectation.

2a) Why is important the balance between self-testing and independent testing in testing psychology(4m)

Self-testing	Independent
Being blind to see own mistakes- not able to specify appropriate test cases	Unbiased- not his product
No familiarization-the developer knows his test object	Familiarization – to create test case, tester needs to gain knowledge about test object Test know-how-tester should have test know-how

1.       Top down integration

2.       Bottom up integration-the test begins with the elementary components of the system do not call other components. The successfully larger subsystem is assembled from tested components, followed by attesting of this integration.

3.       Ad-hoc integration- the components are integrated, for example in the order of their completion. Once a component has completed its testing, it is checked whether its belong to already existing and previously tested components or it fits into a semi-integrated subsystem. If so, both elements are integrated and the integration test is executed between the two.

c) 2 reasons to execute the test in a separate infrastructure

-In the lower test levels, the software was tested against technical specifications, mostly from developer’s viewpoint. System testing, however, examines the system from the customer’s perspective and its later user. The testers validate if the requirement were fully and appropriately implemented.

-Many functions and system properties result from the interaction of all system components and are therefore only observable and testable at the level of the overall system.

d) Business process-based testing adapted as a testing strategy for functional req.

-          Used if a software system has the purpose of automating or supporting the business process of a customer.

-          A business process analysis shows which business process is relevant, how often they are used and in which context they appear.

    Testing based on requirement

-          The approved requirements specification document is used as test basis

-          The system specification will also be verified by a review

-          For each requirement, test cases are derived and recorded in the system specification

     Use case testing

-          System test cases can be derived which describe how user handles the system and which acts are typical carries out

-          Different user groups each possess their own user profiles. Typically interactions or use   cases with a realistic frequency can be identified for these groups

-          From these typical interactions, test scenarios can be derived.

-          On the basis of frequency that various actions are performed in using software, the user determines how important the corresponding test scenario is and with which priority it, therefore, to be included in a test plan.

4a) Difference white and black project

white	black
Input values derived with knowledge of the program logic	Input values derived without knowledge of program logic
Testing based on an analysis of the internal structure of the component or system	Specification based test design techniques

Test harness

Driver- call the service of object

Stub- Dummy simulation of the service that test object imports

At this test level, the tasks are closely related to the development. To create test environment, developer know-how is required. The program code of the test object – at least the code of the interface, must be available and understood, so that the driver can be programmed to call the test object correctly. Therefore, component tests are often carried out by developers. For these reasons, component testing is often referred as development testing.  

Non functional requirement

-          Load testing-measurements of the system behavior in relation to increasing system load

-          Performance testing –measurements of processing speed and response time for specific use cases, normally in relation to increasing load.

-          Stress testing-observation of system behavior when overloaded

Difference re-testing and regression

-          Re-testing-If a failure was detected and corrected, a re-test must conducted to ensure that failure was successfully eliminated

-          Regression testing-When tested program were modified, it needs to be shown that no new failures were built in or failures which were undetected have become visible.

CH3: Static Test

Review steps

1.       Manual testing by one or more people

2.       Human analysis and thinking capabilities are used to test and evaluate products

3.       Any software work product can be reviewed