Best Test Case for QA Interview

This case is not something brand new for QA: testing the simplest form, search box, or login/sign-up form. In practice, many specialists cannot fully solve this problem, considering what IT companies expect.

How to Approach a Problem in QA Interview

During the typical QA interview testers approach this problem using testing theory, classes of equivalence, boundary value analysis, and transition graphs. At the same time, they forget about product testing, when the focus is not on combinatorics and techniques like pairwise, but on scenarios faced by a real user.

Probably now I will have to exclude this question from qa interviews, but I will give an example. Login form: login and password, it is simple. Login mask is either phone number or email and the password is somehow restricted.

Sort Out Combinatorial Options

Most candidates begin to sort out combinatorial options: I will type a lot of whitespaces or something like that. And for the user, other cases are important: with an existing account, if the login-password combination (email + password, phone number + password) is correct – then it works and if that’s a non-existent combination – it doesn’t. For some reason, candidates forget about the password recovery case. You cannot be allowed to pass using the old one but the new one should work. From such cases you can see how well the candidate has mastered test design techniques, whether they can abstract from them and think about the product not as a set of buttons and boxes, but as a user scenario that the most ordinary user can face.

Product vision

Product vision certainly plays a role in testing. Now there is such a trend: shift-left testing. Testing is connected as early as possible, included in the planning procedure and requirements elaboration. This approach is becoming more and more popular in many large companies, and of course, the QA engineer understands what the product vision is.

Let the backlog contain 15-20 tasks: cases are built depending on why we do them and what benefits we bring to the user. For example, we want to increase the retention of a mobile application. And this means that everything associated with reactivation push notifications is a high priority. Therefore, they are expected to work like a clock: come at a specific time, target a person to the place where they should be, and so on. Of course, QA must understand why and how this happens.

Shift-right testing

There is an alternative approach: shift-right testing. The QA engineer starts working and connects before the ticket comes in the ready for test state, and does not leave if the ticket is in a “tested” state. The engineer helps to release and maintain production.

Regression Tests

We are also talking about regression tests, which are repeated and indicate that this functionality has not degraded. It’s also about product metrics. Quite often, looking at them, one can assume that something went wrong: take a look at the same DAU, it decreased dramatically after the last release. We might have missed it in technical metrics and regressions show no problem but still, it is a signal that something went wrong and it influenced these events. Besides, don’t forget A/B testing or feature toggling. Many companies release features to a part of the audience while QA, together with product analysts, assess whether the feature meets the expectations and if so, they are releasing further. QA should not drop a feature because “tested” does not mean that the work is finished.