Saving time with the right screen record setup: Valuable tips to screen cast on your PC

If you are reported any bug, you understand how valuable the report you create is. Speaking for myself, filling Bug Reports is a time-consuming task, not only because of the whole written description of the Bug, but mainly because of the visual proof of the bug. Specially when you are a beginner, making the 

Yes: let’s talk about videos and pictures in the article!

I would like to share with you some apps that help me a lot when collecting the evidence of a bug. In this article we will talk about two tools for desktop devices that completely changed the way I test. I will not only present the tools, but also help you to set them up in order to assess their full potential. Mobile users, don’t get mad at me: we may discuss some tools for you another time, okay?

Screen Record: OBS Studio

One of the reasons why I use OBS Studio to record my screen while testing. It is a free, open source software with multiple features, from simple screen recording to streaming. It is available for Windows, MAC and Linux, and it’s free! It does not leave any watermark on the final video and it doesn’t have any limitation on the video length, but these are not its stronger features. Let’s break them down to four key points.

1. Creating Scenes and Sources

One can say that a screen recorder that captures the whole screen is enough for testing purposes, and that’s right. But remember: the point here is to be more productive as a tester, and that can be achieved by using different scenes and sources for the video input.

One of the pain points while testing on Windows, at least for me, was to conduct a guided test case without recording any of the test case documents (do you know that we are not supposed to do that, right?). Sometimes the test case was a little complex and required several sequential steps. Instead of using a second device only to open the test case document, I simply added another scene on OBS Studio and then selected Window Capture as the source. With the test case document in a secondary browser, I’m then able to continue testing while recording only the app in scope.

However, if the test required more than one window to be recorded (like testing simultaneously with two browsers), then I only needed to change the source to Display Capture. Usually, I keep two pre-settled scenes, each one with a different source, so I only need to switch between the scenes while testing. You may also notice that there are several other options of sources, but those two options already worked just fine for testing.

2. Setting up the video output

Knowing that the Tester Work website has a limit of 200MB per video, recording the screen with the convenient resolution can save you from a video editing task. OBS Studio has several settings that can be customized based on the user’s preferences. Setting the video format as .mp4 and the Recording Quality as High Quality, Medium File Size usually is enough for uploading on Tester Work.

You can also change the video resolution and bitrate, and even modify the name format of the video that is being recorded. That way your video is ready to be submitted as soon you finish the record.

3. It’s free

Did I already mention that? I think it is already clear at this point…

4. Using shortcuts 

This may sound a little bit perfectionist, but I just don’t like to record the screen and the first image we see is the screen recorder window. I know, that is not a problem at all, but having a clear recorder makes the job of the test cycle moderators easier. Imagine yourself with dozens of bugs to be reviewed, you would prefer to have records that go straight to the point. You know, less is more.

You can set up some shortcuts in OBS Studio for the functions that you use the most. The good thing is that they work even with the software in the background. What I do then is to set up some shortcuts to start, pause, resume and finish the recording. That way I can start my recordings directly on the app to be tested, simply by pressing the pre-defined shortcut.

I must also say that having a pause/resume function is pretty handy, especially when I forget any info of the test case document, such as an assigned account to log in. It also helps if anyone interrupts you during the test – if you have kids at home you know what I’m talking about. Of course, sometimes you will need to go from start to end without any pauses, but being able to pause the record is really helpful.

Screenshot: Lightshot

Some types of bugs do not require a whole screen record to be clearly reported. Take the Translation Feedbacks as an example: recording the whole flow is pointless if you only need to highlight a single word or sentence.

When I started testing and I encountered any of those bugs, I hitted Print Screen, opened any image editor, pasted the printed screen, edited it to highlight the bug, and only then I was able to submit it.

But, what if the image editor was embedded on the Print Screen function? That is the premise of Lightshot! And it does it well, you can run it even on low-end devices without noticing any impact on the overall performance. Spotted a bug? I only need to hit the Print Screen button and the Lightshot is activated. You have then to select the area, no need to crop the image afterwards. At this moment, two tool boxes will open.

