3 Tips about automated testing

In the planning of the activities which occur in a software development cycle it is crucial to select the test activity that best suits on that project/product. The implementation of a solution of automatic tests is far from being an activity out of the box, on the opposite, it requires specific technical capabilities at the level of the automation tool use and particular know-how to operationalize the test effort for the team.

The “Three Topics”, that I document bellow about Automated Tests, are shared frankly with the community, being by-products of an intense personal study, of my professional experience and ideas exchange with colleagues.

• Equal conditions, equal results.
  • The automation process of a Test Case (TC) should have under control different and various environment variables. A procedure that achieves this objective is the cloning of the environment where these tests are performed (if possible, including the tool used in the automation) with posterior clone/copies distribution through the test team. The procedure mentioned before not only speeds up the process, as simultaneously guarantees that the TC’s created interact, homogeneously, with the same configurations of the system, be it the Operative System, the Browser, or in the interaction with third-party applications (like PDF readers openings). In terms of test output, the submitted solution allows circumvent the false “Failed” of the executions. These abnormal and undesirable results could occur when being included in the automation process interactions with non-documented platforms or objects and that emerged in a certain moment in X machine. On the other hand, Y machine, with TC execution functions, trying to run that TC would get problems in the recognition of the platforms/objects because it would not contain the same conditions to reproduce it.
  • Computer systems, normally, presents an architecture of use premised under the premise User/Permission binomial. So it should be initially studied if, in the automation process, the use of different usernames in the access to the test system is neutral to the objective of the tests or if it results in a custom automation that conditions the means/interactions that the functional validation objective is aims to achieve. If the test objective is conditioned by the username use we recommend one solution could result in the centering of all the access with a single username, which is shared by all the test team, including the robots that execute the TC’s.
  • Parameters agglutinating in a common repository may be necessary for the TC execution and also the update process and alteration propagation is made easier. For example, if the project option is to have only one username (as indicated before), this can be saved in a txt or xml file, and can be used by 1 TC or by 100 TC. However, and independently of the number of TC’s it feeds, if it has to be changed by any reason, just do the update in one local.
  • In a classical approach, like in the waterfall model (or in “V” model), we could yet refer that the target application of the automation should be mature enough on what concerns the tests, namely, the automation process shouldn’t be the first point of contact with the tests area. Typically, the automated tests have the purpose of checking if new functions do not affect negatively previous ones (regression tests). Under a different perspective coming from the Agile methodologies (that have gained expression in the current software development world), we are conducted to an assumption that the automation occurs since the beginning of the process. However, many authors say that only an automation process with a keyword-driven approach (a.k.a. action word based testing) may be flexible enough to accompany the fast change of requirements that this type of software development methodology tries to correspond.
• Scheduling
  • Creating and executing TC in different periods is advantageous. Below are some notes that justify the planning of a schedule.
  • During the execution of the Automatic Test Cases (ATC’s), some code is useful be programmed to save variables in cache with the objective of being used on another ATC’s. By not having a schedule of its executing, the risk of being used by third-parties (example testers to execute manual TC) and, so, rendered useless, is significant. It is also common to constitute sequences of test cases that replicate a business flow with the various interactions on the same data in a CRUD (create, read, update and delete) or BREAD (Browse, Read, Edit, Add, Delete).
  • All the applications (either web or standalone) exists under an infrastructure that can have overpopulated accesses at some point. The scheduling of executions can serve various purposes: a) validate that from a functional point of view, the system is correct and that, by it, the execution must occur in a period of diminished usage to avoid false “Fails”, or b) validate by not functional characteristics what are the stress times on the system or which functionalities lose partial or totally its use.

