Testing Without Requirements - Need help

Hi everyone!

To get the job as a junior QA engineer I have to complete a task that doesn’t seem to be suitable for a junior)
I understand that nobody is going to do it instead of me, but I’d appreciate any link or advice how to accomplish this task as I’m completely stuck(

Thanks everybody for your help in advance. The following is the task description:

“ Task 3 – Give your ideas on the QA process

As you may know, ideal processes at products usually can be found only in the handbooks. Quite often when a QA Engineer joins the product, there is no documentation or it is quite outdated, or the product is in production but there hasn’t been any tester who would have tested it, etc.

So, your task is to write an essay about the process you would offer for introducing quality assurance to a product. There is some information that we should take into account before we suggest the process to the client:

The product is a mobile application for the UK market.

The app has been under development for about 7 months already. We are planning to release the app to production in 2-3 months.

The team consists of the product owner - a businessman from the UK, two back-end Node.js developers, and two front-end React Native developers. Also, there is a designer, who is partially helping with the planning of the work scope.

The team works with Agile methodology. They try to plan the scope of tasks for two weeks.

There are designs in Figma, some of the screens are outdated.

The task management system used for the product is Trello. Some requirements can be found there.

There is no test documentation, obviously.

Proper testing hasn’t been done for the product. Usually, developers checked what they implemented and fixed bugs found by the product owner.

Please, think about what you can offer in this situation to prepare the app for the release. Describe steps, actions, and tools that will help you.”

5 Likes

Junior, Medior, Senior, Principal, Testing God, … without requirements it’s never suitable for anyone :stuck_out_tongue:

It’s really all about asking. Never ASSUME anything, always ask. Note it down and move to the next questions. Don’t note down assumptions either, when somebody says ‘it should work like that’ – for me, that’s not acceptable. It either works like that or it doesn’t. ‘Should, Usually, Normally’ words like these… try to avoid them. Although these words are music to any testers ears because this is where the bugs are hiding :wink:

It’s going to be really hard to define a process, because you want to develop a process that works for your entire team. Which isn’t always the “best” solution on paper.

Automated tests (do you have these?):

  • Unit tests + Mutation Tests
  • API + Integration tests
  • Perhaps UI tests?

I’m not sure how much time and effort you are willing/can get into writing documentation yourself. Let’s say you’ll have to test a new feature or a current existing feature, would you be able to fully document it?

It’s going to be a bit rough and gut feeling in the beginning of guessing how the app will work, as I mentioned before, when your gut tells you this isn’t how it’s supposed to work, get confirmation. You don’t want to assume anything. After that note it down on a wiki or some page so others after you will not make the same mistake.

You could start writing test scenario’s, this will also start eliminating a lot of assumptions.

Are you the only tester on the project?


When you are testing without (NFR-)requirements, there is 1 thing I always do.

I’ll tell them: ‘this is how the app works and this is the performance’

I do NOT tell them the performance is great nor bad or the app works fine, I keep standing ground stating that I cannot confirm nor deny if the app works fine because there are no requirements. If they want me to give a GO or NO-GO, they’ll have to get me requirements. They’ll be pissed but at least you are doing your job correct :slight_smile:

6 Likes

Hi @slavasosnin ,

Welcome to the community and thanks for asking your question.

Here’s an approach that might prove useful when things are super unclear and you have to make a tonne of assumptions. Use a “Risks & Questions” approach. Here’s the sort of reply I’d share for the exercise you mention.

Let’s assume I’ll have to ask lots of questions to discover useful information to inform how I define a QA process. So for now I’ll take an exploratory test approach to solicit useful information. Here’s how I’d do that:

  1. Capture the value of the product we’re developing. What’s important to our customers? What problems are we trying to solve for them? What pain points are they experiencing with the current product? This will be done via interviews wit the team.
  2. Document risks. These are things that threaten the value of the product you’re developing. What worrying things might happen when someone uses the product? What risks are we aware of already?
  3. Ask questions. What questions could we ask about those risks that help us learn more about those risks? Stuff like “What happens when …”, “How many times does …” or “Why does it …”
  4. Go explore. I’ll explore the product to answers those questions. I’ll capture my notes and present them back to the team. I might even run them as 60-minute sessions to see what other risks I discover which will inform more questions for us to run more exploratory sessions.

After I’ve run this exercise a number times I’ll have good enough amount of information to put together the beginnings of a QA process.

I’ve shared an audio version of a similar approach on Racket. Hope it helps.

Good luck!
Simon

5 Likes

Take a breath; they’re not expecting you to have all the answers - they just want to see that you can think things through, come up with an approach, and talk about it. I think this is actually a great task, for juniors as well as those further along in their careers. The scenario is a common occurrence, and as an interview question/screener, it’s meant to let them get some insight into your thought process (as well as your written communication skills).

If I were using this question for candidates, I’d probably send it as a pre-screen, before an interview, and then use the candidate’s answers during an interview as a springboard for discussions. It’d be a way for me to get insights into how they think, what they do when presented with new ideas, how they respond to criticism, etc.

I actually think it’s a really strong prompt, in that they’ve given a lot of small details, and there’s multiple ways you could approach this, different things you could latch onto/describe/etc.

5 Likes

Like others pointed out this could seem like a daunting task, but could also be a great opportunity. Maybe do some research to see how leading companies are doing software testing a take some notes based on that, for instance Netflix and Microsoft have been doing some interesting things in terms of testing.

Aside from that, just be transparent and forthcoming, give it a shot it could be an excellent learning opportunity!

3 Likes

As a junior or newbie to a domain, whenever I join a new company or start a new kind of work I am partly in this zone. I have 2 coping mechanisms now after years of having to climb this kind of wall. Job interviews are often a lot like that, a wall.

Even once you start a new job, you will get similar kinds of tasks. They will tjhrow you a curve ball.

  1. Like you say, nobody else is going to do the task if you don’t, so take it seriously and do your best.
  2. It’s not a test of your abilities, it’s a test for you to see what you can come up with as alternative ways of approaching something that is, (as you point out because the requirements are missing) a broken system or process. Because you are new to the task, you might just have some fresh insights, even if you are really junior.

There is a belief that Napoleon used to promote his generals based on how lazy they were. His rationale was that lazy people consumer the least resources and always find the most efficient way to do a job. Very often, there are Software Engineering jobs that get done badly, because they are too expensive to do well.

So if I got this question in an interview process I would simply declare:

  1. I’ve yet to see anyone develop and ship a mobile app in one year without any prior experience of doing it (which appears to be the case from lack of process.) So my first step would be to understand the intentions for release of the app and how it will be maintained. Use that to drive testing priorities into either manual or automation testing. It’s pointless doing any automated test if the app gets re-written.
  2. Book a meeting in an informal setting as possible and speak to the PO, and get a good grip on the constraints of the product. All of the constraints, and then build a list of “Most Valuable Features”, and work out how to test for those features.
  3. Build relationships with the engineers and iteratively build and execute on a test plan. This is going to require deciding on test tooling platforms available or suitable to the project, something you won’t be able to judge or plan without the above info.
2 Likes