Category

Guest Blog

Category

We could say automation is the whole raison d’être for software development. As developers, we seek to employ automation in order to solve problems with more efficiency than before. And we solve problems not only for our clients or employers but also for ourselves. We write scripts and software utilities to automate the packaging and deploy of our applications. We employ plugins and other tools that can automatically check our code for common mistakes and even fix some of them.

Another instance of automation is browser automation. And that’s what this post is all about. If the term doesn’t ring a bell, never fear. The post will do justice to its title and answer the question it poses. And after defining the term, we’ll proceed to show scenarios where browser automation is the right tool for the job. Then, to wrap up the article, we’re going to give you tips so you can get started with browser automation ASAP. That’s what, why, and how in just a single post.

Let’s get started.

Browser Automation: Definition

We’ll start by defining browser automation. We could try something like “‘Browser automation’ means to automate the usage of a web browser” and leave it at that. But that would make for a definition that’s both technically correct and useless unless we define automation. That word is one that we often take for granted, so I think it might be useful to actually take a step back and define it.

Defining Automation

Here’s what Merriam Webster has to say about automation:

1: the technique of making an apparatus, a process, or a system operate automatically
2: the state of being operated automatically
3: automatically controlled operation of an apparatus, process, or system by mechanical or electronic devices that take the place of human labor

Interesting. Now take a look at Wikipedia’s definition:

Automation is the technology by which a process or procedure is performed with minimum human assistance

Bots Don’t Get Bored

What do those two definitions have in common? At least for me, the point that’s really obvious is that automation seeks to remove human intervention from the equation. And why would we want to do that? While we humans are great at a lot of things, we’re also terrible at a lot of things—especially tasks of a repetitive nature. When performing repetitive, boring tasks, we tend to get…well, bored. Our mind easily zooms out of focus as we enter autopilot mode, and soon we’re making mistakes.

But since we’re a pretty smart species, we came up with a device that’s way better—and faster—than we are at performing repetitive tasks. And of course, you know I’m talking about the computer. With all of that in mind, here comes my upgraded definition for browser automation:

Browser automation is the process of automatically performing operations on a web browser, in order to achieve speed and efficiency levels that wouldn’t be possible with human intervention.

It’s far from being a perfect definition, but it’s already something we can work with.

Browser Automation: Scenarios for Usage

Why would someone want to automate the operation of a web browser? As it turns out, there are plenty of use cases for browser automation, and that’s what this section will cover.

Automatic Verification of Broken Links

It’s frustrating to click on a link only to see the infamous “404 Not Found” message. If you have a site, then you should definitely fix the broken links in it or, alternatively, delete them. But before you go about doing that, you first need to find them. This might not prove too much of a problem if your site has just a handful of pages. But think about a complex database-backed portal, with hundreds or even thousands of pages, mostly dynamically generated!

Now, what before was a minor nuisance becomes a herculean task. And that’s where browser automation fits in. You can employ tools that will automatically go through your site, verifying every link and reporting the ones that are broken.

Performance Testing

Performance is a huge concern when talking about software development. In this era of high-speed connections, most users will get frustrated if the site they’re trying to access is even slightly slower than they’d expected. Besides, Google itself penalizes slower sites on its search result pages.

Browser automation can also help with that. It’s possible to employ browser automation tools to do load and performance testing on your websites. This way, you can not only verify your web app’s performance on the average case but also predict its behavior under the stress of traffic that’s higher than usual.

Web Data Extraction

When the World Wide Web was invented 30 years ago, its purpose was to allow researchers to easily propagate their works. In other words, humans put stuff on the web for other humans to consume. In the decades that followed, we watched a rise in the non-human use of the web.

Browser automation definitely plays a part in this. Web data extraction, also known as web scraping, is another use case for browser automation tools. From data mining to content scraping to product price monitoring, the sky is the limit for the uses of web data extraction.

Automated Testing

