Questions d'entretiens - Manual test engineer

163

Questions d'entretien pour Manual Test Engineer partagées par les candidats

Principales questions d'entretien

Trier: Pertinence|Populaires|Date
Agilysys
On a demandé à un QA Manual Test Engineer...8 décembre 2017

Cut a cake where only 3 cuts are allowed but we have to get 6 pieces

3 réponses

2 cuts horizontal and 1 cut vertical or vice versa

The cake if it is in square shape can have two cuts veritcal and one cut in the center which will give u 6 pieces Moins

Actually the question should be 8 pieces from 3 cuts. IF that is the case the cut should be in X axis, Y axis and Z axis to get 8 pieces. TO get 6 pieces it is a normal cake cutting with 120 degree Moins

Deloitte

what will be the priority and severity of pen without cap

3 réponses

Its again depends on released based , for example if we need to release this feature in the current sprint we have to consider priority is High even though severity is Low. But by considering the business value , the severity is high and priority is low (If this feature is not in the current release ) correct me if I am wrong. Moins

high priority as it impacts the business value.and low severity as pen is usable even without its cap Moins

High severity as pen without cap have more chances to get damage. also it will impact business value of product. low priority because even without cap, pen is usable. Moins

Deloitte

give example of different combination of severity & priority defects eg.high severity & low priority

2 réponses

you can say,an application crashes after 200 times clicking on some button As clicking 200times is rare case so low priority and application crashes so high severity Moins

High Priority & High Severity: All show stopper bugs would be added under this category (I mean to say tester should log Severity as High, to set up Priority as High is Project manager’s call), means bug due to which tester is not able to continue with the Software Testing, Blocker Bugs. Let’s take an example of High Priority & High Severity, Upon login to system “Run time error” displayed on the page, so due to which tester is not able to proceed the testing further. High Priority & Low Severity: On the home page of the company’s web site spelling mistake in the name of the company is surely a High Priority issue. In terms of functionality it is not breaking anything so we can mark as Low Severity, but making bad impact on the reputation of company site. So it highest priority to fix this. Low Priority & High Severity: The download Quarterly statement is not generating correctly from the website & user is already entered in quarter in last month. So we can say such bugs as High Severity, this is bugs occurring while generating quarterly report. We have time to fix the bug as report is generated at the end of the quarter so priority to fix the bug is Low. System is crashing in the one of the corner scenario, it is impacting major functionality of system so the Severity of the defect is high but as it is corner scenario so many of the user not seeing this page we can mark it as Low Priority by project manager since many other important bugs are likely to fix before doing high priority bugs because high priority bugs are can be visible to client or end user first. Low Priority & Low Severity: Spelling mistake in the confirmation error message like “You have registered success” instead of successfully, success is written. Developer is missed remove cryptic debug information shortcut key which is used developer while developing he application, if you pressing the key combination LEFT_ALT+LEFT_CTRL+RIGHT_CTRL+RIGHT_ALT+F5+F10 for 1 mins (funny na). It is where rare scenario where user can hold the key for such long period of time so bug should be marked as low priority. Moins

Capita

normal manual testing concepts and practical scenarios about the project. agile write test cases for some scenario

2 réponses

I have also faced same behavior. It's really annoying and waste of time. I understand that you want to take 1-2 rounds to decide on some candidate. But it's so unfair for a candidate. Moins

I have also faced same behavior. It's really annoying and waste of time. I understand that you want to take 1-2 rounds to decide on some candidate. But it's so unfair for a candidate. Moins

Deloitte

how do you execute test cases when you have less time and you know you can't complete test cases

2 réponses

priority and risk based testing approach

1.First execute the high / core functionality / features of the application. 2.Risk based test cases execution 3.Based on the client requirement release based 4Aand send the mail to the concerned person /client like we have to focus on the following areas only because shot notice release and less time. Moins

Deloitte

defect logging details

2 réponses

