monkeypaster.blogg.se - Microsoft principal software engineer interview questions

#Microsoft principal software engineer interview questions code

Low severity but high priority issues include these types of scenarios:

Clicking on a submit button 50 times causes the application to crash.

Unpublished posts (draft versions) in admin can be accessed without a valid login if the exact address is typed in manually (e.g.

Application crashes when an obscure button is clicked on a legacy page which users rarely interact with.

High severity but low priority issues include scenarios like: Usually, the priority increases as the issue is more reachable by the end user. On the other hand, the value for priority is defined by the individual judgment of a responsible person in accordance with the specified requirements. But if the end user encounters application crashes or similar problems while using the application, the severity increases to high. If the end user will be able to normally interact with the application and the normal use of the application is not obstructed, then the severity is low. Severity is a characteristic that is precisely defined as it is based on how the issue affects the end users. Severity represents the harshness of the issue, while priority represents how urgently the issue should be resolved. Issue severity and issue priority are important for proper issue management. An incorrect title alone shouldn’t affect the rest of what’s being tested. checking a web page title: We just want to make sure that the page title is as expected and we will log the outcome of the verify command.

#Microsoft principal software engineer interview questions code

We use verify commands when the code after them can be executed regardless of the condition having been met. In that case, we will assert that the currently logged-in user equals the admin user, and test code will execute only if that condition is met-otherwise there’s no point, because we know we’re testing in the wrong environment. we want to perform actions on a page only if we are logged in as an admin user. We use assert commands when the code following them depends on their success. On the other hand, when a verify command fails, the code will continue with execution regardless. When an assert command fails, the code following it will not be executed and the test will break immediately. The difference is what happens if the condition is false and the check fails. In order to perform those checks, for example by using Selenium framework, we use the Assert* and Verify* classes of commands.īoth assert and verify command groups check if the given conditions are true. In test automation, throughout each test case, we make validation checks to assure that we are getting the right results. The essential part of testing is the validation of results. Test cases for boundary value analysis are: 10 and 99 (valid) -10, -9, 9, and 100 (invalid).Test cases for equivalence partitioning are: 42 (valid) -15, 2, and 107 (invalid).10įrom those four partitions and the boundaries between partitions, we can devise the following test cases:

Any three-digit integer: a number greater than 99 (invalid input)īoundary value analysis testing is a software testing technique that uses the values of extremes or boundaries between partitions as inputs for test cases.Any negative two-digit integer: a number smaller than -9 (invalid input).Any single-digit integer: a number greater than -10 and smaller than 10 (either positive or negative) (invalid input).Any positive two-digit integer: a number greater than 9 and smaller than 100 (valid input).For the example in question, we can create four partitions: In such situations, we need a better way of choosing test cases, while making sure that all the scenarios are covered.Įquivalence partitioning testing is a software testing technique which partitions input test data in such a manner that, for a single input from the entire partition, the system under test would act the same.

In the case of valid input being a positive two-digit integer, there are already 90 valid test cases, and there are many more invalid test cases.

Quite often in QA, it is not feasible to test all the possible test cases for all scenarios.