The vertical tool box is meant for editing. You can add text boxes, arrows, lines and rectangles, or you freely draw them by hand with the pen tool. But do not expect a full design tool with layers, shades and magical wands – you can change the color and that’s all. It is enough to highlight any bug that you find along the way, though.

The horizontal tool box is used for saving. Here you may not only be able to copy the printed image with edits, but you can also save them in a local directory, share in social media, and even perform a reverse image search on Google. For testing, saving the image will be enough. If you prefer to go through the flow as fast as possible without long pauses, you may be interested in saving the images without edits and use a third party app to highlight the bug later.

OBS Studio and Lightshot are only two available tools to make us more productive as testers, not only to have more time to dedicate to bug hunting, but also to create reports with higher quality. There are several other tools that can be used, with additional features like mouse highlighter. If you have any remarks, let us know in the comment section below.

 

Happy testing you all!

Gustavo

Why it’s important to be a User first; then a Tester

 

In this blog post, I would like to share some of my experiences and bugs I found in various apps while I was simply using them for my personal interest.

YouTube Studio – Sorting
Recently; I was using the YouTube Studio app on my Android-based smartphone. In YouTube Studio, I was accessing various modules (not in any specific order), such as Dashboard, Videos, Playlists, Comments, Analytics, etc. While accessing the Videos section, I did use available sorting options such as Most recent, Most viewed. With Most viewed sorting options, I observed something strange. All Videos – Most viewed sorting wasn’t working appropriately.

 

I did try multiple things (clearing cache, clearing data, re-login) and was able to reproduce the Bug. Then I reported this Bug on YouTube Studio’s Twitter handle and Facebook page. They actually replied and asked if this issue was happening on other devices too, and they suggested that I reinstall the app. I did just that and after reinstalling the app, I was able to reproduce the Bug. Believe me, I was not testing this app, I was just using it, so I simply stumbled upon this bug without any intention of finding issues.

Below are a few more experiences from the past, where I found similar errors while using apps:

Facebook App – Synchronization
Facebook Mobile App (Android version – 137.0.0.24.91) and Web were not in sync.

Facebook App – Facebook Memories
After sharing the memory, No. of Years Ago value & original Album Date & Time were getting displayed incorrectly.

Facebook App – Post reaction count
Post reaction (Likes, emoticons such as “Haha”) count was getting displayed incorrectly

                             

 

There are more such examples with the applications I use daily, but I will conclude the list here.

In conclusion, as a Software Tester, finding and reporting Bugs is one of the crucial tasks; however, it makes more sense if a Tester can find and report the Bugs which an end-user doesn’t wish to see.
I agree none of the above Bugs were Critical or High in nature (for me as a User). But; as a User, I still don’t wish to see them happening.

In all the above cases, I was using (not testing) the respective apps. That’s why… Be a User first; then a Tester: as a Software Tester, think of using the Software (of course; in addition to Testing the Software).

What are your thoughts on this?

Working for Tester Work as a beginner

I’ve been working with Tester Work since the second half of September. First of all, surprisingly, there was a written “online interview” where I had to prove that I have the basic skills to start working with them. That seemed serious enough for me, and I thought that I must be in the right place. After the registration was done, I felt lucky that I could start to work as a tester. It was exciting and a little bit frightening at the same time. As an indie game developer, I know things about testing, however, the way of presenting bugs at Tester Work is slightly different than I was familiar with.

 

My first test…

The following day my first invitation has landed in my inbox. As I was busy, my registration was late, so I was put on the waiting list. That was the first lesson for me: check my emails on my phone as soon as they pop. There are a lot of other fellow testers who are waiting for the opportunity to work. No problem, I said to myself. I am going to attend the next one. A few days later I was faster!

