ISTQB questions with answer

ISTQB Test1

ISTQB Test2

ISTQB Test3

CapLink

Form

Test scenarios on Object and Applications

Test scenarios for applications
Test scenarios for object

STLC

Test Plan – is a document which derives all future activities of the project. All future testing activities is planned and put into a document and this document is known as Test Plan. It contains – number of engineers needed for the project, who should test which feature, how the defects must be communicated to the development team, when we should start and finish writing test cases, executing test cases, what are the types of testing we use to test for the application etc.

Write test case – we write test cases for each feature. These test cases are reviewed, and after all mistakes are corrected and once the test cases are approved – then they are stored in the test case repository

Traceability Matrix – it is a document which ensures that every requirement has a test case .

Test cases are written by looking at the requirements and test cases are executed by looking at the test cases. If any requirement is missed i.e, test cases are not written for a particular requirement, then that particular feature is not tested which may have some bugs. Just to ensure that all the requirements are converted, traceability matrix is written. This is shown below,

The Traceability Matrix is also known as RTM(Requirement Traceability Matrix) or CRM(Cross Reference Matrix).

Test Execution Report :- Send it to customer – contains a list of bugs(major, minor and critical), summary of test pass, fail etc and when this is sent, according to the customer – the project is over.

TER is prepared after every test cycle and sent to development team, testing team, management and customer(depends if it is a fixed bid project or time & material bid project).

The last TER of the last test cycle is always sent to the customer. And this means that the project is over-according to the customer.

Retrospect meeting – (also called Post Mortem Meeting / Project Closure Meeting)

The Test Manager calls everyone in the testing team for a meeting and asks them for a list of mistakes and achievements in the project.

MISTAKES(Mistakes in the Process)	ACHIEVEMENTS(good process/procedure followed)
1) Review process is not good	1)Last day of each cycle generally swap modules and do ad-hoc testing
….	…..
…..	…..
…..	….

This is done by test lead or test manager. Here, the manager documents this retrospect meeting and stores it in QMS (Quality Management System). It is a folder, where inside this folder, there is another folder called Retrospect folder and here this excel sheet document is stored. When we get new project, while we write the test plan – we will open this retrospect file and will try and implement the good practices and correct the mistakes.

Test case Template

Header of the Test Case:

1.       Test case Name:

Test engineer will write a unique test case name for every individual test case in a test management toll or in excel:

Example:

Project Name_ModuleName_ScenarioName

CityBank_AmountTransfer_FAN Text field should accept 10 digit Positive interger.

Gmail_Login_To validate login Functionality:

2.       Test Data:

It is a data created by test engineer in the application before executing test case or step no1.

3.       Severity:

TE while writing test case, TE should give severity for every individual test case based on the complexity and importance of the feature from the customer business point of view.

Forms of Adhoc Testing

Forms of Adhoc Testing

1.   Buddy Testing: Two buddies, one from development team and one from test team mutually work on identifying defects in the same module. Buddy testing helps the testers develop better test cases while development team can also make design changes early. This kind of testing happens usually after completing the unit testing.

2.   Pair Testing: Two testers are assigned the same modules and they share ideas and work on the same systems to find defects. One tester executes the tests while another tester records the notes on their findings.
3. Monkey Testing: Testing is performed randomly without any test cases in order to break the system

Drawbacks of Manual Testing:

Drawbacks of Manual Testing:

1) Manual Testing requires more time or more resources, some times both Time and Resources.

2) Less Accuracy

3) Performance testing is impractical in manual testing.

4) Comparing large amount of data is impractical.

5) Batch Testing is possible, but for each test execution Human user interaction is mandatory.

6) Manual Test Case scope is very less, if it is Automated test, scope is more.

7) Executing same tests again and again is time taking process as well as Tedious.

8) For every release you must rerun the same set of tests which can be tiresome.

Advantages of Manual Testing:

1)No Environment Limitations

2) Programming Knowledge is not required.

3) Recommendable for Dynamically changing GUI designs.

4) Manual testing allows for human observation, which may be more useful to find potential defects.