defect id,defect description,raised by,priority,severity,date raised,expected date for fixing,assigned,component,version/build,environment,defect type,attachment/screenshots,steps to reproduce,test data(optional),project,release,cause of defect,scripts affected,number of scripts affected, etc Moins

The Below are the mandatory information for the defect logging 1.Description : exactly what the defect is , have to mention very clearly 2.Steps to reproduce 3. Severity and priority 4.Screenshot and URL of the web application 5. Requirement ID 6.Expected and actual Result Moins

Deloitte

defect(or bug) life cycle

2 réponses

The bug has different states in the Life Cycle. The Life cycle of the bug can be shown as follows with different status. New: When a defect is logged and posted for the first time. It’s state is given as new. Assigned: After the tester has posted the bug, the lead of the tester approves that the bug is genuine and he assigns the bug to corresponding developer and the developer team. It’s state given as assigned. Open: At this state the developer has started analyzing and working on the defect fix. Fixed: When developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team. Pending retest: After fixing the defect the developer has given that particular code for retesting to the tester. Here the testing is pending on the testers end. Hence its status is pending retest. Retest: At this stage the tester do the retesting of the changed code which developer has given to him to check whether the defect got fixed or not. Verified: The tester tests the bug again after it got fixed by the developer. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “verified”. Reopen: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “reopened”. The bug goes through the life cycle once again. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “closed”. This state means that the bug is fixed, tested and approved. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “duplicate“. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “rejected”. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software. Not a bug: The state given as “Not a bug” if there is no change in the functionality of the application. For an example: If customer asks for some change in the look and field of the application like change of colour of some text then it is not a bug but just some change in the looks of the application. Moins

The bug has different states in the Life Cycle. The Life cycle of the bug can be shown as follows with different status. New: When a defect is logged and posted for the first time. It’s state is given as new. Assigned: After the tester has posted the bug, the lead of the tester approves that the bug is genuine and he assigns the bug to corresponding developer and the developer team. It’s state given as assigned. Open: At this state the developer has started analyzing and working on the defect fix. Fixed: When developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team. Pending retest: After fixing the defect the developer has given that particular code for retesting to the tester. Here the testing is pending on the testers end. Hence its status is pending retest. Retest: At this stage the tester do the retesting of the changed code which developer has given to him to check whether the defect got fixed or not. Verified: The tester tests the bug again after it got fixed by the developer. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “verified”. Reopen: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “reopened”. The bug goes through the life cycle once again. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “closed”. This state means that the bug is fixed, tested and approved. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “duplicate“. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “rejected”. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software. Not a bug: The state given as “Not a bug” if there is no change in the functionality of the application. For an example: If customer asks for some change in the look and field of the application like change of colour of some text then it is not a bug but just some change in the looks of the application. Moins

Fiserv

there were more question on the Performance side and scalability of application in the test which is not needed for a Manual testing profile.

2 réponses

Technical ..

is written test aptitude or technical?

DarkMatter

How to install app on an android mobile

1 réponses

adb install path/filename.apk

SanDisk

there is a room consists of one light bulb and it has onlt one door which is light sealed..The bulb is connected to the 3 switches which are placed outside the room.so you need to find the correct switch which lights the bulb. conditions: you can enter the room only once to see whether the bulb is lighting or not. You should find the exact switch.

1 réponses

Let -- Bulbs are X,Y and Z . Turn on switch X for 5 to 10 minutes. Turn it off and turn on switch Y. Open the door and touch the light bulb. 1. if the light is on, it is Y 2. if the light is off and hot, it is X 3. if the light is off and cold, it is Z Please write comments if you find anything incorrect, or you want to share more information about the topic discussed above Moins

1 - 10 sur 163 questions d'entretien d'embauche

Consultez les questions posées en entretiens pour des emplois similaires

manual testertesting engineermanual qa testertest analystsoftware testerautomation testeretl tester