I was able to join an exciting new functional test case execution test cycle. WOW! Not to mention, that I am not able to let you know any of the details, because of the NDA (Non-Disclosure Agreement). Yes, it’s the place where things are taken into serious consideration. But, if someone takes their business seriously, it’s not a problem to work with Tester Work. Sloppy work is out of scope!

Back to my first test. It was awesome. It took me a couple of hours to catch up with those, to know how things are going. Nevertheless, the team of Tester Work gave me all the support I needed as a beginner. Emails with links lead to a handful of information, like useful articles, to the ‘Test Case creation guide‘, or how to acquire crash logs on different devices and machines (e.g. Android, iOS, Windows, etc.).

 

About precision

One of the important things is to be precise and to follow the instructions of the ‘Test Specification document‘, accurately. It is fully detailed, as it contains the following information:

• overview
• short description of the app/program
• test prerequisites
• what and how to test + what NOT
• the SCOPE
• bug reporting instructions
• plus additional instructions
• and many more, depending on the test case

Do you think it is too much? Probably. But they need testers who are able to watch out for many things at the same time. Not to mention that they have to work also with inaccurate reports, which means no payout for those who are not able to keep up with the rules. During my first test, I have learned a lot! I also learned that some bugs are more valuable than others. Not only for the developers but for me as well. If you find more bugs that are in the scope, the payment you get is higher.

Being a tester is an interesting job to do, you will learn many types of programs, applications, systems, and so on. But be aware! Because it’s not about just running through and finishing your task in 5 minutes. You need time. You should be patient, and be precise. The job of a tester is to support the developers with the most relevant, and detailed information.

 

What else do you need so you can be a tester at Tester Work?

Apart from the devices, you should have some basic skills like knowing how to take screenshots and recordings. For example, if you have a smartphone that you can work with, you should learn how to get a crash report, and how to record it. Another thing is that you have to write clear and good-quality reports.

 

+TIP: if you are not a native English speaker, use Grammarly, an extension for Google Chrome (also works with Brave browser), so you will cause less headache for the person who double-checks the reported bugs, and of course for yourself because there will be no need of additional adjustments of your report.

 

The point is, you should check out all the information you were furnished by the Tester Work team, and just do your best. This is the way you can get a better ranking, which means more payment!

Tester Work: a must-read guide on best practices for beginners

 

We’ve all been there: the first test assignment is sent, after not being selected in several profile surveys. You read the whole Test Case document, you follow the instructions, you take your time for each step (it’s your first time, so you’re a bit nervous), and then… You find it! Your first bug! You take a screenshot. You replicate the bug in a dedicated screen record. You save the application’s log. You create the bug report and report it! And as you wait for the end of the Test Cycle, a moderator revises the bug report that you created earlier…

“Rejected – Poor quality report”!

If you already had this experience, I feel you, my fellow tester. And if you just landed on this article before your first testing assignment, know that you don’t need to go through this experience! I’m here to give you some tips that I wish someone had given me when I started testing.

 

In this article, you will find some valuable advice on how to conduct the testing execution, from sending an application of a Test Cycle, to reporting bugs. As a Brazilian tester with intermediate-advanced English skills, this article can be even more helpful if your English skills are a little bit rusty.

Without further ado, let’s start, shall we?

 

#01: Keep your profile updated!

Yeah, that’s kinda unnecessary to say, right? Even if you’re starting your testing adventures right now, I’m sure you understand that you need to keep your profile actualized. But let me break down the reasons why you need to always check your profile info:

First, the test invitations are sent based on your preferences, competencies, and devices. The majority of the Test Cycles can be executed in any model of phone, for example. But adding that new phone that you just bought also opens you to the possibilities of tests exclusively designed for that model or brand. Do not hesitate to add the devices of your relatives – but make sure they will allow you to use their device during testing… 

The second main reason to keep your profile updated is to check your notifications preferences. You don’t need to refresh your dashboard again and again and again to see if an invitation appears. Just make sure that you add your best email and enable the email notifications, and then that’s it!

