Hard work pays off.
Hm… Usually. Ocassicanally. In the long-term perspective?
But not always in the crowd. Here are just some of the cases where I was totally smashed by the crowd machine. Obviously, it’s all confidential.
No face, no name, no number
🚫 No platform, no client, no cycle
Just cold facts.
How could you not hate the crowd after this?
Fails, fails and more fails…
❌ Case A – Fair/Unfair
Context: I am really pressed as later in the evening I am heading for a short trip to the neighbor country.
I receive the invitation – usability testing for a website of one of the major European airlines. How could I decline this one? I just can’t resist UX cycles as I am really passionate about the subject.
Hence instead of packing for the trip, I start testing and complete the tasks according to all requirements. Later I discover that my reports are rejected as not meeting the quality standards. And I am like – “What?”
I am a quality-obsessed geek, how on earth could that happen?
As it appears the only problem is that I haven’t copy pasted the exact report title. Yeah, just think about that. I’ve written the title myself, so as a result, it had slightly different words order.
Let’s say if the expected format would be: “UX testing for A/B version – Section XYZ”, mine would be – “Section XYZ – UX report for A/B version”.
Wow, such a crucial difference.
The worst part is that I was not even given a chance to correct the title. It would literally take me 2 seconds. But don’t you try to argue. Have the report rejected and your time wasted.
Conclusion: Being treated like dirt is very eye-opening. At the same time, there is no point in saying it’s unfair. Committing into any crowd cycles implies certain odds of such things happening. If you are not ok with it, the concept is not for you. No complaints, only lessons learned.
❌ Case B – All the time and energy waste
Context: The product in test is a website of one of the global automobile brands.
The requirements look very straightforward and the flow seems easy. Just one minor problem on my side, the requested feature to be tested is not available for me.
Oh, the things that I’ve tried – switching devices, registering accounts in different countries, using the account borrowed by a fellow tester. Nothing. After 2 hours of “what the heck is going on” I finally get it. The environment in question is very complex (there are a lot of branches and countries available). Thus, users are automatically redirected to the corresponding store based on their location. Finally, I am able to access the correct configuration (using VPN and registering a new account in one specific country).
❗ No mention of this little nuance anywhere in the test cycle documentation or chat.
Anyway, having solved this issue, I get to work and log 10 reports (which is more than all other testers’ suggestions combined). Just when I think that I am done with this time-consuming cycle, I receive the lucky news – none of my reports gets accepted. Further info is requested. Hence, I go ahead and try to justify every single report, despite the fact that I’ve based my suggestions on standard usability guidelines. Any further communication with TL leads nowhere. In the end, each and every report is rejected.
⌚ 8 hours of active productive efforts (including the time spent on the environment troubleshooting, testing, reporting, and communication) traded for nothing. Bummer, to say the least.
Conclusion: Ok, so you do feel horrible in such situations, no way to spin that. You may blame it on bad luck or whatever – it won’t change anything.
Sometimes you outsmart the system and sometimes it screws you over. In general, who wins, who loses, are you equal? You decide.
Wow, this is getting wordy enough. I will shorten the narrative. You’ll figure out on your own the conclusion part for each case.
❌ Case C – The killer formalism
The task is to validate some typical user stories. A slight problem occurs. The video size of the screen recorder is too big to fit into the limit imposed by the platform. The easiest workaround I can think of – uploading screencasts to the external file sharing service. Nope, not getting accepted like this. So I spent two hours trying to figure out how to reduce in size the videos without losing the quality. In this end, they get rejected anyway as not meeting the requirements.
❌ Case D – Not a nice surprise
My problem is that I care way too much about the quality of my work, even if it’s not really needed. I’ve spent some extra time investigating the defect. At the moment I log it I realize that the bug payout has dropped to 50 cents.
Just a quick remarque. There is no shame in working for free as then you are guided by some kind of intrinsic motivation. But working low cost… Have respect for yourself. Your mental energy resource is not limitless.
❌ Case E – Who are you to make mistakes
At 7 a.m I am up and testing a website of one of the popular online courses platform. The staging environment isn’t set up properly. At one point, I get redirected to the live environment, because of the incorrect link set-up in one category. Haven’t noticed until logged the defects. Rejected.
❌ Case F – Dull “Bugs to be reproduced” policy
One particular condition for this crowd cycle. Every bug has to be reproduced by at least one tester. So you go ahead and test, discover the legit defects. It seems like you’ve made your part of the work, all should be fine now.
Ha. Eventually, the defects are rejected only because no one bothered to reproduce them.
❌ Case G – Not fast enough
You start testing 10 minutes after the cycle has started. Discover a defect, fill in a report. Oops, it shows up in the list already. Someone is faster than you.
Another defect. Damn! it’s already among the known defects.
One more. This one is good. Don’t you dare to waste any time. Shut.
No way. Another tester logged the same defect 30 seconds before. Delete your defect, as it will be rejected anyway.
❌ Case H – No defects found
Very common one. You test, test, test. But find no new defects. Because of the scope limit, because of the large known defects list, because the build is surprisingly stable. Whatever. But you are a loser, as this way you trade your time for nothing.
What do you think? Will I run out of the letters in the alphabet before I finish my fail list?
Let me assure you, I’ve got more than that. The point is not counting the things that went wrong. It’s all about what you learn from them.
What have I learned from all the fails in the crowd?
I came up with the following 3-A principle:
✔ Assume the responsibility for your choices ➖ don’t complain.
✔ Analyze your mistakes ➖ figure out what can you do better next time
✔ Accept what is beyond your control ➖ OR ➖ make changes to gain the control
Here is the brilliant quote that pretty much sums up everything:
Ever tried. Ever failed. No matter. Try again. Fail again. Fail better