Ans: As a test engineer, I have to verify the hot fix and I also should conduct regression testing for the same. Since time is very crucial for hot fix. I would prefer to do possible testing activities in parallel to development so that the time to release can be reduced.

Ans: Some of the examples of risks in the product are
Team turnover (Team members leaving the project)
Domain of the project was new
Unexpected long leave of employees
Knowledge of technology
Knowledge of products and requirements developing during the course of the project
Complexity of the project
Visibility of the project

Ans: Browser compatibility
Operating system compatibility
Hardware compatibility

Ans: I believe every product will have a user manual and admin manual even if the SRS is not available. These manuals are one of the best places for me to understand the product. If you don’t even have these manuals, I believe that the context based help is provided for the functionality of each screen. Using the domain knowledge I have, I will explore each screen to understand the workflow of the application. We call this activity of exploring the application for understanding its behavior as exploratory testing.
Then I would prepare test conditions and a test case for each functionality of the product and take the review by involving developers and business analysts. I can use the finalized test cases for further test cycles execution.

Ans: I have tested many application that are developed using object oriented programming languages like java, C# etc. Being a tester, functional understanding of an application is essential for me. My testing focuses on checking whether the application meets business requirements as specified in SRS. It doesn’t matter which language is used to develop the application.

Ans: Testing is the process of locating or identifying the errors or bugs in a software system, where as debugging is the process of fixing the identified bugs. Testing is done by the test engineer and debugging is done by the developer.

Ans: The steps to be followed in retesting a bug
I understand the bug description and steps to reproduce the bug from the bug tracking tool. Optionally I also try to understand the root cause given by the developer for this bug.
I identify the test conditions to be used for verifying this bug.
I will run the test cases which found this bug to make sure that this bug is nor appearing.
I also run the test cases which cover all the test conditions identified for verifying this bug. In case some test conditions are not part of any test case I update the test case document with these additional conditions
After completion of test cases execution I document the tests executed to verify this defect in the comments section of the bug tracking tool with my time stamp.
I will send the tests I executed to retest the bug for peer review and based on the approval I update the status of bug to ‘closed’.

Ans: We stop testing a project when:
The traceability matrix shows that all the requirements are covered through testing
The test coverage report is 100%
All medium and above severity bugs are fixed, else they are differed with the concurrence of all the stakeholders.

Ans: I worked on a web based ecommerce application and involved in conducting following tests.
Requirements based functional testing
Business process flow functional testing
Browser compatibility testing
Smoke testing
Regression testing
Retesting

Ans: Articrafts produced during the test process such as test plan, test conditions, test cases, test procedures, test execution reports, test summary reports and automation scripts are known as test deliverables.