As Tester Work is always growing and improving, new specifications and preferences can be added to your profile. Opening the settings menu once in a while and paying attention to the release notes is everything you need to do to be up-to-date. 

 

#02: Use Grammarly

Up to this point, I think you might have heard of Grammarly already. If not, this is a handy service that checks your text searching for orthographic and grammatical incoherences. It can be used both as a PC application and as a plugin in your preferred browser. It has a free tier that covers the main functionalities, but you can also benefit from a premium account to have access to more refined features. But don’t worry: for testing purposes, the free tier works just fine!

Even if you’re an English native speaker, Grammarly gets your back when it comes to typos. When submitting a bug report, the last thing you want is that another tester submits a similar report, and your bug ends up as a duplicate… Using an app to check your spelling helps you to save time without sacrificing the report’s quality.

 

#03: Do not go fancy, use simple terms

For the bug reports of thee, one shall not attempt to weave far-fetched considerations.

Just keep it simple, dude.

Use the words that work well in your day-to-day vocabulary. You may also have in mind to use straightforward sentences. The goal is to describe the user’s actions and the application’s response, so be as most objective as possible. Even in complicated Test Cases, your explanation and comments must be clear so that anyone can easily understand your point.

The best way I found to understand how I should write any sentence is by looking at the Test Case itself. I mean, the best way for someone to understand you is by talking the same way they do, right? So try to “speak the same language” as the client. Apply the same terms, the same abbreviations (when testing for Instagram, for example, it is usual to call this app simply by “IG”) that is contained in the Test Case documents. 

 

#04: Pay attention to the deadline and the requirements

This tip seems a little bit too obvious, but make sure to read the requirements and the deadline carefully. They contain crucial information for the test. For example, if you are assigned to conduct a Test Case execution with a 2G network, you can expect that it will take a little bit longer to finish the Test Case.

Paying attention to the deadline doesn’t mean that you need to know when the Test Cycle ends. There are some Test Cycles that require the user to take action after a couple of hours, so make sure to not leave all the work to the last moment.

Ah, and before I forget: the date format in the Test Case invitations is mm/dd/yyyy, and not dd/mm/yyyy. You might think you would never be mistaken, but anything can happen if you’re rushing with several Test Cycles – especially if this is your side job.  

 

#05: Talk to the Test Cycle moderators

Let’s imagine that you just skipped the last tip and you find yourself without enough time to finish the Test Cycle. Instead of giving up, give a shout-out to the Test Cycle moderators! They are always open to hearing your demands and helping you finish the work. You know, we all go through unforeseen issues, so do not fear asking for an extension in the deadline. You may be granted a couple more hours if it fits in the project’s schedule.

Feel free to contact them if you have any doubt. They are usually available to help you solve any technical issues which might be blocking you from testing. Remember that they have the same aim as you: to gather as much information as possible until the end of the Test Cycle. And they will do anything it is at hand to help you finish testing.

 

#06: Don’t ignore the Insights

Talking about gathering as much information as possible, some Test Cycles require more than only bug hunting. Test Case executions can have up to three types of reports.

First, we have the well-known Bugs. Isn’t something working as expected? Is there any graphical element not rendering properly? Fill in a bug report to describe the issue. Take your time to describe in detail what are the expected and actual behaviors of the application, and also describe the steps you need to take in order to reproduce the bug.

Sometimes everything is working just fine, but you find a word that was not properly translated or that is just misspelled. In that case, you may report it not as a Bug, but as Translation Feedback. You can then provide a more suitable translation for the given term. Make sure if your Test Cycle makes a distinction between Bugs and Translation Feedbacks, there are some Test Cycles where they are reported as the same type.

And then, finally, we have the Suggestions and Insights. This is not quite easy to make, and the majority of testers forget about it. But if you come across a product and you miss any feature that was not implemented, do not leave the Test Cycle without reporting it. 

 

#07: Read the whole Test Case spreadsheet before testing

