DEV Community: Liviu Lupei

TestProject is closing down

Liviu Lupei — Mon, 21 Nov 2022 18:16:46 +0000

TestProject was a test automation tool developed in Israel.

What happened?

The official announcement came through a blog post.

TestProject launched in 2017 and it stood out by not offering a paid tier.

Unlike other next-gen test automation tools, it didn't offer any cross-browser cloud.

That meant their own cloud infrastructure bill was probably small.

But it also meant that the only option to run your tests was to use your localhost or to connect to a third party cross-browser cloud provider (BrowserStack, SauceLabs, etc).

That increased the complexity and affected the user experience.

What I liked about TestProject:

It was no-code/low-code, that means it helped democratize test automation, making it available to everyone
It worked for both Web Applications (websites) and Mobile Applications (Native and Hybrid)
They had a nice blog where anyone could post articles

What I didn't like about TestProject:

No cross-browser cloud, users had to get their own infrastructure
Lack of stability, users often complained about the downtimes

What are the alternatives?

Fortunately, there are plenty of next-gen test automation tools to choose from.

Our Endtest platform is one of them. To help get your automated testing back on track, we'll help you migrate your old TestProject tests. We're also offering a 20% discount to TestProject users that start using Endtest before TestProject's EOL.

A detailed comparison between Endtest and TestProject can be found here:
https://www.endtest.io/testproject-alternative

Why use a next-gen test automation tool?

In general, the purpose of innovation is to drive down the complexity and cost of doing things.

A next-gen test automation tool helps you create, execute and maintain complex tests, without breaking a sweat.

The days when your team had to stitch together your own Selenium/Cypress framework are long behind us.

Version 💯 of Chrome, Edge, and Firefox may break your website

Liviu Lupei — Mon, 21 Feb 2022 09:53:06 +0000

Chrome, Microsoft Edge and Firefox are all getting closer to the release of their 100th version.

This may look like a nice round number, but it might introduce bugs or create compatibility issues for your website.

We've seen similar situations, such as the Y2K bug and Microsoft skipping Windows 9.

1. How exactly?

This particular situation is related to how websites read user-agent (UA) strings to identify your web browser.

When you visit a webpage on a website, your browser sends a request to that page that includes a user agent string that looks something like this:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.36

Mozilla already ran some experiments in August 2021 to test if three-digit version numbers would break some websites, and found that a number of websites did not work properly.

Examples include Slack, Yahoo, Bethesda, HBO GO, and more.

2. It's not just your own code

Think about all those 3rd party libraries your website is currently using.

Each one has its own way of checking the browser version.

3. How to prevent this?

As always, testing is the only way to know that a website works as expected.

Chrome 100 will be released on March 29 and Firefox 100 will land on May 3, but you don't have to wait until then.

You'll be able to test your website on these browser versions while they're in beta, by using Endtest.

Right now, you can already run your automated tests on Chrome Beta v99, Edge Beta v99 and Firefox Beta v98.

If you want to learn more about that platform, I recorded a video tutorial:

What Happens When You Don't Test in Safari

Liviu Lupei — Tue, 15 Feb 2022 09:11:22 +0000

I decided to write about a major bug I recently encountered in our platform.

In Endtest, there is a section where users can view the test execution logs:

It's a critical component, and that's where it occurred.

1. The Bug

We recently made a change to improve the timestamps.

In our database, we store all the timestamps in UTC time zone, in a basic format:

2022-02-10 07:31:15

And we wanted to display the timestamps in a more friendly way, while also converting them to the time zone of the user:

February 10, 2022, 14:31:15

This was being done in the frontend, with some vanilla JavaScript.

It worked great in Chrome, Edge and Firefox, but not in Safari:

2. The Fix

The issue was coming from this line:

unixTimestamp = new Date(the_timestamp).getTime() / 1000 - (diff*60);

As you can see, it's a really basic one, nothing fancy or risky.

Turns out Safari has an issue with spaces in timestamps, and the solution is to replace each space with a T, like this:

the_timestamp = the_timestamp.replace(' ', 'T');

3. The Lesson

No unit or Jest test could have captured this issue.

The only way to detect such an issue is to run functional tests in Safari.

This shows us that a browser is more than just a JavaScript interpreter.

And that cross-browser testing is more relevant than ever.

4. The rise of Safari

More and more folks are using Safari, they're loving the privacy-focused aspect of it.

Not testing on Safari means that you might be ignoring 20% of your users.

I'm also using it, but only on my phone. Chrome is still my desktop browser.