Last but not least, we have what’s probably the poster child of browser automation use cases: automated testing. Yes, we just talked about performance testing and broken link verification, and those things are also automated tests. But here we’re talking of general, end-to-end functional tests. For instance, you might want to check that, when informing an invalid login and/or password at a login screen, an error message is displayed.

Such tests really shine when you can effectively use them as regression tests. If a fixed problem returns in the feature, you have a safety net that will warn you. And that safety net is way faster and more efficient than human testers—at a fraction of the cost.

How to Get Started With Browser Automation

Learning browser automation can seem like a daunting task. It’s an enormous topic, and there’s a lot to know. But it’s no different from any other area in tech. Approach it the way you would approach learning a new programing language or framework: by doing it.

First, think of at least one use case for browser automation in your current organization. We’ve just shown you some, and I’m sure you can think of many more. Some people call this “scratching your own itch,” and it’s an effective way of motivating yourself to learn something.

As soon as you have a small, discrete problem you think you can solve with browser automation, starting looking around for tutorials on how to get started with some of the available tools. When you get stuck, look for help in the documentation of the tool you’re trying to use. You can also search for help on Stack Overflow under the “browser automation” tag. And of course, there’s always Google.

Build a minimum viable example of browser automation in place. As soon as you get something that works, no matter how simple it is, that’s a milestone. You can use it as a foundation upon which to build more sophisticated and complex approaches.

Where to Go From Here?

Today’s post was meant to give you a quick primer on browser automation. We started by defining the term, then proceeded to show some common use cases for the technique. Finally, we gave you tips on how to get started.

As I like to say when writing introductory articles like this one, this was just the tip of the iceberg. There’s much more to browser automation than what could be covered by a single blog post. Where do you go from here then?

There’s no silver bullet: the answer is to keep studying and practicing. Continue to evolve your first minimum test suite and learn from it. You should also keep an eye out for what’s happening in the world. There are interesting developments, such as the use of machine learning to help developers with the creation, running, and maintenance of test cases.

Additionally, stay tuned in this blog for more automation-related content. Thanks for reading and see you next time!

This post was written by Carlos Schults. Carlos is a .NET software developer with experience in both desktop and web development, and he’s now trying his hand at mobile. He has a passion for writing clean and concise code, and he’s interested in practices that help you improve app health, such as code review, automated testing, and continuous build.

“When I talk to my colleagues and tell them that we have a team of developers that are performing manual testing guided by a test-plan nobody believes me… ”

Let me just start by saying that I’m very proud of our team and how far we have come.

Since my arrival, we have tripled in size and have significantly improved our quality standards. When I Joined Testim, we were a small R&D team based in Israeli. We had no QA department or defined testing process and had to implement it all from scratch. There are many challenges in trying to create a process where testing is integrated into our CI/CD workflows. For one, there is awareness. The process of assimilating the Idea that we have to test our produced features and acknowledging there are consequences if we don’t. We have a very talented and speed oriented Dev team.  But, it comes to a point when you have to stop and take a step back to really plan for the future. As we strive for continuous improvement, we have to periodically evaluate our process from end to end, making sometimes small adjustments which can improve the flow holistically. We had to assimilate the idea that it is better to “waste” a week of testing than 2 weeks of refactoring. Or worse – to lose our customers trust in our product.

I’m very happy to say that one of the things I love most about our team – is that we do not have inner battles. (At least not anymore). We truly understand that we are all working for the same cause and moving as a team to get the job done.

Some history…

I started at Testim as a one-man show. I arrived with a  background in quality assurance and solid automation experience working for larger companies. The startup environment was new to me.  I took the first month to learn the culture, build rapport with the people, understand the customers and their objectives, and observe the various internal and external process end to end.  From these learnings, I could conclude which things needed to be changed, what was good and should be preserved, and which tools or methodologies could suit our needs the best way.

For example, the product-dev-testing workflow needed some tuning. With that said, what suits an enterprise would be terrible overhead for a fast-paced startup. Typically, a startup requires a lot of risk analysis, fine-tuning and wise tool selection. We needed flexible tools that were easy to use and configure as our processes would quickly evolve over time. We did not have time for lengthy implementations which involved consultants or systems integrators, we needed to deliver value instantly without any setbacks. 

