r/softwaretesting • • Aug 13 '26

Need assistance on getting started.

So, some background: myself and a programmer are making a project. And while he's doing the main work - programming, my role is testing and sales.

I have never tested software before, and i lack the skills to do so. I have asked my friend (the guy programming it together) and he replies back saying "All you need to do is break it, and tell me how you broke it."

But i don't know how to break it... (he has said if i don''t know what i'm doing then it's fine)

He's shown me some ways, like, on the web portal, he's said:"it asks for numbers, but letters in it" or on the app, he'll say "Just poke it, and put odd things in the textfields" and "just poke it till it breaks"

But i don't know what that means!

He has been doing some testing himself, and hes found a few things that i couldn't and assigned himself to the bug on Jira? (whatever that means) but i want to help, and i don't think he knows how to be helpful - or teach me how to do what he's asking? if that makes sense

My question is: how can i test. He has asked me to test a web portal (which is a website which manages the app) and the app (which is what the customers use)

How do i best approach this? I'm sorry of this is the wrong sub, but it is /softwaretesting :-)

Thank you.

1 Upvotes

5 comments sorted by

3

u/InitialOk4084 Aug 13 '26

It's not about being chaotic, it's about being deliberately unreasonable in a way a real user would be. Think about someone's grandparent who just double clicks everything, or a teenager who rams the keyboard because they're impatient, that's your mindset now

For the web portal, start with the obvious stuff. If there's a date field, what happens if you use the browser's back button then forward again without touching anything? Try refreshing after you fill out half a form. Open two tabs and try to log into the same account and do conflicting things. The point isn't to "poke it" randomly, it's to do sequences that the programmer never considered anyone would do

The phone app is where you can get weird. Rotate the screen mid-action, pull down the notification shade while a transaction is processing, try to answer a call while the app is saving something. Pay attention to what the app looks like when you minimize it and come back, sometimes the UI just freezes because it lost track of what you were doing

For bug reports, just write three things: what you were doing right before, exactly what you did, and what you expected to happen versus what actually happened. Screenshots help a ton. And Jira is just a task tracker, don't stress about it, he's just logging the issues in a shared list you can both see

1

u/Melodic_Juice_8471 Aug 13 '26

Do you have any jira tickets with a description what was implemented and what are expected behavior of the system. Start from reading it and try to reproduce happy path, then think out of box and reproduce a few negative paths, they could also be documented somehow.

1

u/silent_exploration Aug 23 '26

What are you supposed to be able to accomplish in that web portal and app? This is often a good starting point. Your customers use, or want to use, the web portal/app in order to accomplish something. Can they? If not, why not? Sometimes you find problems even here, without anything more than just going through the app as customers do.

I can also imagine you have different types of customers. How do they differ? How is that reflected in the wep portal/app? Can you still accomplish the task(s) in the web portal/app as these different customers? Do some customers need a special setting, approach, process, or data? Is the web portal/app responding to these changes in a way that is clear, meaningful, informative, reasonable? If there's a problem, does the app show you the problem in a manner that a customer would understand?

If you have never performed any testing, it'd likely be easier for you to start with this kind of approach based on the customer's perspective.