Test, get tested, and stay safe

My testing experience at forty-two has been interesting, to say the least. When I first started testing, I did it for the money. Today, I do it for the fun. It’s like a puzzle, looking for what’s what and what shouldn’t be and all that. In between then and now, there’s been good, bad, and neither-good-nor-bad days. This blog shares how I deliberately refused to allow my health to be affected while testing during the pandemic and especially the lockdown.

 

Did anyone notice that during the lockdowns, there was a barrage of test invites? COVID threw everyone into panic mode. And we panicked. Anyways, the torrent of test invites was mind-blowing. My devices were beeping all the time and with very little to do, it became natural to go to one of my most favorite things – testing. Little did I know that everyone seemed to be locked on to this too.

After accepting several test invites, I had to keep up. You know, trying to log issues before anyone else – that rush was addictive. Some tests were basically easy to comprehend and some test scripts needed zero distraction. And, some test overviews, you’d wonder if the Test Manager wrote it standing up. Well, what do you know, once I accept an invite I’m always committed to completing the test, even if sometimes I had to translate the test into my native language, juxtapose versus what the Test Manager is trying to achieve. Mind you, each test has its specific area, however, if you’ve tested several apps and websites, it’s almost impossible not to know what the general or specific areas of testing would be.

So back to my accepting several tests. I realized that most of my issues were logged and approved but I was clocking at least several hours of work every day. Most times I test on my bed. For days, my bed wasn’t laid and shower-time was either short or non-existent. If you add on top of that correspondence with the team, taking into consideration the difference in time-zone, you have a cocktail of you being awake for more than 32 hours sometimes, testing!

Then I checked my BP. It was over the healthy limits. Don’t forget that we were in lockdown- no walks/jogging, not enough physical activity, or fresh air. Even if it was allowed, I wouldn’t because I was scared stiff of the coronavirus. When I realized my blood pressure was tilting past the normal ranges, I had to pause and check what I was doing wrong. Without looking into a crystal ball, it was obvious. So I did the first and immediate responsible thing: I SLEPT.

I chose to give up tests that I couldn’t finish on time, given that I had now accepted the ‘sleep’ invite. Then, for the logged issues, I left the acceptance/rejection to fate; choosing fate over worry – approved test cases and issues is a better ranking and more money but then I preferred life. Thirdly, I silenced the alerts on my device – no interruptions during my newly accepted invite (sleep). When I had gathered about two straight days of sleep (and ignoring worries, alerts, and invites), I designed a new system of accepting invites: No more than 3 test acceptances per day. No more than 30 issues in a day. No more than 10 hours of testing. No less than 8hrs of sleep (every day)! This deliberate stance over two months period sent my health numbers back to normal. And so it has remained – both Tests and Tester.

Today, there aren’t that barrage of test invites like during the lockdowns but this one Tester is currently happier and would be testing in better health. There’s no gain in losing one’s good health and having a stash of cash. That’s my admonition. So, fellow testers, I hope this brings some feel-good sunshine into your day (or night) as you read.

Happy Testing, folks.
Olufemi

Bugs galore

Introduction: Despite extensive testing happening for software products, defects still pop and are seen by the end-users. If these were cosmetic defects, like spell errors or tiny defects, they would be tolerated. But when these are functional defects that are customer-facing, it is a cause of concern. These are the areas in which crowd testing can assist the community and the improvement of the software product by offering multiple hands to test with reasonable resources invested.

Here are a few real-world instances that I observed recently:

1. An investment arm of a banking organization incorrectly popping up spouse gender as “Male” instead of “Female”.
2. Video verification for Bank account opening KYC, failing multiple times due to browser and device compatibility issues, right at the time of getting introduced to the customer, leading to customer frustration.
3. In a stock trading application, the amount of monthly SIP being accepted is lower than the unit stock price, without any error message being prompted.
4. As a stock trading customer on a trading website, I was unable to locate the key functional requirements with ease.
5. Repeated SMS messages received for the same activity done by a customer.
6. Multiple SMS messages received with different content for the same activity done by a customer.
7. Not to mention all the spell errors noticed on the website of even well-established organizations.

All these are leading to a subject called Defect/Bug acceptance criteria, where bugs in software are acceptable to an extent by the end-user, acknowledging the fast-changing software application landscape and rapid evolution of software at the speed of a mobile button click.

 

Why are these defects occurring despite continuous testing?

Use case 1 – The integration between the Banking software and the Investment software was not tested efficiently.

Use case 2 – Browser compatibility and device compatibility were not verified to the extent required. The mobile app was given more priority than the identical website during the testing process when multiple service delivery channels were used.

Use case 3 – Field level validations were not performed, meaning an alert/error message was to be provided for the amount lesser the average stock price current market price to the investor in order to avoid such circumstances.

Use case 4 – The software was built without taking all the considerations of ease of App Learnability for the end-user.

Use case 5 – Frequent changes to the application even after UAT are performed in order to accommodate the product owner requirements.

All these and many more point towards the lack of extensive testing of the software and especially the continuous changes done to the software.

 

How can these be prevented :