I see a lot of guys being recruited to a small startup coming from a big enterprise, and without fully evaluating their surroundings, start to incorporate heavy test management, reporting, and bug tracking tools just because “This is the way it should be done.” Frequently they will encounter resistance from the team because they simply do not see the need, or it creates an unnecessary burden on the routine without really delivering added value to the current work process. The thing is that there is no “single right way” to do things, and each team needs to collaborate to create an efficient workflow that works for them.

The 5 steps we took to building our quality driven development process

  1. Effective Product-Dev-Testing flows – We needed some more concrete requirements, tech designs, with lean and effective documentation. We also needed to establish what was the entrance and exit point to all of the “stops” in our cycle (And how the ping-pong would be addressed during the cycle). That took some work but I think that we are in a very good place now and we continue to learn and iterate.
  2. Incorporating quality initiatives into our roadmap – An important thing to realize – plans tend to change in a fast-paced startup. With that said, if we don’t bring up things for the agenda – they will not go into our mindset (and eventually into our roadmap). I mapped the things I needed to implement in regards to quality and automation, ensuring it was a part of the plan and scheduled work procedure. One more thing I needed to change was proper time estimations for feature releases. While we do need to move fast and give reasonable time estimations, we started incorporating testing and automation coverage time into our time assessments for each feature. That way, the time we needed to release a well tested and “covered” product is being properly evaluated.
  3. Tool choice – We decided on tools, frameworks and document formats that suited our needs the best way and worked on perfecting the flow with every sprint. The key guideline was to make the tool work without making us work for the tool.
  4. Testing and automation coverage – We worked on reaching a point where our own automation gives us a very solid picture of our product and risk-analysis to cover what needed to be performed manually. In addition to that, we made it part of the process for each and every one of us to write automated coverage for the features we deliver. The standardized approach and guidelines are maintained with some insights from me and our Chief Architect. We also implemented an effective CI/CD process and pipeline to assure our fast pace and quality standards could go hand-in-hand.
  5. Ownership & teamwork – It is true that in a startup there is a lot more versatility in everybody’s roles.  With that said, over time we learned our strong points and took responsibility for things where we can contribute to making our work more productive. I took the Quality Assurance and Test-Automation part because it was my background. There was a time when testing was my sole responsibility. Time went by, we grew to understand that a bottleneck is not a good place to be stuck in (If you know what I mean). That lead us to adopt a whole new approach. We always worked as a team, and as such, everybody feels responsible to make their task come to an end with maximum quality and fast delivery time. A part of that is to take responsibility and test your own work. When I tell my colleagues that we have a team of developers writing test automation and performing manual testing according to a test plan – nobody believes me. It’s actually very simple math. We had a lot of work to do, and a limited staff. The alternative is to deliver features without testing or to delay releases, and that was not an option. Test your work and be responsible for it – it’s as simple as that. Ones you push that deploy button – you have to be confident that you did what you could to assure it’s quality. Psychologically speaking, when you know that you don’t have a “Gatekeeper” checking after you, you would do a more thorough job. With that said – at times you do need an additional set of eyes or it’s better to let someone else take a look after you have boiled your own code for a long time – and that’s where I come in – or someone else from the team who is available. The popular conception is that only testers can test a product. But, what is the difference between a tester and a developer? The main difference is that a tester decided to learn how to test and a developer decided to learn how to develop. Is it possible for someone to learn how to do both? Traditionally, organizations preferred that it was separate functions. However, today’s Agile and DevOps practices try to reduce the handoffs between various stages of the process to create a continuous workflow. Once you teach a developer how to test, and give them the correct mindset for testing – they can tackle any feature they develop. Since they know the code and its weak points, they can do an amazing job of testing it., Everybody who “Touches” the product and its feature at any stage of the development lifecycle has to do their best to deliver quality work. The bottom line is as I mentioned before, there is not a “one size fits all” model – it takes time and continuous improvement to adopt a process that works best for your team.

