Tag Archives: Testing

7 Tips for Automation Testing

Luckily today, the term Automation is becoming more common and popular in the immense world of IT companies. You just have to search a little bit in the web to find hundreds or thousands of articles in all languages talking about the benefits of automated testing and how much money companies can save using it, so it is not my idea to repeat the comments of my colleagues, but rather to share some of my experiences across more than 5 years of working as a QA.

I worked on 3 giant projects: the website of a major airline, a video on-demand provider, and a security application of one of the most famous antivirus services. I also participated in small projects where manually running the same test suites every day, up to 3 times a day, made me realize how necessary and beneficial it is to automate.

Automation Blog image

Here are 7 tips I learned from automating that I would like to share with you:

  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 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, environment, etc. and not because of a bad analysis made before creating it. This also includes the Unit Test.

  4. Ask for help. We are all proud people and it is a huge satisfaction to complete a challenging task without having to turn to someone for help, but sometimes pride translates into hours that only lead to losing time in the sprint, 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.

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

  7. Adapting is very important. Sometimes because of licensing issues or for a number of other reasons, we may have to automate in a language with which we do not feel comfortable or simply do not like. Despite not enjoying it when it happened to me, I understood that the language was the right one for the software to be tested, and today I can say that at least I have some experience in other languages and technologies that will surely be useful again throughout my career.

Hopefully these tips can help testers and developers who are not yet familiar with Automation to 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 it is a task that becomes more difficult and expensive. Therefore, it is specially 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 tests 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 reflects the maturity of the area that selects possible candidates for test case automation.

For areas of type “a” a range of possibilities is opened up:

  • 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 I list 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 farily 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, never underestimating its variability though.
  • 100% Automation: Will depend on how much human intervention the test scenario possesses.
  • Main flow: Identify/recognize/evaluate the main scenarios and it 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 no 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 be then 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 type of Test Cases (eg 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 have.

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 can not fail under any circumstances.
  • Features that if 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, ie, it’s not 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 in 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 too many questions when it comes to creating a testing strategy for a project. How are we going to manage test cases is perhaps one of the most important of them. This question has many possible answers like Excel (!), Google Docs, Microsoft Word (?), etc. But 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. Here’s where TestLink makes its appearance.

Continue reading