Tag Archives: Testing

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. 


Mocking with Python!

By Juan Norris, Python Developer at Santex

Here at Santex, we pride ourselves on delivering high quality software, and therefore testing is a big part of our day-to-day development process.

I’m currently working on a Python project that relies heavily on mock for unit tests. A few months ago, some new members who were not familiar with the mock library joined the team. As those of you who have used it may know, mock sometimes can be unintuitive, confusing and lead to “false positives” – passing tests that are not really testing anything – but it is also very useful and powerful.

So we found ourselves in the need of a way to explain this library a little bit, and that is why these slides were created.

We started with an introduction to what mock is and why should you use it. The slides are meant to be both a starting point and some best practices, because they explain the most important classes and helpers in the library, as well as how/when to use them and the common pitfalls you may run into.

Although there is not a lot of written information and this material is composed mostly of code examples, I hope this can get you started with Mocking in Python!

See Mocking in Python Presentation!

About Juan Norris. He is a Python/Django developer with experience in JavaScript (Jquery, AJAX), MySQL and PostgreSQL. Juan is continuously learning and training to investigate new technologies.

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


Integrating Jira with TestLink

By Martin Navarro

There are a number of questions to ask when it comes to creating a testing strategy for a project. How we are going to manage test cases is perhaps one of the most important. This question has many possible answers like Excel, Google Docs, Microsoft Word, etc. However, none of these are valid or practical answers. To produce a high standard test case management we need a tool with all the necessary requirements, or at least most of them. This is where a product like TestLink can be very useful.

Continue reading