In my first Test Cycles, I was so excited to start finding Bugs that I flew over the Test Case spreadsheet. Instead of earning a couple of bucks for the bug hunting, I lost some time with re-testing.

Reading the whole document helps to better understand the aiming of the Test Cycle. I also like to have a pretty clear idea of what is the next step I need to take during a guide Test Case. This helps me record a clear Test Case Execution while I save time for any exploratory testing.

Reading the whole documentation beforehand also allows me to identify possible issues which might block me from testing. I can then reach out to any moderator while I still have plenty of time for concluding the test. This is extremely important, especially for Test Cycles during the weekends.

=========================

 

Well, these were my 7 tips for best practices during testing. Hope this will be helpful for you anyhow! If not, if there is anything you disagree with or that you would like to add up, feel free to comment down here! Let’s use this space to exchange information on how to become a better tester.

Happy testing, you all!
Gustavo

Get Paid to Test Apps and Websites: A Step-by-Step Guide to Getting Started with Tester Work

If you want to make money doing QA testing, Tester Work will pay you for it. Based on my experience as a tester at Tester Work, I’ll show you how to get started in this post.

Working-from-home job seekers should consider QA testing. Tester Work is an excellent opportunity for freelancers and QA enthusiasts to work part-time and earn money while testing applications and websites.

testerwork.com enables people from all around the globe to work from home on their own time. Do you have a question regarding how to get started with Tester Work, the world’s most trustworthy software testing platform? Allow me to lead you through the process step by step.

The following is an overview of everything you need to know to get started properly:

• What exactly is Tester Work?
• How does it work?
• How can I become a tester at Tester Work?

What exactly is Tester Work?

testerwork.com is a global software testing platform that pays freelancers to test applications and websites. The organization seeks motivated QA testers with web and mobile expertise. You will get paid to test applications and websites if you are eligible.

The platform has a global network of over 50,000 testers. You can make money by testing websites and applications in your spare time.

It is seeking testers from all across the world. It enables workers to work from home or anywhere they like, and most crucially, in their spare time.

Some people work full-time, but the majority work as part-time QA testers at Tester Work.

All jobs are flexible but bear in mind that each project has a set start and finish date.

How does it work?

To start making money, simply follow three simple actions.

• Register. Make a profile.
  It is completely free to join. You must share the devices you own. After that, you must complete a brief online QA test.
• Testing Apps and Websites
  If you pass the brief exam, you will receive a confirmation mail from Tester Work within the following three working days and will begin receiving invites to new testing projects when available.
• Get paid for testing
  You will earn money if you report bugs or complete test cases. You will be testing applications from major tech giants like Microsoft, Evernote, Facebook, Kano, Spotify, and many others.
  The payout for every bug reported will depend on bug severity and your rank.
  Normally, you will begin with the bronze rank, and the payout for this rank is 1x, while the payout for the elite is 2x, implying that someone with the gold rank will be paid 2x more than someone with the bronze rank. The rank is updated every day, based on your activity on the platform.
  Every time you get notified about a new available test case, you will see the amount to be paid after the task, and the amount will depend on the job. After you report a bug or complete a test case, you will get paid in the next 2 weeks. The amount will be credited to your balance and can be withdrawn via your PayPal account or Upwork account. 

How to become a tester at Tester Work?

Simply click the sign-up button in the upper right-hand corner and fill out the form.

In order to be hired as a tester, there is an online test that you must pass. It takes about 15 minutes.

If you fail the initial examination, you will be offered another opportunity to complete a follow-up evaluation.

If you pass, you may begin testing as soon as you receive an email announcing a new project.

In conclusion

• Tester Work is a legitimate website that will pay you to test websites and apps.
• Tester Work is the easiest, most straightforward way for testers, QA enthusiasts, and freelancers around the world to earn money by testing apps and websites.
• Tester Work is an excellent site to make money in your free time and work from home.

Check the timezone 

