Tag Archives: automation

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. 

 

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.

TestingAutomation

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.

Reference:
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
https://www.facebook.com/testingbaires
https://twitter.com/testingbaires

ISTQB Certified Tester
No.12-CTFL-27832-HA