5. The Democratization of Automated Testing

We've always advocated for testing in multiple browsers, that's why Safari was always an option in our platform:

By providing browsers in the cloud, anyone can run tests on Safari, regardless of what operating system they're using.

And by proving a low-code interface, anyone can create automated tests in a few minutes, even without writing code.

The Test Automation space has always had its fair share of gatekeepers, and we're getting them out of the way.

6. What about you?

Are you running your functional tests in Safari?

What percentage of your users are on Safari?

Did you ever find bugs that occurred only in Safari?

How To Deceive a CAPTCHA

Liviu Lupei — Thu, 20 Jan 2022 12:54:07 +0000

I'm Liviu, a Solutions Architect at Endtest.

Let's take a look at how we can deceive a CAPTCHA.

This is useful in a test or in any script that wants to imitate a real user.

1. What is a CAPTCHA?

In case there's someone out there who doesn't know:

A CAPTCHA (an acronym for "Completely Automated Public Turing test to tell Computers and Humans Apart") is a type of challenge–response test used in computing to determine whether the user is human.

It's meant to stop bots and scripts from pretending to be real humans on the internet.

2. Why do we need to deceive it?

Our use case here is for an automated test.

The typical workaround is to use whitelisting, and skip the CAPTCHA for requests coming from certain IP addresses.

But that workaround does not verify if the CAPTCHA works and if your real users can actually sign up.

What if the CAPTCHA system that you're using is broken?

Your tests would pass, but your real users would get stuck.

3. The solution

We need to extract the text from that image.

And the best way to do that is with Optical Character Recognition (OCR).

If you're looking to invest time in that and maybe even build a product around OCR, it's worth exploring the Tesseract OCR package from Google.

There are also different wrappers around this package, such as pytesseract for Python.

But it's not that smooth, the process involves a number of steps:

Align the image correctly.
Convert the image to grayscale.
Increase the sharpeness of the image.
Increase or decrease the DPI.
Configure a tolerance.
Extract the text.
Remove or convert incorrect characters.

If you're doing that only for an automated test, you can just use the OCR feature from Endtest:

And when you run the test, it will easily extract that text:

Here's the video recording from that test execution:

This tutorial should only be used for the websites you're testing, and not to scrape other websites.

What is the "no code" / "low code" movement?

Liviu Lupei — Tue, 11 Jan 2022 16:44:04 +0000

I'm Liviu, a Solutions Architect at Endtest

Let's take a look at this whole "no code" / "low code" movement.

Is this the next big thing? 🤔

Even UIPath, the juggernaut of RPA, has released UIPath Apps, a low-code app builder.

Microsoft also launched Microsoft Power Apps.

And who hasn't heard of Zapier?

But you've probably met at least one "no code" skeptic:

1. The Democratization

Democratization empowers individuals.

This movement is helping non-technical founders launch internet companies.

It's no longer a privilege only for those who have vast financial resources or the opportunity to learn programming.

How are we even supposed to call someone who uses Google Sheets and Trello to build an app?

Can we call them Developers? I don't know, maybe.

But we seem to be reaching a point where we don't need to hire a Developer for every web project that we want to build.

By the way, there's a website called Makerpad that teaches you to make projects and automate at work, without having to write code.

2. The Disruption

Technically, you can slap together some of those microservices, and you're able to put together entire web products or web services.

And it would be a complete service, end-to-end, because there are even things such as Email Marketing and Automation.

When I look at this, I sense DISRUPTION.

Do you remember, some time ago, we had these roles called Server Admin and Database Admin?

These people would just maintain the databases and the servers, helping with the scaling.

These days, we can see that no one that does that stuff anymore.

Or not as many, because people are using these prebuilt platforms, by AWS and Google.

That means you can get scale out of the box, simply by using these services, provided by those cloud platforms.

We don't need those roles anymore, their jobs were just automated out of existence.

Is this really the future of software development?

3. The Skepticism

And just like with any disruption, you'll encounter some skepticism.

Historic examples include Amazon Web Services (AWS).

If you search for posts and comments related to AWS on Reddit from 2011, you'll find plenty of opinions on why it will never work.

And the same applies if you search for discussions related to Airtable from 2015. And look at them now.

4. What about the Developers?

Here's a funny thing, I haven't heard anything about any of this while reading HackerNews.

When I go to HackerNews, this is what I see:

It feels like that programmer community has their head in the sand.

They seem to be completely ignoring the market, which is supplanting what these programmers are doing.