Don’t be disappointed if it looks like we’ve sent you the invite after the start of the project! It may seem so, but keep in mind that the timelines mentioned in our e-mails are for the UTC+2 timezone.

This means that 11 AM in the invite might actually be 3 PM in your location!

Read all details

Better and more complete bug reports trigger higher ranking, which in turn makes for more project invites and better payment.

Read the tester specs in each cycle carefully – you’ll find there everything that’s in scope and what’s not in scope, what you should focus on and a reminder on how to write great reports.

1. Duplicate reports

This may seem obvious at first but it is still a mistake made often. In fact, this rejection reason occurs twice as often as any other.

When reporting an issue, if the same issue has already been reported, it will not be considered valid.  

Here are some steps you can take to ensure the issue your report will not get rejected:

• Read the tester spec carefully. There are certain types of issues that are considered duplicates as long as the method of causing the issue to occur is identical, even if they occur in different areas of the application. If you find behavior that has already been reported, it is best to comment on an already reported issue and mention any other areas where this occurs, even if the issue does not belong to you.
• Check the issues reported on the cycle. Hop into the tracker and see which issues were already reported. Many of the issues encountered will generally occur on multiple devices. The easier it is to find and replicate the issue, the higher the chance this was already discovered and reported. Note that rushing is not ideal, not only will your issue be rejected, but you will have spent time reporting an invalid issue which could have otherwise been spent checking for other issues.

2. “Not an issue”

An issue marked with this status usually reflects an improperly described bug, which causes misunderstandings during moderation.

Three simple steps to avoid having your issue rejected:

• Report the issue clearly and provide all the necessary information. While it is important to keep bug reports short and concise, make sure you always provide enough information. The more detail the Test Managers have, the less likely your issue will be rejected. 
• Understand the application. Before you begin testing make sure you understand the application you are testing. Context is extremely important for certain features. What may seem like a bug in one application, might be understandable in another.
• Avoid repetitive or vague descriptions. Using language such as “This behavior happens” or ”This behavior shouldn’t happen” isn’t constructive and needs to be avoided. Instead, explain why the behavior shouldn’t occur or suggest how it should behave.

3. “Not in scope”

While you may be testing the same app during multiple cycles, the scope and focus of the test can change.

The scope refers to what the general purpose of the cycle is.

Meanwhile, the focus, zones in on a particular feature or update that may have undergone recent updates and can potentially be unstable as a result.

What are the correct steps to follow?

• Check the focus and scope of the test. Check the Tester Spec to see which areas are in scope for testing and what the focus of the test is. If the issue does not match the scope and focus, even if it is valid, it will be rejected.
• Check if any areas or flows are not to be tested. This is the same as above but needs to be emphasized. Sometimes the spec will mention a specific aspect that should not be tested.

As an example, the Test Spec may have the entire application in scope but will request that you do not test the payment/subscription section. This means that, while you may report any issues you encounter, these should not be related to that specific section or flow.

Note, that due to the high number of issues rejected because of this issue, the Not in scope rejection reason is also debated in the next article a little bit more details.

4. Poor Quality Report

This resolution focuses almost exclusively on the information provided or requested from the tester. If there is information or evidence required, this needs to be included. Sometimes a client specifically requests that something must be included in the report. If this is missing, the issue will be rejected.

Solutions:

• Read the tester spec. This makes us sound like a broken record, we know, but really, all the information you need in order to test will likely be in that document. Evidence does not refer simply to a video or a screenshot. You may be requested to provide a specific log or attachment, in addition to the video or screenshot. Other times you may be requested to add login-credentials, title tags, etc.
• Provide the right evidence for the right situation. Often times we see testers provide screenshots for dynamic issues. This is wrong. If an issue needs to be observed in action to be understood, a video needs to be provided. A flickering screen? Stuck in a loading loop? Application crashes? A button doesn’t work? Provide video evidence. Screenshots are intended for static behaviors that do not require user input to trigger. Some examples include text typos, overlapping* or misaligned images, etc.

