Tipuri de testare:

Functional - checking the functionalities of the software system

Functional Testing Non-Functional Testing

Functional testing is performed using the
Non-Functional testing checks the  Performance,
functional specification provided by the client
reliability, scalability and other non-functional
and verifies the system against the functional
aspects of the software system.
requirements.
Non-functional testing should be performed after
Functional testing is executed first
functional testing
Manual Testing or automation tools can be used
Using tools will be effective for this testing
for functional testing
Business requirements are the inputs to Performance parameters like speed, scalability are
functional testing inputs to non-functional testing.
Functional testing describes what the product Nonfunctional testing describes how good the
does product works
Easy to do Manual Testing Tough to do Manual Testing
Examples of Functional testing are Examples of Non-functional testing are

• Unit Testing • Performance Testing

• Smoke Testing • Load Testing
• Sanity Testing • Volume Testing
• Integration Testing • Stress Testing
• White box testing • Security Testing
• Black Box testing • Installation Testing
• User Acceptance testing • Penetration Testing
• Regression Testing • Compatibility Testing
• Migration Testing
 

Boundary Value Analysis (BVA): As the name suggests it's the technique that defines
the testing of boundaries for a specified range of values.
Equivalence Partition (EP): Equivalence partition means same class
State Transition Technique: This method is used when software behavior changes from
one state to another following particular action.
Error Guessing Technique: This is guessing/anticipating the error that may arise while
doing manual testing. This is not a formal method and takes advantages of a tester's
experience with the application
In prioritizing what to test, the most important objective is to:
High risk area is to be checked first as it may posses potential bugs.

The oracle assumption:

Test oracle does the comparision ans is part of the Test comperator. it is assumed that it will do the
comparision and provide the reliable result every time.

Error guessing: A structured approach to this technique is to enumerate a list of possible defects and
to design tests that attack these defects.Hence Supplements formal test design techniques.

V- model includes the verification of designs.

capture-replay tools
Most tools of this type get started by capturing or recording manual tests; hence they are also
known as ‘capture/ playback’ tools, ‘capture/replay’ tools or ‘record/playback’ tools. They are not
used to capture the user behaviour.

cost of faults
Concept is early the bug is found less expensive it is . system testing comes towards the end of the
development cycle so it costs more compare to on found during review.

 Incident resolution is job of everyone in the team.

Test execution can be automated with the help of a tool to great extent and helps in reducing the
cost and time.

Test comparators determine differences between files, database or test results. Test execution tool
typicaly include dynamic comparator, but post-execution comparision may be done by a separate
comparison tool. A test comparator may use a test oracle, especially if it is automated.

Determining how the existing system may be affected by the changes is called impact analysis.

Test procedure specifies the sequence of action for the execution of a test.
the content of the master plan is covered by the concept that the document "Test plan" covers
different levels of planning. hence it covers how testing will be performed.

 Exit criteria defins when to stop testing such as at the end of a test level or when a set of tests has
achived specific goal.

Project risks are the rosks that sorround the project;s capability to deliver its objectives; produc
risks are potential failure areas in the software or system

-100% branch coverage guarantees 100% statement coverage.

-100% branch coverage guarantees 100% decision coverage.
-100% decision coverage guarantees 100% branch coverage.
To perform 100 percent statement we have to write tests to validate each condition. In the process of
validating condition we can detect many fault. with 100 percent branch coverage no necessary we
can cover all the statements and dead code in the software may remain. so 100percent statement
coverage is a better option.
An independent tester may be more effective at finding defects missed by the person who wrote the
software

The process of designing test cases consists of the following activities:

1. test planning and control
2. test analysis and design
3. Test implementation (comparision) and execution
4. exit criteria
5. Test closure

Test basis for acceptance testing are user requirement, system requirement ,use cases, business
process and risk analysis report.

The main objective of testing is to prove that the software is working.

A failure is: departure from specified behaviour.

Test specification is a step where test case is designed.

An important benefit of code inspections is that they Enable the code to be tested before the
execution environment is ready