At some point, it almost feels like all some programmers want to do is hit keys on a dark mode terminal, compare editors and see who can come up with the most concise and cryptic Linux command.

5. Who is winning?

When disruption happens, the affected activities become easier and more affordable.

Do you know how expensive it was to build a startup 20 years ago?

You needed at least $2M funding just to buy the servers.

Thanks to AWS and other cloud platforms, anyone can purchase cloud computing resources now.

And now, anyone should be able to build a web or mobile app, without having to hire expensive developers.

I'm not talking about just a basic website, you can ship complete products very quickly.

This includes email marketing, landing pages, CRMs, domain names, even checkout pages (see Gumroad).

These services have experienced explosive growth.

And even our very own Endtest is growing much faster than we expected.

Typical reaction when someone tries our platform:

Coming up with the code all by yourself becomes a meaningless struggle.

This doesn't mean that we can all stop coding and throw code out the window.

We just need to understand in what areas do we need to deploy code, and in what areas we can leverage these services in order to ship our products faster.

6. Who is losing?

The ones who will take a hit from this disruption are the ones who make a living out of keeping things complicated.

Some of these folks would do anything to discourage this movement:

Imagine being a web agency that does small projects for all sorts of businesses.

And suddenly, some of these businesses no longer require your services.

I've seen something similar because of Endtest and other no code test automation tools.

The only adversaries of these testing tools seem to be the ones who've made a career out of pasting together an incredibly overcomplicated Selenium framework, or out of teaching others how to do that.

7. What problem is it solving?

A solution is successful only if it's solving a problem.

Software Development is slow and expensive

Software Developers have been in a privileged position, due to the high demand.

But several factors in the last few years made Software Development even more expensive for companies.

And we're seeing companies moving away from relying on coders to build everything.

Context

It's not just the small businesses.

Most huge companies have an unhealthy obsession with saving money.

There are countless horror stories of highly profitable corporations, that scramble to save every penny.

Relevant example

If you look at the homepage from Airtable, you'll see that Netflix is one of their customers.

As you can imagine, Netflix has all the engineering resources to code everything by themselves, and yet, they're using Airtable for some processes.

We'll most likely see the big companies pushing the pedal on this movement, since it will result in massive savings, and higher profits.

What about you?

I'd love to hear your opinions on this.

How to run Cypress tests on Safari

Liviu Lupei — Thu, 16 Dec 2021 09:59:47 +0000

Today, we're going to learn something really important.

I'm a Solutions Architect at Endtest, that means I try to stay up-to-date with all the testing technologies.

This article is meant to raise awareness about the importance of doing test automation the right way.

Some of you might already be using Cypress, but there's a major inconvenience:

Cypress does not work on Safari

And that's pretty serious, because Safari is the 2nd most used desktop browser in the world.

There is no excuse, you have to test on Safari.

There are other incoveniences as well:

Cypress cannot handle multiple browser tabs
Cypress cannot access multiple URLs in the same test
Cypress has dificutlies finding elements in iframes

But does that really matter?

As a Software Developer, should you actually check if your website works as expected on all major browsers?

Building great software is more than just installing npm packages.

And it seems the Can't they just use Chrome? solution isn't good enough for most companies.

Now, it's your responsibility to make sure those Cypress tests that you worked on for months will actually deliver some real value.

Shouldn't be too hard, right?

You made the decision to use Cypress instead of Selenium after reading that one blog post, that totally wasn't written by a paid Cypress Ambassador.

You did check that the person who wrote it wasn't being paid to write it, right?

Ideally, you should have looked at an unbiased Selenium vs Cypress comparison.

Now, let me show you how to run those Cypress tests on Safari.

1. Run your Cypress tests on Chrome once.

2. Export the results in HTML format:

3. Now, rename the file:

4. Send that file to your Manager or put it on Slack.

But wait, we didn't actually test anything on Safari...

Well, of course you didn't.

The reality is that Cypress can never work on Safari, because Apple has a restrictive ecosystem and takes security seriously.

But the Cypress tests you ran on Chrome are just as irrelevant.

Want to know why?

Cypress is using JavaScript to interact with the elements.

And JavaScript can click on any element, regardless if the element is hidden or covered by another element.

Can a real user do that? Definitely not.

That means that your tests will always be green, but your real users might face issues.

This is one of the many reasons why Selenium migrated from JavaScript to webdriver commands a long time ago.

// Detect dark theme var iframe = document.getElementById('tweet-1258152994815672320-611'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1258152994815672320&theme=dark" }