*Note that a static issue will require a video if the user needs to force the behavior to occur. For example, if a text field starts overlapping another field only when the user taps on it, it is no longer a static behavior.

• Make sure the report is clear and easy to understand. Sometimes the report is simply poorly written and is misunderstood. Ensure the sentences make sense, are written in proper English and can be easy to follow. If the description of the issue is too complicated or not clear enough, it can be misunderstood for another issue, or it simply cannot be reproduced. 

Let’s start by addressing the need for such a system in the first place.

Firstly, severity is defined as the extent to which a particular defect could create an impact on the application or system. This simply means that some bugs create a lot more problems than others and need to be given a higher priority when solving them. In the fast pace world of Software Development, time constraints and resource availability dictate that certain issues get a certain amount of attention. That’s why a grading scale needs to be implemented in order to maximize efficiency when solving bugs in the code.

The difference in severity can be easily understood when comparing a minor display issue like a spill or an overlap to something critical like a crash, but oftentimes that line can be blurry when comparing similar bugs with almost identical causes or effects.

Therefore, we hope this guide will help you understand the way we moderate bugs and set the correct Severity for yourself thus avoiding the correction penalty.

You can check out more information here in our comprehensive guide or in our YouTube video below!

This guide forms an essential part of our help centre and is the go-to place for any queries or questions that you may have about bug reporting or testing with us here at Tester Work!

Check it out, try out some of the quizzes to test your knowledge, and be sure to let us know if there is anything that we have missed!

2. Test Case Execution – Legacy

Test case execution is the process of performing a set of flows using specific instructions and comparing the results observed with the expected/intended results provided by our team. The goal is to make sure that everything works as implied in the test case suite on your selected environment.

The most valuable aspect of the legacy test case executions is the ongoing communication with the Tester Work team in charge of that execution.

Starting with the moment you receive the test case execution invitation, you’ll be able to message the team and ask for help and clarification related to your execution. The team is instructed to help you throughout the duration of the test to ensure you’re not blocked in executing the test cases. The communication aspect, along with the detailed instructions, aims to provide a smooth testing experience leading to quality results.

Here’s a rundown of the most important aspects of this type of testing:

1. The email invitation to the test case execution includes testing time frames, selected environment (Device/OS), and payment for completing the test;
2. In order to ensure a smooth experience, we recommend replying to our invitation as soon as possible letting the team know whether you are available for the test;
3. It’s important to read all of the testing instructions and to clarify any unclear aspects ahead of time, in order to meet the agreed deadlines;
4. If the behavior encountered in the app doesn’t match the expected outcomes written in the test case suite, the affected test cases are “Failed” and relevant bug reports must be attached in the test case execution document;
5. The test case execution is considered complete once all of the test cases inside the selected suite have the appropriate status assigned to them.

3. Test Case Execution – Tester Work Platform

While this type of project follows essentially the same flow as the legacy one, in this case, the process is automated through our platform and will be performed in our test runner without any interaction over emails with our team. The focus here is on the status of the test case, pass or fail.

The test cases are designed in such a way that you’ll be able to execute each instruction in a given time frame and you won’t have to check any third party documents for executing them.  It’s important to keep in mind that the notes and visual proof of the issues encountered while testing need to be relevant to the instructions provided, in order to ensure the success of an execution.

The two most important aspects of testing via the test runner are attention to detail and speed! The test case instructions need to be followed thoroughly in order to avoid flagging non-issues caused by misunderstanding the steps, while also keeping an eye on the clock to ensure you have enough time left to correctly go through the presented instructions.

Here are some fundamental principles of testing via the test runner:

1. The Tester Work profile includes notifications about upcoming and ongoing tests
2. Successful tests are the ones where the instructions have been thoroughly followed
3. Being aware of the time left to execute a set of instructions allows stress-free testing
4. The desired outcome of a test case execution is having all of the relevant notes and proof for the issues encountered during that execution.