Crowdsourced testing provides one of the effective solutions for preventing these defects:

1. The number of tests can be repeated across multiple browsers within a limited time frame.
2. The number of tests can be repeated across multiple devices, legacy and new, within a limited time frame.
3. Enables new pairs of hands and eyes every time the tests are run and are regressed.
4. Business-oriented testers may be a part of the crowd and hence business domain-centric tests can be executed efficiently.
5. Channel-based integration tests were accorded lower priority and hence missed out later, which could have been solved by using more testers from a crowd testing platform.
6. Extensive regression testing can be achieved by using a crowd testing platform for frequent software modifications and new feature enhancements and impact areas.

The bugs galore provide ample opportunity to crowd testers, but extensive testing prevents bugs from being rolled into production without adequate testing. Happy testing!

My love for testing!
and
I’m here, back again

I began testing as a hobby a few years ago, some of the projects I tested on were video games, PC games, mobile games, console games, and much more exciting ones. I love playing games a lot, so I started my career as a game tester. Also, finding bugs motivated me. This is where my true love for testing was established.

I started my journey with Tester Work in 2018. Well, those were happier days compared to 2020 and 2021 (the COVID time). I worked on various functional exploratory test cycles, all the cool features and enjoyed it a lot. Then a lot happened like a tornado in my life and I stopped working with Tester Work in 2019. Now the love for testing brought me back again in 2021.

Sometimes I wonder who I am, an accidental tester? Or was it a deliberate choice?

What I love about Tester Work was getting involved with them not only to earn money but follow my passion, also to learn, as well as get feedback on my bugs as a way to validate some of my thoughts and ideas!
Sometimes the bugs fool you, sometimes the words and new functionalities can go all spinning around your head. Staying on top of yourself, helping customers get a product that they love, will give you a nice experience. Testing allows me to ask questions and apply the skills I’ve developed, which has been a major part of my success.

How cool is testing for me? I made a list of reasons for which I love it:

Because It Challenges Me…?? Every project provides different features and its testing problems, there is never a straightforward, “one size fits all” solution – this approach is completely wrong. Looking at software from various angles, with different perspectives, and testing it with different expectations is what I like best.

Because It is sooo… satisfying… I mean yes, resolving issues feels like doing a puzzle, completely frustrating but completely amazing when you find the correct piece! Finding, tracking bugs, improving ideas, improvement of the product, solving issues, and perfecting methodologies – being able to do all this stuff in Software Testing makes it the most satisfying job.

Because It is Complex…Am I Kidding? Yes, but sometimes working on complex tasks makes me be thrilled all the time. The biggest challenges are when a lot of devices are available and checking the application’s behavior gets weird in terms of response time and usability.

Because We can Critique… Judging other work, not by being mean, but I’m having fun, almost like in giving reviews to a person who cooks food for me. Usually, even when someone pronounces a word wrong, I love correcting them. Well, with a healthy attitude, that is. When I find small faults in others’ work, I just tell them, similarly with software testing, it’s my job to see if everything is fine and I have to do it as best as I can. The tester’s mindset is different from the developer’s mindset, testers are folks that like to find problems, they have a different personality.

Because It is all about Understanding the user , putting yourself in someone’s shoes and simply understanding their perspective. Knowing the market and understanding the latest trends, what the customer wants, providing relevant information, ultimately who else can think like the User and work on the product.

Miscellaneous Reasons: testers are generally fun, ego-free, and honest folks who are great to know and hang out with. The profession attracts the type of people I like to be around.
I love getting early access, experiencing the early versions of software while it is still secret.

I love being a software tester, but I’m still not sharing all the reasons, let’s keep it our little secret. Maybe there are other reasons why you like this job too.

Because the managers can stress about schedules, the developers can stress about adding more things and fixing bugs, while Software Testers sit in a sweet spot of flexibility where we can play, learn, live on the cutting edge of technology, and work with generally interesting and nice people.

Oh, and the salaries aren’t that bad either! And you can freelance too.

Anyway, I’m back again to show my love for testing!
Karishma

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?

How to assess a bug’s risk

 

Finding bugs is an art. It’s the art of minimizing risk.

In some applications, the impact of critical bugs can result in loss of life, for example in healthcare, where an incorrect procedure on the wrong patient might mean physical death. In other applications, like banking, the existence of a critical bug might mean serious financial losses. Luckily, the bugs in most applications don’t result in such drastic losses. The riskiest impact of bugs in most software is the loss of reputation.

When you encounter a bug in software, it either stops you from achieving your goal, leaving you no option but to abandon the software and find an alternative. Or if there are non-critical bugs, the software is perceived as unprofessional, leaving the user doubting the capability of the organization behind the software to do what it is intended to do and to be trusted.

With so many options available for any one function you possibly would want to do, there is little incentive for a user to continue to struggle through errors in an attempt to complete a goal. It’s much easier to find an alternative without the bugs.
Finding bugs is thus no longer only crucial for risky software like healthcare, banking, or insurance products, but essential for any product to stand out and grow in a saturated market filled with options.

But how do you decide which bugs are critical and which are not? It’s not as easy as providing a checklist, as a spelling error in one application might be critical and in others considered trivial.