• Robustness and Redundancy
  • An Automatic Test Case, in its core, must be robust in both the functional validations and the unforeseen events without a defined origin. To apply these principles correctly, we should use in the ATC the functions at the tool level that better adapt to the situation. Two examples:
    • The function assert () fails the test in case the characteristic doesn’t have the same expectable properties unlike verify () that allows the robot continue executing remaining steps (tool: Selenium WebDriver).
    • Preferentially, a WaitProperty should be used instead of a Wait (generic) (tool: HP Unified Functional Testing [UFT] / QuickTest Professional [QTP]). In the first case, the robot is programmed to wait until the “expected” object/characteristic is confirmed, spending only the time between the start of the instruction and the confirmation time, under a maximum configured timeout. On the contrary, a generic Wait function has a fixed “wait” time and uses it totally, with the aggravating of the object/characteristic reaches the expected test result like as the contrary.
  • In the script execution, an existing special behaviors on the ATC’s execution may be important.
    • Always Finds the Error. It can be implemented in all the moments the appearance of a label with the “error” name in any type of object, with the purpose of finding non-predicted errors and to a) fail the test or b) unlock the system and try to continue testing the automated business flow. A practical case of the implementation of this functionality is, if working on a browser, to replicate the process of making a search for an Error word in each executed step. So, and dependent of the subjacent at business level to the test, all these situations fail the TC immediately or, on the other hand, search to find a “x” close button or an “ok” button and try to continue the flow.
    • Clean environment. On mass executions, the ATC’s that find negative results can leave the test environment with objects derived from the error situation, therefore non-existent in normal conditions, or even make the platform unstable. These two kinds of outputs can condition the next ATC execution and result in a false “fail”. Once again, it is possible to code at the script level a “cleanup routine” (of windows for example) or an “essential services reboot” between each ATC execution.

------------------------------------------------------------------------------------------------

No planeamento das atividades a ocorrerem num ciclo de desenvolvimento de software é crucial selecionar a atividade de testes que melhor se adequa ao projeto/produto. Implementar uma solu??o de testes automáticos está longe de ser uma atividade out of the box, pelo contrário, requer capacidades técnicas específicas ao nível do uso da ferramenta de automa??o e know-how próprio para operacionalizar o esfor?o de testes pela equipa.

Os “Três Tópicos” que abaixo documento sobre Testes Automáticos, partilho-os de forma franca com a comunidade, sendo subprodutos de um estudo pessoal intenso, da minha experiencia profissional e de alguma troca de ideias com colegas.

• Condi??es iguais, resultados iguais.
  • O processo de automa??o de um Caso de Teste (CT) deverá ter sob controlo as variáveis ambiente. Um procedimento que permite atingir este objetivo é a clonagem do ambiente onde se realizam os testes (se possível, incluindo a ferramenta a usar na automa??o) com posterior distribui??o dos clones/cópias pela equipa de testes. O procedimento atrás referenciado n?o só acelera o processo, como em simultaneo garante que os CT’s criados interagem homogeneamente com as mesmas configura??es de sistema, seja do Sistema Operativo, seja ao nível do Browser, seja na intera??o com aplica??es de terceiros; como as aberturas de leitores de PDF. Em termos de output de teste, a solu??o apresentada permite contornar os falsos Failed das execu??es. Estes resultados anómalos e indesejáveis poderiam ocorrer ao serem incluídas no processo de automa??o intera??es n?o documentadas com plataformas ou objetos e que surgiram num dado momento na máquina X. Por sua vez, a máquina Y com fun??es de execu??o dos CT, ao tentar correr esse CT obteria problemas no reconhecimento das plataformas/objetos dado n?o conter as mesmas condi??es para o reproduzir.
  • Os sistemas informáticos, n?o raras as vezes, têm como premissa concetual a sua utiliza??o sob o binómico Utilizadores/Permiss?es. Deve ser estudado inicialmente se no processo de automa??o a utiliza??o de usernames diferenciados no acesso ao sistema em testes, é neutro para o objetivo dos testes ou resulta numa automatiza??o personalizada que condiciona a forma/intera??es como se alcan?a o objetivo da valida??o funcional. Se o objetivo do teste for condicionado pelo uso do username a solu??o recomendável poderá traduzir-se na centraliza??o de todos os acessos com um único username, sendo este partilhado por toda a equipa de testes, incluindo os rob?s que executam os CT’s.
  • Ao aglutinar vários parametros necessários para a execu??o de um CT num repositório comum é facilitado o processo de update e propaga??o da altera??o. Por exemplo, se a op??o do projeto for ter apenas um username (como indicado no tópico anterior), este dado pode ser gravado num ficheiro txt ou xml, e tanto pode ser utilizado por 1 CT como para 100 CT. No entanto, e independente do número de CT que alimenta, se por algum motivo tiver de ser alterado, basta fazer o update num único local.
  • Numa abordagem classista, como no modelo em cascata (ou em “V”), poderíamos ainda referir que a aplica??o alvo do processo de automatiza??o deverá estar madura do ponto de vista dos testes, i.e., n?o deve ser o processo de automatiza??o o primeiro ponto de contacto com a área dos testes. Tipicamente os testes automáticos servem para aferir que novas funcionalidades n?o estragam anteriores (testes de regress?o). Sob uma perspetiva diferente oriunda das metodologias ágeis e que têm ganho express?o no desenvolvimento de software na atualidade, somos remetidos para uma assun??o que a automatiza??o ocorre desde o início o processo. Porém muitos autores dizem que apenas um processo de automatiza??o com uma abordagem keyword-driven (action word based testing) poderá ser flexível o suficiente para acompanhar as rápidas mudan?as de requisitos que este tipo de metodologia de desenvolvimento de software tenta corresponder.