I think the main key here is making quality an organizational initiative. Whether you are in product, engineering, sales or marketing, focusing on the customers experience should be the responsibility of everyone.  We try to leverage as much data as possible to provide cross-functional team transparency and not let emotion and anecdotal assessments get in the way of our decisions. We all share the same agenda and my mission is to influence and foster quality awareness and maintain a productive workflow which combines a detailed code review, effective CI/CD, unit testing and some TDD elements – our winning recipe for success.

 

Software Development ranks as the number one job in 2018, spanning industries such as healthcare, finance and manufacturing sectors. This being the case, it becomes really important to write good quality code when developing programs and apps for these industries. Even the slightest coding mistake can lead to big problems in the future. Many coding professionals use Log Analyzer – Real-time Log Analysis by Papertrail to monitor and fix coding errors in their programs.

Below you will find 7 Critical Tips to generate high-quality code.

Image via Pexels

  1. Developing Test Frameworks is Essential

With all of the different tools available to programmers, choosing the right ones can be a bit confusing. Utilizing the power of testing frameworks is a great way to see how well your code will perform. Most of the programs that offer these frameworks are automated and very easy to use.

If you are trying to perform a unit test, then using some of the commonly used unit test frameworks is a great idea. For programs in need of GUI testing, working with tools like Testim is beneficial. Regardless of what your testing needs are, there is a tool/framework out there for you.

  1. Have a Coding Standard in Place is Crucial

Most newcomers to the world of programming fail to realize just how easy it is to write bad and unorganized code. In order to write good code, you will need to put some time into developing standards. Following standards that require you to do things like having name conventions and using good formatting is a must.

By following these standards, you can rest assured that your code can be easily read by you and anyone else that comes across it. There are a number of widely accepted coding standards like the W3C standards that can take all of the guesswork out of this process.

  1. Code Documenters Can Be Helpful

If you are working on larger coding projects that span numerous namespaces and classes, working with software that instantly generates API documentation is a wise choice. With this software, you can help your team identify key pieces of the code without investing a lot of time in research. This type of software is also helpful for developers who are working on a number of projects simultaneously. For years, programmers have used JavaDoc  as their code documenter of choice.

Image via Pexels

  1. You Need to Make Sure Your Comments Are Useful

One of the most important pieces of a sound coding structure is good comments. If you take a break from a thousand line script you are developing, the notes you leave will help you make sense of it all upon your return. These comments can also be helpful to the people who will have to maintain your code once you are finished. Vague lines should have meaningful single-line comments attached to them.

Functions and methods should have meaningful names and parameter descriptions. You should also focus on keeping each of the comments you write up to date. Failing to change these comments when major alterations are made to the existing code is a recipe for confusion and disaster.

  1. Automated Build Tools can be a Life Saver

Using tools like Maven or Ant can assist you in getting your source code developed, compressed and deployed in a relatively short amount of time. By building your program or application with a single command, you can avoid errors and omissions, as well as performing repetitive tasks. 

  1. Get Familiar With Code Refactoring

Failing to refactor your code on a daily basis may lead to big problems in the future. Most programmers believe that refactoring is the key element to keeping their code healthy. When taking on this process, you need to make sure that everything from your program’s architecture to methods and functions are properly refactored.

Functions that have more than 25 lines of code, will generally have far too much logic contained in it. This means you should refactor it and split it into smaller functions or methods. While learning how to properly refactor your code will take time, it is well worth the effort and time you invest.

  1. Try to Avoid Using Global Code

Most new programmers fail to realize what a mess global variables and loops can create. Using global code will usually lead to a number of clashes and error developing. Ideally, you should avoid having blocks that are defined globally. Making sure your methods are written inside of class definitions can be very beneficial. You should also focus on putting class and function definitions within the right namespaces as well.

By following the advice in this article, you can avoid major headaches when developing new code and ensure good quality code.

Be smart & save time...
Simply automate.

Get Started Free