And that's why Endtest is also using the webdriver technology:

Because of that, the tests can run on all major browsers, including Safari.

5 Reasons Why You Should Perform Geolocation Testing

Liviu Lupei — Fri, 05 Nov 2021 18:02:38 +0000

We all know the saying "It works on my machine". It's a good practice to take the testing beyond the "It works in my country" phase.

It may be dangerous to assume a website will work the same for everyone in the world.

Here are 5 reasons why you should perform Geolocation Testing.

1. Using jQuery? Your website might not work in China.

Many websites that are using jQuery tend to still load it from a Google CDN.

Wait. What's a CDN?

A content delivery network (CDN) refers to a geographically distributed group of servers which work together to provide fast delivery of Internet content.

This means that, instead of hosting the jQuery library on your own servers, you just fetch it from a URL, like this:

https://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js

And it seems these URLs cannot be accessed from China without a VPN.

That means your website won't work correctly, and you'll end up like user151496:

Now, you don't have to be as dramatic as user151496: It's easier to just test instead of giving up on ever using a CDN.

But maybe you're not interested in the 989 million people that have access to internet in China.

2. Your Checkout page is probably breaking the law in Germany.

In Germany, it's mandatory for any Checkout section to have a Review step.

Which is nice, since it gives folks a chance to double-check before making the payment.

As with any law or regulation, not respecting it can lead to a crippling fine.

One of the many reasons we have Frankfurt, Germany as a Geolocation option in Endtest.

3. Online Betting or Gambling? It's illegal in some US states.

There are 9 states that have strict laws for Online Betting and Gambling: Arizona, Alabama, Hawaii, Idaho, Iowa, Louisiana, Montana, Nevada and Washington State

If your website offers anything resembling online gambling, you should make sure it doesn't work in those states. Unless you're willing to pay some fines or go to prison.

Remember, it's the responsibility of the website owner to restrict access.

This is why we offer Seattle, US as a Geolocation option in Endtest.

For those of you who are outside the US or just really bad at Geography, the city of Seattle is in the State of Washington.

4. Your GDPR hacks are probably messing up something.

Remember 2018? Everyone was going bonkers about GDPR.

And a lot of custom logic was added in websites and services to have a specific behaviour when being accessed from the European Union.

It's a good practice to check if those GDPR patches that you added in 2018 are still working as expected.

Don't forget about the GDPR fines, they are still a thing.

5. Some third party scripts just can't be trusted

If you navigate the dependency tree of all the modules and services your website is using, it really makes you consider the risks you inherit, not to mention the exposure to left-pad type issues.

We encountered a memorable situation with an Endtest customer and their website.

Their website was working perfectly fine for them in Netherlands, but it was literally causing the browser to freeze and crash when being accessed from a US machine.

Turns out that some third party module used by their website was going crazy when being accessed from the US.

And we're talking about freezing the Chrome browser on a Windows machine with 16 GB of RAM.

That issue might have never been uncovered if they never accessed their own website from outside of Europe.

Originally published on the Endtest blog:

https://endtest.io/guides/blog/2021/11/05/5-Reasons-Why-You-Should-Perform-Geolocation-Testing/

How to test file uploads with Selenium

Liviu Lupei — Wed, 03 Nov 2021 15:47:35 +0000

I work as a Solutions Architect at Endtest.

In this article, we're going to learn how to perform a file upload with Selenium.

1. Let's understand how a file upload works

Here is a basic example on Filebin:

Behind each file upload section, you will find an <input type="file"> element:

When I click the Select files to upload button, the native file explorer window from my OS will open and I can select a file:

And after I select the file and click on the Open button, the local path of the file will be written in the <input type="file"> element.

In my situation, this will be the local path of the file:
/Users/liviulupei/Desktop/rabbit.png

2. Behind the scenes

The browser is the one writing that local file path, not the JavaScript.

Browsers do not allow JavaScript to write in <input type="file"> elements, due to Security reasons.

If that restriction wouldn't exist, a website could potentially upload files from your computer, without your knowledge or permission.

As an experiment, let's try to write in that input with JavaScript:



document.querySelector("#fileField").value="/Users/liviulupei/Desktop/rabbit.png"

As you can see, we're getting an error.

3. How not to automate a file upload test

The first instinct might be to automate the exact steps that a real user performs.

But there's a major challenge in that approach.

Selenium can only interact with elements from the DOM, it cannot interact with elements from the OS, such as that File Explorer window.

