Smoke tests/starting to test

The first time joining a project may be confusing to many newcomers looking to start their journey in software testing. On top of figuring out where to find all the info you need to meet the project requirements, you also need to figure out what to start with in terms of testing.

• Which section of the app should I test first?
• Is one feature more important than the other?
• For how long should I be exploring a specific section of the app?

👉 These are questions each of us figures out as they participate in more and more projects, but in this article, we’ll try to provide some insight into the basic principles of a smoke test and what’s usually considered to be a good start each time you join a testing project.

🔎 Smoke testing is the process of ensuring a software build is stable before putting any more effort into testing it.

Think of it as an initial check on the stability of an app: if the Sharing functionality doesn’t work in a social media app, QA teams won’t proceed with testing advanced settings or other secondary features on that build version. They will instead report that major issue and request a new version be released.

Let’s try to adapt the smoke testing principle to the first steps after joining a project on Tester Work:

The first thing you should do after receiving the build and the test specification document checks the most important functionality of the app. Go through the login flow, access the main screens and features available to the user and report any issues encountered during the flows which are most obvious to you during the initial launch of the app.

Unlike QA teams, who will stop testing when they’ve reported a critical issue during the smoke test, the benefit of testing on our platform is that you’re still able to move forward with testing despite that initial issue. Move forward into the more advanced features of the app and report any other bugs you’re finding there!

Just keep in mind that if the issue you've reported causes further problems down the line (eg. not being able to access the device's gallery from within a given app prevents you from uploading a profile picture or using local images for any other feature), you should add all of the resulting problems as extra details to your initial report, not as separate bugs. These are considered Duplicates, as the secondary problems wouldn't occur without the existence of the initial bug. 

So there you have it, this is our recommended way of starting to test after joining a project: Check the main functionality of the app and report the issues you’re finding during that check. The next steps will come naturally once you’re confident you’ve covered the main features.