Integration testing tests interfaces between components, interactions with different parts of a
system, such as the operating system, file system and hardware, and interface between systems.
hence, Tests interactions between modules or subsystems is more appropriate.

 Configuration Management tools is used for maintaining vesrions

Alpha testing is done before the beta testing and it is done at the developer sites by the end user. it is
the last testing at the developer site. after alpha testing beta testing starts

 Data flow is a static analysis tool to review the code by going through the flow of the code. .

Exploratory testing is Concurrent test design, execution, logging and learning based on test charter
containing test objectives. This approach is most useful where there are inadequate specifications
and severe time pressure.

Planning is usually done to lay down the road map. hence Test Plan provides Road map for testing.

white box testing is also called as Structural Testing.

Functional testing verifies that each function of the software application operates in conformance
with the requirement specification. In other words, comparing the actual results with the expected
results.this can be done at any stage

If the application is complex, but NOT data intensive and is to be tested on one configuration and 2
rounds, the easiest method to test is manual testing

Preparing the automated test cases before coding is called Test first approach or Test-driven
development(both means same)

Configuration management tool deals with the versioning of the artifects.

Review is done to find the defects or errors present in the design, and the discussion diring the
review meeting helps to find and solve the problem with design.

Person per day and prson per hours is used to define the size of project but calender per month is
not used.

Equivalence partitioning is a software testing technique to minimize number of permutation and

combination of input data. In Equivalence Partitioning , you divide set of test conditions into
partitions that can be considered the same. The divided sets are called Equivalence Partitions or
Equivalence Classes. Then we pick only one value from each partition for testing. Hypothesis
behind this technique is that if one condition/value in a partition passes all others will also pass.
Likewise , if one condition in a partition fails, all other conditions in that partition will fail.

Syntax to follow for development is already guidlined like in MISHRA guidline, if syntex is written
wrongly then it has to be correct as per the guidline. In syntax testing test cases i.e input to the
software are created based on the specifications languages

Statement coverage is the assessment of number of executable statements that have been exercised
by a test case at least once. Decision coverage Decision coverage, related to branch testing, is the
assessment of the percentage of decision outcomes (E.g., True and False options of an IF statement)
that have been exercised by a test case suite. 100% decision/branch coverage guarantees 100%
statement coverage, but not vice versa., in this question we focusing on the conditions hence
condition coverage is the answer.

Test plan is made by the test manaer not by test leader, test leader is related to the testing process
implementation, exit report , cordination with manager etc.

Component integration testing: tests the interactions between software components. Once the
component testing is done component intigration starts.

Test planning is the activity of Defining the objectives of testing and The specification of test
activities in order to meet the objectives and mission.

Reviewers: Individuals with a specific technical or business background (also called checkers or
inspectors) who, after the necessary preparation, identify and describe findings

Big Bang testing: An integration testing approach in which software elements, hardware elements,
or both are combined all at once into a component or an overall system, rather than in stages.

Test analysis and design is an activity of transforming test objectives into test conditions & test
designs.

Branch Coverage is another name for decision coverage. The percentage of branches that have been
exercised by a test suite. 100% branch coverage implies both 100% decision coverage and 100%
statement coverage.

Functional testing verifies that each function of the software application operates in conformance
with the requirement specification. In other words, comparing the actual results with the expected
results.Its a Validation techniques

maintenance testing Testing the changes to an operational system or the impact of a changed
environment to an operational system.

 V-model A framework to describe the software development lifecycle activities from requirements
specification to maintenance. The V-model illustrates how testing activities can be integrated into
each phase of the software development lifecycle.

An incremental approach to integration testing where the lowest level components are tested first,
and then used to facilitate the testing of higher level components. This process is repeated until the
component at the top of the hierarchy is tested.

maintenance testing Testing the changes to an operational system or the impact of a changed
environment to an operational system.

A mistake in coding is called error, error found by tester is called defect, defect accepted by
development team then it is called bug, build does not meet the requirements then it is failure.