One of the most famous examples of how a spelling error resulted in an $18.5 million cost can be found in a spelling mistake in the Nasa software: on 22 July 1962, Nasa launched the spacecraft Mariner 1. A mere five minutes after lift-off, however, the mission was aborted and the spacecraft destroyed. Surely one of the most expensive failures in history, caused by a single missing hyphen in the code.
In most cases, however, a spelling error will probably have no impact on the users and most people might not even notice it. And if someone does, the biggest impact is that you might become the laughing stock of the public for a short period of time.

The key is thus to understand the impact of the error: what might be the consequence of leaving the bug in the software? To help you decide how risky the software is, ask yourself these questions before you log a bug next time:

1. Would there be a security impact? If the bug was encountered in production, would it be possible to stop someone from accessing assets they should be able to access? Or could an unauthorized person access it more easily?
2. Might there be a financial impact in either the form of a loss or a gain as a result of the bug? A simple calculation error might, for example, result in thousands of losses or gains as a result.
3. What about the reputational impact? What would people say and how would they behave if the error was left in the code?
   Would there be any impact on the ability to provide a service as a result of the bug? Does the existence of the bug stop someone from getting or providing the service customers expect?
4. Finally, is there an impact on any resources as a result of the bug? Would it cost more to do the same task? Would it take more time to achieve the same goal? Or would you need more people to do the same job as a result of the error?

When there is a substantial impact in any of these areas, it will very likely be considered a critical bug. Although the ideal is to have perfect software, the cost of fixing a trivial bug with a small impact far outweighs the cost of leaving it in the software.
Fixing, for example, a trivial bug of correcting a non-critical spelling error will result in the cost of the tester who reported the bug, the cost of the test manager reviewing the bug, the cost of the development team who needs to implement it in the code, and again the cost of another test cycle once the bug has been fixed. Compare this to the benefit and it is simply not worth the effort and cost.

So next time before you log a trivial bug, ask yourself these questions and evaluate whether the risk of leaving the bug in the software might outweigh the benefit and cost of fixing it. Not only will you get paid more for logging better bugs, but your tester rank will also go up, improving your chances of being selected for the next test cycle.

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.

Aishwarya – Qa Tester

1. Who are you?

I’m Aishwarya V, from New Delhi, India, presently residing in Bangalore, India for my education purposes. I am pursuing my third year of engineering in Information Technology. I’ve been a freelance tester for about more than 5 years, a Test Team Lead for a few months, and now promoted to being a Test Engineer. I also achieved a gold rating in this field last year. I work for various Fortune 500 companies and give out usability suggestions for developing their websites.

My hobbies include cooking, dancing, singing, and reading.

2. How did you start your career as a tester and how is it to be a freelancer in this field?

I was in my 10th grade when my sister signed up as a freelance tester with many websites. Later, she moved away from it but I picked up the flow and started learning about testing. Since there was no one to guide me, I had to start everything from scratch and learned about software testing, automation testing, agile testing, API testing with the help of Google and other resources available on the internet.

Being a software tester feels amazing. The happiness when you find a bug or your reported issues get approved is something next level. I have learned a lot of things in my 5 years of testing journey. Initially, it was tough but I did it. 

3. Do you recommend testing as a full-time job or a side source of revenue?

I have lots of friends who are full-time freelancers and earn enough, sometimes even more than what the IT industry could offer as a full-time employee. 

It totally depends on your skills, your experience, and your determination to work in the freelancing field. It isn’t easy but it isn’t tough either If you are earning enough from your primary job, you can consider freelancing for a side income. 

4. Can you do freelance testing and have a full-time job at the same time?

I am a third-year student pursuing my engineering in the IT field. I manage my studies as well as my work. I have lots of friends who work full time in companies and work as a freelance tester during their free time. They utilize weekends, holidays to earn an extra income. Instead of spending time on social media, they prefer testing. 

5. How is it to work with a team you don’t know in person?

I am an extrovert and can initiate a conversation with anyone, anywhere! I can’t deny that yes, it feels a little difficult initially to understand a person especially one who is from another region and speaks a different language. But we all should remember that after all, they are human beings and they are testers too and we all are like-minded people. 

Once we start exchanging our views or knowledge in testing, we become a family! 

6. What advice would you give a tester who wants to start their freelance journey?

Initially, it will be very difficult and you’ll earn very little. But once you get a hang of it and spend more time, you’ll start earning. I always say that if we focus on learning and gaining knowledge, earnings will automatically come to you. Even if you face rejections or if you don’t find a bug in a project, do not give up. Just give your best in every project!

There are many people out there who don’t know about freelance testing or leave the job before they even try. Initially, it is difficult I agree. But once you get experience in this field, no one can stop you from excelling! Prepare a list of goals and work towards it and don’t stop until you achieve it.

At times, people start working overtime which is also not good. You will earn a lot during this time but in the longer run, it’ll adversely affect your health. Spend time with your family and take frequent breaks. Only accept work and projects if you are ready to work on them. Don’t overburden yourself. Meditate. Breathe. Have confidence and give your best! 

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.