Tag Archives: automation

7 Tips for Automation Testing

The term automation is becoming more commonplace and popular with the already large and rapidly growing world of IT companies. A quick web search will give you thousands of articles talking about the benefits of automated testing, including how much money companies can save by using it. The purpose of this article will be to share some of the experiences I’ve had in more than five years of working in quality assurance (QA).

In my time in QA, I have worked on three major projects: the website of a major airline, with an on-demand video provider, and creating a security application for one of the most famous antivirus services. I have also participated in small projects where I was involved in manually running the same test suites every day, up to three times a day. Working on these projects has made me realize how necessary and beneficial it can be to automate.

7 Tips for automation testing

Throughout my five years of experience, I have acquired a lot of tips that make the automation process much more manageable. In this article, I will provide you with seven tips that will making the automation process a lot easier.

  1. The Code Reviews of other QA and/or developers, as well as those from POP or the BA are of GREAT importance.

  2. Reuse code. Writing the same code over and over again can be a waste of time, particularly when the changes in the data set are minimal.

  3. The tests have to be fail-proof. They should only fail due to errors in the product or the environment. They should not fail because of a bad analysis made before creating it. This fail-proof status should also include the Unit Test.

  4. Ask for help. We are all proud people. Because of this, it can be very satisfying to complete a challenging task without having to turn to someone for help. We all want to be resourceful and use the skills we have acquired in our years of working so that we share our successes with our colleagues. However, being prideful can sometimes translate into hours of extra work that will only lead to losing time in the sprint, losing money for the client and the company, and can even delay the tasks of our peers.

  5. Respect good practices. When working as a team we must remember that our code can affect the code or work of others. Because of this, we need to keep best practices in mind.

  6. Automated tests are not only a good tool for testers but also, when used correctly, can be very useful for developers.

  7. Being able to adapt is very important. Sometimes, because of licensing issues or other reasons, we may have to automate in a language which we are not comfortable using, are not familiar with, or simply do not like. Although this has happened to me before, I understood that the language was the right one for the software to be tested, and I pleased to say that I have some experience in other languages and technologies that will surely be useful again throughout my career. Being flexible and open to learning new skills will also make me more valuable to my current employer.

Hopefully, these tips will help testers and developers who are not yet familiar with automation to better understand more about its importance. At Santex, we are always open to sharing knowledge and listening to new experiences and opinions, so feel free to leave your thoughts on automation.

About the author: Mauricio Ardiles is an enthusiastic QA Analyst seasoned in a variety of testing skills. Strong background in automation testing and a certified Scrum Master. 


Candidate Casuistry for Test Automation

By Angel G. Terrera

As systems grow, the generation of manual test cases is a task that becomes more difficult and more expensive. Therefore, it is especially important to use techniques for test case automation from previously selected best candidates if we want to meet market standards and deliver on time.


When selecting candidate test cases for automation, two different stages of software testing areas should be identified:

  • An area that hasn’t yet begun to automate their testing efforts.
  • An area that has implemented automation projects and intends to walk the path of continuous improvement.

These two different stages reflect the maturity of the area that selects possible candidates for test case automation.

For areas of type A, a range of possibilities is available:

  • Identify and recognize the candidate casuistry from certain defined criteria.
  • Register the candidate casuistry in a tool for further monitoring, control, and update.
  • Manage the execution of the generated scripts on the basis of the selected candidates scenarios  or integrate them with other tools that can run them.

Areas of type B encounter another range of possibilities. They should recognize from the already automated processes those test scenarios that, according to their characteristic or outcome, should begin to be “separated” as best candidates for continuous performance improvement.

Here are some factors that should be considered when selecting candidates for automation, depending on the type of scenario that has to be tested:

  • Automation Tool: The tool must be able to withstand the technology on which the application was built.
  • Time available for testing: Automating from scratch takes twice the time than making the script for manual testing.
  • Frequency of use of the application: Before carrying on automation efforts we should know if the application will be used constantly, sporadically, or just once.
  • Complexity of the application: If the application is fairly complicated we will have to evaluate certain candidates cases because the initial effort for automation is too high.
  • Stability and Variability version: We should consider automation if we have a stable version of updates, without underestimating its variability.
  • 100% Automation: Will depend on how much human intervention the test scenario possesses.
  • Main flow: Identify, recognize, evaluate the main scenarios and their respective priority conditions (critical, important, urgent) that align the main business rules.
  • Avoid automating everything: The most common mistake is trying to automate all test cases. Automation scripts should be a support for manual testing and not a replacement of it.
  • Evaluate combination III and VII: It refers to test cases linked to the core of the application that can be built at the beginning of the project and which can then be used in the rest of the development cycle.
  • Cost associated with automating test case: Assessing its complexity to decide whether to continue with the process of automation or go back to manual testing.
  • Maintenance Project: Identify the history incident as a source of information.
  • Think about the audience: Who will read and use the selected test cases?
  • Types of Tests: Consider particular scenarios of certain types of Test Cases (UAT, Regression, Smoke).
  • ROI: Return on Investment (ROI) for the business that each script has, specific to each company.
  • Number of steps and verification: The complexity is given by the number of steps (actions) and checkpoints (expected results) each of them has.

However, much will have to do with the type of project since the course of treatment is not the same for traditional (cascade) or agile projects.

Some positions related to assessing the best candidates state:

  • Scenarios that cannot fail under any circumstances.
  • Features that, if they were missing, would have a negative impact on the customer.
  • The selection begins with cases that cover the main functionalities.
  • Cases with average complexity of business; for example, not being too expensive to automate.

From the basis of this article, I will go a little deeper in the next one and explain more concrete situations.

Content generated on the basis of the comments written by the members of the group TESTING & QA on LinkedIn.

Angel G. Terrera is the Founder of TestingBaires.com, a website dedicated to the promotion of software testing.
webmaster@testingbaires.com | www.testingbaires.com

ISTQB Certified Tester


Continuous Delivery using ASP.NET MVC4 – Web API

By Gastón Robledo, Architect at Santex

This post will help you learn how to create continuous delivery using ASP.NET MVC4, which is a web API.

Software Needed

  • Jenkins
  • MSBuild
  • Web Deployment Tool 3.5
  • IISWebSiteCreation (Custom Application)
  • MSTests
  • GIT
  • Jenkins MSBuild Plugin
  • HTTP Requests Plugin

Continue reading