• Calendariza??o
  • Criar e Executar CT em diferentes períodos apresenta vantagens. Abaixo algumas notas justificam o planeamento de uma calendariza??o.
  • Durante as execu??es dos Casos de Teste Automáticos (CTA) alguns podem estar programados para guardar variáveis em cache com a predestina??o de ser usadas noutros CTA. N?o existindo uma calendariza??o da sua execu??o o risco de serem usados por terceiros (exemplo testers a executar CT manuais) e por isso inutilizados é grande. é também comum constituir-se sequências de casos de teste que repliquem um fluxo de negócio com as várias intera??es no mesmo dado em sistema CRUD (create, read, update and delete) ou BREAD (Browse, Read, Edit, Add, Delete).
  • Todas as aplica??es (sejam web ou standalone) existem sob uma infraestrutura que pode ter acessos sobrelotados em algum momento. A calendariza??o das execu??es poderá servir vários objetivos: a) validar que do ponto de vista funcional o sistema está correto pelo que a execu??o deve ocorrer num período de menor uso para evitar falsos fails, ou b) validar pelas características n?o funcionais quais os períodos de carga no sistema e quais as funcionalidades que perdem parcialmente ou totalmente a sua utiliza??o.
• Robustez e Redundancia
  • Um Caso de Teste Automático na sua génese tem de ser robusto tanto nas valida??es funcionais como a imprevistos sem origem definida. Para aplicar corretamente estes princípios devemos utilizar no CTA as fun??es ao nível da ferramenta que melhor se adaptem. Dois exemplos:
    • A fun??o assert() falha o teste caso a característica n?o tenha as mesmas propriedades expectáveis ao contrário do verify() que deixa os restantes passos serem executado (ferramenta: Selenium WebDriver).
    • Preferencialmente deve-se utilizar um WaitProperty em vez de um Wait (genérico) (ferramenta: HP Unified Functional Testing [UFT] / QuickTest Professional [QTP]). No primeiro caso, o rob? está programado para aguardar até o objeto/característica “expectável” seja confirmado sendo só consumido o tempo entre o início da instru??o e o tempo da confirma??o, dentro de timeout máximo configurado. Ao contrário uma fun??o genérica de Wait tem um valor fixo de “aguarda” e utiliza-o na totalidade, com a agravante de o objeto/característica alcan?ar o resultado expectável do teste, como o contrário.
  • No script de execu??o poder?o ser previstos comportamentos úteis à execu??o de teste independente do CTA que seja executado.
    • Always Finds the Error. Poderá ser implementado em todos os momentos o surgimento uma label com a inscri??o “error”, em qualquer tipo de objeto com vista a encontrar erros n?o previstos e para a) chumbar o teste ou b) desbloquear o sistema e tentar continuar a testar o fluxo de negócio automatizado. Um caso prático de implementa??o desta funcionalidade, é se estivermos a funcionar sobre um browser, é replicar o processo de fazer uma pesquisa por uma palavra Error em cada step Assim, e dependente da negocio subjacente ao teste todas estas situa??es falham o CT imediatamente ou por outro lado procuram encontrar um bot?o “x” close ou um bot?o “ok” e tentam continuar fluxo de teste.
    • Clean environment. Nas execu??es em massa, os CTA que encontram resultados negativos podem deixar o ambiente de teste com objetos derivados da situa??o de erro, logo n?o existentes em condi??es normais ou ainda deixar a plataforma instável. Estes dois tipos de outputs podem condicionar a execu??o seguinte de CTA e resultar num falso “fail”. Mais uma vez pode ser codificado ao nível do script uma “limpeza” (de janelas por exemplo) ou “restart de servi?os essenciais” entre cada execu??o de CTA.