A possible workaround for that would be to call an external script that can handle that part, such as AutoIT, SikuliX or pywinauto.

But that could introduce flakiness in your test, since things might not always look the same in that file explorer window.

4. The correct way

The correct approach is to skip the file explorer window part and to write the local file path directly in the <input type="file"> element.

JavaScript can't do that, but Selenium can, since the commands go directly through the webdriver.

Let's write that Selenium command with Python:



file_local_path = "/Users/liviulupei/Desktop/rabbit.png"
file_input = driver.find_element_by_id("fileField")
file_input.send_keys(file_local_path)

Easy, right?

5. In case the file input is hidden

There are situations where the <input type="file"> element might be hidden.

That is the case with most modern website designs.

Selenium won't be able to interact with that element, because it can only interact with visible elements.

In that situation, you would get an Element not interactable error.

The workaround is to execute some JavaScript code in the browser that will make the element visible:



document.querySelector("#fileField").style.visibility="visible";
document.querySelector("#fileField").style.display="block";

That JavaScript code will actually be executed from your Python Selenium code, with the execute_script method.



javascript_code = "document.querySelector..."

driver.execute_script(javascript_code)

Not ideal from a CI/CD perspective

Relying on a hardcoded local file path works well only if you're testing on your own machine.

But most teams have their tests plugged into their CI/CD pipelines.

You could implement a script that downloads the file from a repository and places it on the machine that is running the test.

7. The easy way

It's a bit easier to perform a file upload test with Endtest.

You just need one step:

Details are provided in the How to test file uploads chapter.

The file needs to be stored in the Endtest Drive (or any other system that provides a direct download link).

And when the test execution starts, the file will be downloaded from the Drive onto the machine or device that the test is running on.

That means it's really easy to plug the test into your CI/CD system.

5 Myths About Codeless Automation

Liviu Lupei — Fri, 11 Dec 2020 15:07:24 +0000

Let's take a trip down memory lane and look back at some of the myths that were born in the early days of codeless test automation.

1. No flexibility

This was, by far, the most popular myth.

It dates back to the old test recorders from the early 2000s.

And it's the main reason why some folks used to reinvent the wheel and write their own internal test frameworks a few years ago.

Those internal test frameworks were a nightmare to maintain and the ROI was terrible.

It might be difficult to find someone who still does that in the present.

But if you would ask them why, they might tell you that their scenarios are simply far too complex and they need functionalities such as:

If statements
Loops
Variables
Reusable functions
Concatenate different strings
Extract values from JSON objects
Extract values from arrays
Extract values from CSV files
Connect to databases and execute SQL queries
Send API requests
Chain together multiple API requests
Handle iframes, Shadow DOM, multiple browser tabs
Read and write cookies
Access the page source and the browser logs
Execute JavaScript code snippets

The truth is that Codeless Automation tools do support all of those functionalities.

At least Endtest does.

2. Editing is difficult

Another myth that dates back to the early 2000s.

If someone wanted to edit a recorded test, they had to record it again.

Things are different nowadays, editing is easy:

This makes codeless tests more stable and easier to manage than classic Selenium Webdriver tests

If you can still find someone who believes that they need to record the entire test case again or edit the actual code if something changes, please let them know it's not 2005 anymore.

3. Collaboration is difficult

The old test recording tools were Desktop tools.

This means that anything you created was stored on your computer.

Syncing your work with your colleagues was a nightmare.

This led some folks to the following conclusion:

"We need to write code, because we need to put it in a git."

Fortunately, modern Codeless Automation tools are cloud solutions.

This means that anything you create is stored directly in the cloud and you can easily grant access to other team members, use versioning, branches and sync your work.

Endtest even offers an Automatic Backup functionality.

4. It's too expensive

In the early 2000s, due to a lack of knowledge and in an attempt to cut spendings, some teams or companies decided to use only open source solutions.

Not because they took an interest in the community and they wanted to add their contribution, but simply because open source solutions are free.

That principle can no longer be applied, because most modern tools are in the cloud.

If someone asks if a cloud solution is open source, it means that they're not aware of the differences between a library and a cloud solution.

Using a cloud solution helps a company save money, because they no longer have to build their own internal tool by stitching together different libraries.

Let's take a look at an example.

Company A and Company B decide that they need a video conferencing tool because they want to host webinars.

After doing some research, Company A decides that they are going to use Zoom, paying $19 per month.

Company B wants to save money, so they look for open source options. They decide to use WebRTC, an open source project that allows you to build real-time communication apps.

Day 1:

Company A now has a stable video conferencing tool and they start hosting webinars.

Company B starts building their own video conferencing tool by stitching together WebRTC and other libraries.

6 months later:

Company A has already hosted an impressive number of webinars, without encountering issues.

Company B is still working on their own video conferencing tool, they assigned 3 Software Engineers to that project. It's almost ready, but it will take time until they'll have advanced features and there's no way of knowing if it will be reliable enough.

If you do the math, you'll see that Company B actually spent a lot more money compared to Company A, but they didn't get any return on their investment yet.

That's because those 3 Software Engineers have salaries, which are definitely more than $19 per month.

Company B also missed out on plenty of opportunities during those 6 months when they didn't host any webinars.

You can apply the same logic when comparing an open source library such as Selenium and a tool like Endtest.

5. Vendor lock-in

Let's take a look at the definition:

Vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs.

Modern legislation like GDPR and HIPAA makes it mandatory for vendors to provide flexible data migration options.

Your data is your data and you have the right to take it wherever you want.

Just make sure to review the Privacy Policy.

Originally published here

Will cross-browser testing still be relevant in 2021?

Liviu Lupei — Mon, 07 Dec 2020 11:22:24 +0000

If you're a developer, most of your time is spent on building and improving functionalities.

It's easy to forget that not everyone is using Chrome.

I recently spotted a major cross-browser bug on LinkedIn.

This is how the Interests section looks like on Chrome:

And this is how it looks like on Firefox:

It gets worse if you click on the See all button.

Chrome:

Firefox:

You'll find plenty of articles online about how LinkedIn has a complex workflow with scalable technologies to deliver to best experience for their users.

Not even the latest and most scalable frontend technologies can prevent cross-browser issues from appearing.

Nowadays, it's a lot easier to build automated tests than it was 5 years ago.

A defect like the one I just showed you could have been easily prevented with a simple automated visual test.

9 Characteristics of a Bad Software Tester

Liviu Lupei — Thu, 26 Nov 2020 17:28:37 +0000

I'm Liviu, and I work as a Solutions Architect at Endtest.

You can easily find advice on what to do to be a better tester.

Here is a list on what not to do:

1. Not knowing enough about the product.

Testers can be the bridge between the business side and the technical side.

A good tester is also a power user and is familiar with all the workflows and the corner cases.

2. Not testing on all major browsers.

Not everyone is using Chrome, I can't stress this enough.

Safari has an 18% market share and lots of folks are still using Internet Explorer.

It doesn't matter if your product is built with React, Vue or Angular, there is no library or framework that can eliminate cross-browser issues.

3. Not automating.

Relying only on manual testing is unacceptable.

Automated tests are the best way to make sure that everything is working as expected, without breaking a sweat.

Don't know where to start? Start here:

How to create Web Tests

How to create Mobile Tests

4. Not showing empathy.

Finding a bug doesn't have to turn into a blame game.

Don't be arrogant or patronizing.

Bugs are a normal byproduct of software development.

5. Not casting a wide net.

Even the smallest change applied to a software product can cause a ripple effect and break functionalities which might seem completely unrelated.

Don't test only around the change, go beyond that.

6. Not testing all the way.

You're familiar with mocks, drivers and stubs, but you should never have complete faith in them.

If you're testing a workflow that sends an email or a text message, make sure that you test them as well.

How to test emails

How to test SMS messages

7. Not providing enough details in the reports.

No one likes to read a vague bug report.

Always include the following items:
• description
• steps to reproduce
• the expected result
• the actual result

Don't hesitate to include:
• screenshots
• video recordings
• logs

8. Not brushing up on the latest tools.

For example, an intelligent test automation tool can make your life easier.

Don't reinvent the wheel.

Familiar with the KISS principle?

It stands for Keep it simple, stupid.

You can check out this video where I compare Selenium with Codeless Automation:

I'm comparing them by using the following criteria:
• ease of use
• flexibility
• collaboration
• cross-browser capabilities
• implementation cost
• end to end capabilities
• reliability

9. Not wanting to learn more.

Even if you're not writing code, that doesn't mean that you shouldn't be familiar with the basic concepts.

A good tester should be familiar with:
• HTML
• CSS
• JavaScript
• HTTP Request Methods
• Linux Commands
• SQL

A good place to start learning those is W3Schools.

Your turn.

Which one of these are you currently doing?

Write a comment below and tell me all about it.

Selenium vs. Codeless Automation

Liviu Lupei — Tue, 24 Nov 2020 18:47:03 +0000