Non-functional Test Automation for Windows Phone Apps

Mobile applications are required to be developed in a short period of time to meet the competitive market's demands. This limitation undermines the product quality and reliability. Therefore, it is necessary to undergo a rigorous testing process not only on functional but also on non-functional requirements. This study is about automating the non-functional testing areas for the mobile applications. At the beginning manual testing is covered and after that the topic is discussed with examples from previous testing systems. This thesis presents one way to develop an automated testing system. The biggest target for this project was to reduce the test results variation, which makes it more difficult to judge the quality of the app and thus increases the risk of bad quality app being pushed to the market and reduce the test cycle by automating the manual testing process. The outcome of the study is an NFT automated testing system for the test organization. This tool tests the performance and the memory utilization of the mobile applications. The developed automated testing system is integrated to the testing process

Mapeamento de Critérios de Aceitação de Transparência de Software para Testes Automatizados

TCC(graduação) - Universidade Federal de Santa Catarina. Centro Tecnológico. Sistemas de Informação.A qualidade da informação deve ser enxergada como um dos principais pilares para o desenvolvimento organizacional. Dentre os requisitos de qualidade estão aqueles referentes à transparência de software, que definem como as informações devem ser apresentadas e como o software deve funcionar e ser desenvolvido. Com o objetivo de garantir o cumprimento destes requisitos no setor público brasileiro, foi proposta a Lei de Acesso à Informação (LAI), que estabelece regras para a publicidade das informações, demonstrando a necessidade de transparência de processos e informações das organizações públicas. Neste contexto, o presente trabalho baseou-se em requisitos não-funcionais de transparência de software definidos no checkTrans, para a criação de templates de casos de teste de aceitação abstratos escritos em Gherkin, com o intuito de avaliar o cumprimento dos requisitos em sites de organizações públicas. Para validar o trabalho, foram desenvolvidos testes automatizados com Cucumber e Selenium, utilizando os templates previamente definidos, para sites que cumpriam e que não cumpriam os requisitos testados. Após execução dos testes automatizados, concluiu-se que os templates podem servir de cenários de testes de aceitação na concepção de sites do governo.The quality information must be seen as one of the main pillars for the organizational development. Quality requirements include software transparency, which defines how information should be presented and how the software should run and be developed. In order to ensure compliance with these requirements in the Brazilian public sector, the Law on Access to Information (LAI) was proposed, which establishes rules for the disclosure of information, demonstrating the need for transparency of processes and information in public organizations. In this context, this work proposes, based on the non-functional software transparency requirements specified by the checkTrans, the creation of abstract acceptance test case templates written in Gherkin, in order to evaluate the fulfillment of requirements on public organizations' websites. To validate the work, automated tests were developed with Cucumber and Selenium, using the previously defined templates, for sites that meet and do not meet the tested requirements. After executing the automated tests, we concluded that proposed templates can serve as acceptance testing scenarios in the design of government websites

Uma abordagem ágil para transformar modelos cognitivos em modelos comportamentais e de domínio

No processo de desenvolvimento de software, um dos problemas recorrentes é garantir que as expectativas das partes interessadas (stakeholders) estão a ser satisfeitas. Expectativas essas que correspondem ao comportamento do sistema. A disciplina de Engenharia de Requisitos estuda a melhor forma de capturar, especificar, validar e gerir requisitos. No entanto, os modelos utilizados que expressam os comportamentos, muitas das vezes, não são entendidos por parte dos stakeholders. Com a introdução das metodologias ágeis, que se baseiam no princípio de uma colaboração ativa e contínua dos stakeholders durante o desenvolvimento de software, os pressupostos da disciplina de Engenharia de Requisitos foram questionados e fizeram nascer novas práticas. Uma prática que emergiu foi o Desenvolvimento Orientado ao Comportamento (BDD). Surgiu com a finalidade de dar a capacidade aos stakeholders de expressarem, sob a forma textual, o comportamento que desejam para o seu software, de forma simples e sucinta. No entanto, não existindo restrições nem validações automáticas na escrita dos stakeholders, é criada a possibilidade de introdução de ambiguidade e perda de informação quando a equipa de desenvolvimento utiliza os cenários descritos. Dado este problema, propomos uma abordagem em que os stakeholders consigam especificar cenários comportamentais, de forma cognitiva, com uma representação simples, clara e mais precisa. Criamos duas linguagens, o DomainMap e o BehaviorMap, que estão relacionadas entre si: uma para representar modelos de domínio e outra para representar cenários BDD, respetivamente. Foi executada uma experiência com 15 indivíduos para comparar o esforço cognitivo na compreensão entre cenários BehaviorMap e cenários textuais e os resultados mostraram que o BehaviorMap teve melhor desempenho