ptcmariano · October 18, 2012 02:35
diff --git a/TCC_ATDD.txt b/TCC_ATDD.txt
 Bacharelando de Ciência da Computação da Universidade de Sorocaba. Paulo Tiago Castanho Mariano.


 Resumo
 Teste de aceitação é o conceito chave para as atuais equipes ágeis que trabalham com Desenvolvimento Dirigido ao Comportamento (Behavior Driven Development - BDD). Esse trabalho tem como foco exibir as atuais formas de trabalho dentro dessa metodologia e demonstrar como uma ferramenta pode ser aproveitada para essa área de desenvolvimento, definir o comportamento do sistema e garantir que esse comportamento será entregue através de testes automatizados de software.
 
 Introdução.

 Um sistema de informação é uma combinação de pessoas, dados, processos, interfaces, redes de comunicação e tecnologia que interagem com o objetivo de dar suporte e melhorar o processo de negócio de uma organização empresarial com relação às informações que nela fluem, segundo (Bezerra, 2006).

 Nesse trabalho de conclusão de curso do bacharelado em ciência da computação, apresenta-se uma análise dos processos de desenvolvimento de software e a criação de uma estrutura de um sistema para aplicação de uma técnica em teste de software, denominada Teste de Aceitação. O trabalho prossegue demonstrando como utilizar a ferramenta AutoIt3 para que o teste de aceitação seja realizado.

 O tema foi escolhido devido à relevância na atualidade, para os meios acadêmicos, científicos e comerciais, de se desenvolver sistemas confiáveis e o mais rápido possível. O cenário de desenvolvimento de sistema pode estar imprevisível, onde uma funcionalidade adicionada ao sistema pode gerar erros (Rspec ). Muitos parecem não estar conscientes do arsenal de práticas e ferramentas disponíveis para enfrentar esses desafios (Acc guide). Justifica-se, nessas ocasiões, entender uma cobertura de testes automatizados que garantam mudanças estáveis. 

 O objetivo do trabalho, assim, é descrever como uma equipe precisa se formar e o que é necessário para criar testes de aceitação que garantam a funcionalidade do sistema.

 A formação da equipe está descrita nas metodologias citadas pelo trabalho. Para servir à prática dos Teste de Aceitação foi utilizada a ferramenta open source Autoit3, para a qual anexa-se um resumo com instruções de uso.

 No primeiro capítulo o trabalho mostra o contexto em que as equipes de desenvolvimento passaram durante as décadas passadas.
 No segundo capítulo foi descrito as metodologias utilizadas em desenvolvimento de software para exemplificar o contexto em que são utilizados testes de aceitação.
 O terceiro capítulo demonstrou o componente humano, ou seja, as pessoas que participam do processo e qual papel de cada um para o resultado.
 O quarto capitulo passou os conceitos de Desenvolvimento Dirigido ao Comportamento, bem como as práticas comum de teste de aceitação.
 O quinto capítulo descreveu a ferramenta usada para a automação de teste de aceitação, também discriminou a estrutura utilizada para a interpretação das estórias de usuário.
 O sexto capítulo mostrou a conclusão e os resultado obtido com o estudo aplicado ao desenvolvimento da estrutura necessária.


 Capitulo 1 - Evolução da qualidade e teste de software e suas definições
 Durante as diversas décadas de desenvolvimento de sistemas, esses foram se modificando conforme cada contexto, [Bezerra, 2006] define histórico de como os sistemas eram modelados:
 Décadas de 1950/60 – os sistemas de software eram bastante simples. O desenvolvimento desse sistema era feito de forma “direto ao assunto”. Os sistemas eram significativamente mais simples e, consequentemente, as técnicas de modelagem também eram mais simples: era a época dos fluxogramas e diagramas de módulos.
 Década de 1970: nessa época, computadores mais avançados e acessíveis começaram a surgir. Houve uma grande expansão do mercado computacional. Sistemas mais complexos começavam a surgir. Por conseguinte, modelos mais robustos foram propostos. Nesse período, surgem a programação estruturada e o projeto estruturado. Os autores Larry Constantine e Edward Yourdon são grandes colaboradores nessas técnicas.
 Década de 1980: nessa fase os computadores se tornaram ainda mais avançados e baratos. Surge a necessidade por interfaces mais sofisticadas, o que originou a produção de sistemas mais complexos. A Análise Estruturada surgiu no início deste período com os trabalhos de Edward Yourdon, Peter Coad, Tom DeMarco, James Martin e Chris Gane.
 Início da Década de 1990: esse período em que surge um novo paradgima de modelagem, a Análise Orientada a Objetos. Grandes colaboradores deste paradgma são Sally Shlaer, Stephen Mellor, Rebecca Wirfs-Brock, James Rumbaugh, Grady Booch e Ivan Jacobson.
 Fim da Década de 1990: o paradigma da orientação a objetos atinge sua maturidade. Os conceitos de padrões de projeto, frameworks, componentes e qualidade começam a ganhar espaço.

 Nas três primeiras décadas da era do computador, o principal desafio era desenvolver hardware que reduzisse o custo de processamento e armazenagem de dados. Efetivado isto, o foco voltou-se para o software, e o desafio tornou-se melhorar a qualidade de reduzir o custo de soluções baseadas em computador, de ANA PAULA (200X) citando  (PRESSMAN, 1995).

 Diante deste contexto, onde passamos por diversas décadas com desenvolvimento de software, o trabalho tratando de qualidade e teste de software, se faz necessário definições formais de qualidade e teste.

 Para Molinari (2008) a engenharia de software é mostrada como uma grande ciência, uma área de construção e gerência de projetos de software. Quando olhamos mais afundo, veremos que esta tem uma área de Qualidade. Dessa forma, a Engenharia de Software, por sua vez, tem internamente o que é chamado de Garantia de Qualidade ou QA (Quality Assurance).
 Quando falamos de software, estamos falando de GQS (Garantia da Qualidade de Software) ou SQA (Software Quality Assurance). Teste é uma área importante devido ao seu crescente destaque durante os últimos anos.
 Teste é uma área da Engenharia de Software e tem como objetivo aprimorar a produtividade e fornecer evidências da confiabilidade e da qualidade do software em complemento a outras atividades de garantia de qualidade ao longo do processo de desenvolvimento de software.

 E Molinari (2008) descreve definições formais de qualidade conforme a seguir.
 IEEE 610.12 1990 (Glossário de Termos de Engenharia de Software) – qualidade são sistemas, componentes ou processos que seguem os requisitos e atendem a necessidade do usuário.
 ISSO 9003-3-1991 (Guia de Aplicação da ISSO 9001 para Desenvolvimento, Entrega e Manutenção de Software): “totalidade de características e funções de um produto ou serviço que habilitem a satisfação de necessidades implícitas ou específicas”
 
 Sendo para Kaner (2001) uma definição voltada para aplicação. “O teste de software é feito para localizar informações, decisões críticas sobre o projeto ou o produto são tomadas com base nessas informações”.
 Kaner, Cem; James Bach e Bret Pettichord. 2001. Lessons Learned in Software Testing. Wiley.

 O teste é tratado diversas vezes para as decisões de um projeto de software. Esse trabalho trata especificamente do teste de aceitação, essa especialidade é tratada no próximo capítulo.

 Capitulo 2 - Teste de aceitação e processo de aceitação
 Da forma em que o teste de software faz parte da decisão tomada em uma projeto de software. A aceitação de software envolve teste de aceitação, mas esse processo é maior, segundo o Melnik (2009). Que também define teste de aceitação como o conjunto de atividades para reunir informações necessárias para tomar a decisão: “Esse software está preparado para mim (ou para meu cliente) e cumpri meu requisito”.

 Para Mayers (2004) existe uma referência direta entre o que o desenvolvedor faz durante o desenvolvimento do software e o que o testador faz durante o teste de software, vide imagemNN. E afirma que teste de aceitação é o processo que compara o programa com os requisitos iniciais e as necessidades atuais dos usuários finais. Evidenciando, um comum acordo entre a equipe e o cliente, para decisões sobre o produto.

 Para Pugh (2011) testes de aceitação define a funcionalidade de um programa. Mas pode ser usado como complemento de: mensurar o entregue, auxiliar estimativas e quebrar requisitos de software.

 O teste de aceitação sendo uma decisão tomada pelo cliente (ou representante dos clientes) diante do produto apresentado pela equipe que desenvolveu, se faz necessário um reunião onde a equipe mostra o que foi desenvolvido para o cliente. Essa reunião está muito relacionada com o contexto da equipe, do produto e dos clientes, portanto esse trabalho relaciona os  modelos citados nas referências. Cada equipe vai trabalhar para que os modelos se encaixe em seu contexto. Para usar os conceitos é preciso seguir um caminho para o aprendizado dos princípios, conforme a imagemNN.


 Como teste de aceitação é um parte do desenvolvimento de software, existe a relação entre cliente e a equipe. A imagemNN refere-se de maneira geral como é concebido o software e a relação entre o cliente e a equipe.


 Os modelos do processo de aceitação é um conjunto de outros modelos que envolve as decisões em cada campo da aceitação. Melkins (2009) demonstra na imagemNN que os modelos que influencia na processo de decisão sobre o produto são: Modelo do processo de aceitação de software, Modelo do processo de tomada de decisão, Modelo de contexto do produto, Modelo dos requisitos de sistema, Modelo de resolução de problemas, Modelo de risco e Modelo de aprontamento. Imagem NN ilustra o relacionamento entre os modelos.




 Ao construir o Modelo do processo de aceitação de software é elaborado o Modelo do processo de tomada de decisão que descreve as atividades chave e os passos de como o sistema-sobre-teste caminha dos requisitos ao produto acabado, também descreve quem toma as decisões e quem provê os dados para essas decisões.



 O processo de aceitação trabalha melhor quando o dono do produto


 Capítulo Ferramenta

 AutoIt versão 3 é uma ferramenta freeware de linguagem script de formato BASIC desenhado para automatizar tarefas de interface com usuário Windows e de uso geral. Esta ferramenta usa uma combinação de simulações em teclas, movimentos do mouse, manipulação e controle de janelas a fim de automatizar tarefas em uma forma não possível ou fiável com outras linguagens (exemplo VBScript e SendKeys). AutoIt é também muito pequena, auto-suficiente e roda nas versões regulares do windows até hoje, sem exigir problemas em tempo de execução.

 As características da ferramenta é uma lista de benefícios a quem busca automação de interface com usuário, sendo as principais: Amplo conjunto de funções; aprendizado fácil da sintaxe; simula movimentos do mouse e precionamento de teclas; manipula janelas e processos; interage com todos contoles de janela padrão; scripts pode ser compilado em executáveis; suporta COM e expressões regulares.

 Essa ferramenta é comumente usada para tarefas repetitivas de interface com usuário. Testadores que precisam fazer uma rotina diversas vezes ao dia pode usar essa ferramenta para agiliar o processo.

 Quando optar por essa ferramenta
 As vantagens identificadas, se relaciona com o momento de usar. Para as equipes que já tem um sistema em andamento e desejam aplicar técnicas para garantir a qualidade. A ferramenta pode apoiar se utilizar os conceitos dos capítulos 2 e 3 , também  aplicando na estrutura a seguir.

 Como foi usada para testes de aceitação (instruções de uso para aceitação)

 A estrutura de automação foi centralizada em um Arquivo chamado Accpetance.au3. Esse arquivo central contém uma função AnalyseLine que recebe um argumento sendo cada linha a ser analisada do arquivo de aceitação. A interpretação é feita por comparação, cada linha é verificada a existência das palavras-chave, caso exista chama um comando de ação.

 O arquivo de ação está nomeado como Action.au3, este contém funções de ação com objeto do navegador para controle das atividades.
	Bacharelando de Ciência da Computação da Universidade de Sorocaba. Paulo Tiago Castanho Mariano.


	Resumo
	Teste de aceitação é o conceito chave para as atuais equipes ágeis que trabalham com Desenvolvimento Dirigido ao Comportamento (Behavior Driven Development - BDD). Esse trabalho tem como foco exibir as atuais formas de trabalho dentro dessa metodologia e demonstrar como uma ferramenta pode ser aproveitada para essa área de desenvolvimento, definir o comportamento do sistema e garantir que esse comportamento será entregue através de testes automatizados de software.

	Introdução.

	Um sistema de informação é uma combinação de pessoas, dados, processos, interfaces, redes de comunicação e tecnologia que interagem com o objetivo de dar suporte e melhorar o processo de negócio de uma organização empresarial com relação às informações que nela fluem, segundo (Bezerra, 2006).

	Nesse trabalho de conclusão de curso do bacharelado em ciência da computação, apresenta-se uma análise dos processos de desenvolvimento de software e a criação de uma estrutura de um sistema para aplicação de uma técnica em teste de software, denominada Teste de Aceitação. O trabalho prossegue demonstrando como utilizar a ferramenta AutoIt3 para que o teste de aceitação seja realizado.

	O tema foi escolhido devido à relevância na atualidade, para os meios acadêmicos, científicos e comerciais, de se desenvolver sistemas confiáveis e o mais rápido possível. O cenário de desenvolvimento de sistema pode estar imprevisível, onde uma funcionalidade adicionada ao sistema pode gerar erros (Rspec ). Muitos parecem não estar conscientes do arsenal de práticas e ferramentas disponíveis para enfrentar esses desafios (Acc guide). Justifica-se, nessas ocasiões, entender uma cobertura de testes automatizados que garantam mudanças estáveis.

	O objetivo do trabalho, assim, é descrever como uma equipe precisa se formar e o que é necessário para criar testes de aceitação que garantam a funcionalidade do sistema.

	A formação da equipe está descrita nas metodologias citadas pelo trabalho. Para servir à prática dos Teste de Aceitação foi utilizada a ferramenta open source Autoit3, para a qual anexa-se um resumo com instruções de uso.

	No primeiro capítulo o trabalho mostra o contexto em que as equipes de desenvolvimento passaram durante as décadas passadas.
	No segundo capítulo foi descrito as metodologias utilizadas em desenvolvimento de software para exemplificar o contexto em que são utilizados testes de aceitação.
	O terceiro capítulo demonstrou o componente humano, ou seja, as pessoas que participam do processo e qual papel de cada um para o resultado.
	O quarto capitulo passou os conceitos de Desenvolvimento Dirigido ao Comportamento, bem como as práticas comum de teste de aceitação.
	O quinto capítulo descreveu a ferramenta usada para a automação de teste de aceitação, também discriminou a estrutura utilizada para a interpretação das estórias de usuário.
	O sexto capítulo mostrou a conclusão e os resultado obtido com o estudo aplicado ao desenvolvimento da estrutura necessária.


	Capitulo 1 - Evolução da qualidade e teste de software e suas definições
	Durante as diversas décadas de desenvolvimento de sistemas, esses foram se modificando conforme cada contexto, [Bezerra, 2006] define histórico de como os sistemas eram modelados:
	Décadas de 1950/60 – os sistemas de software eram bastante simples. O desenvolvimento desse sistema era feito de forma “direto ao assunto”. Os sistemas eram significativamente mais simples e, consequentemente, as técnicas de modelagem também eram mais simples: era a época dos fluxogramas e diagramas de módulos.
	Década de 1970: nessa época, computadores mais avançados e acessíveis começaram a surgir. Houve uma grande expansão do mercado computacional. Sistemas mais complexos começavam a surgir. Por conseguinte, modelos mais robustos foram propostos. Nesse período, surgem a programação estruturada e o projeto estruturado. Os autores Larry Constantine e Edward Yourdon são grandes colaboradores nessas técnicas.
	Década de 1980: nessa fase os computadores se tornaram ainda mais avançados e baratos. Surge a necessidade por interfaces mais sofisticadas, o que originou a produção de sistemas mais complexos. A Análise Estruturada surgiu no início deste período com os trabalhos de Edward Yourdon, Peter Coad, Tom DeMarco, James Martin e Chris Gane.
	Início da Década de 1990: esse período em que surge um novo paradgima de modelagem, a Análise Orientada a Objetos. Grandes colaboradores deste paradgma são Sally Shlaer, Stephen Mellor, Rebecca Wirfs-Brock, James Rumbaugh, Grady Booch e Ivan Jacobson.
	Fim da Década de 1990: o paradigma da orientação a objetos atinge sua maturidade. Os conceitos de padrões de projeto, frameworks, componentes e qualidade começam a ganhar espaço.

	Nas três primeiras décadas da era do computador, o principal desafio era desenvolver hardware que reduzisse o custo de processamento e armazenagem de dados. Efetivado isto, o foco voltou-se para o software, e o desafio tornou-se melhorar a qualidade de reduzir o custo de soluções baseadas em computador, de ANA PAULA (200X) citando (PRESSMAN, 1995).

	Diante deste contexto, onde passamos por diversas décadas com desenvolvimento de software, o trabalho tratando de qualidade e teste de software, se faz necessário definições formais de qualidade e teste.

	Para Molinari (2008) a engenharia de software é mostrada como uma grande ciência, uma área de construção e gerência de projetos de software. Quando olhamos mais afundo, veremos que esta tem uma área de Qualidade. Dessa forma, a Engenharia de Software, por sua vez, tem internamente o que é chamado de Garantia de Qualidade ou QA (Quality Assurance).
	Quando falamos de software, estamos falando de GQS (Garantia da Qualidade de Software) ou SQA (Software Quality Assurance). Teste é uma área importante devido ao seu crescente destaque durante os últimos anos.
	Teste é uma área da Engenharia de Software e tem como objetivo aprimorar a produtividade e fornecer evidências da confiabilidade e da qualidade do software em complemento a outras atividades de garantia de qualidade ao longo do processo de desenvolvimento de software.

	E Molinari (2008) descreve definições formais de qualidade conforme a seguir.
	IEEE 610.12 1990 (Glossário de Termos de Engenharia de Software) – qualidade são sistemas, componentes ou processos que seguem os requisitos e atendem a necessidade do usuário.
	ISSO 9003-3-1991 (Guia de Aplicação da ISSO 9001 para Desenvolvimento, Entrega e Manutenção de Software): “totalidade de características e funções de um produto ou serviço que habilitem a satisfação de necessidades implícitas ou específicas”

	Sendo para Kaner (2001) uma definição voltada para aplicação. “O teste de software é feito para localizar informações, decisões críticas sobre o projeto ou o produto são tomadas com base nessas informações”.
	Kaner, Cem; James Bach e Bret Pettichord. 2001. Lessons Learned in Software Testing. Wiley.

	O teste é tratado diversas vezes para as decisões de um projeto de software. Esse trabalho trata especificamente do teste de aceitação, essa especialidade é tratada no próximo capítulo.

	Capitulo 2 - Teste de aceitação e processo de aceitação
	Da forma em que o teste de software faz parte da decisão tomada em uma projeto de software. A aceitação de software envolve teste de aceitação, mas esse processo é maior, segundo o Melnik (2009). Que também define teste de aceitação como o conjunto de atividades para reunir informações necessárias para tomar a decisão: “Esse software está preparado para mim (ou para meu cliente) e cumpri meu requisito”.

	Para Mayers (2004) existe uma referência direta entre o que o desenvolvedor faz durante o desenvolvimento do software e o que o testador faz durante o teste de software, vide imagemNN. E afirma que teste de aceitação é o processo que compara o programa com os requisitos iniciais e as necessidades atuais dos usuários finais. Evidenciando, um comum acordo entre a equipe e o cliente, para decisões sobre o produto.

	Para Pugh (2011) testes de aceitação define a funcionalidade de um programa. Mas pode ser usado como complemento de: mensurar o entregue, auxiliar estimativas e quebrar requisitos de software.

	O teste de aceitação sendo uma decisão tomada pelo cliente (ou representante dos clientes) diante do produto apresentado pela equipe que desenvolveu, se faz necessário um reunião onde a equipe mostra o que foi desenvolvido para o cliente. Essa reunião está muito relacionada com o contexto da equipe, do produto e dos clientes, portanto esse trabalho relaciona os modelos citados nas referências. Cada equipe vai trabalhar para que os modelos se encaixe em seu contexto. Para usar os conceitos é preciso seguir um caminho para o aprendizado dos princípios, conforme a imagemNN.


	Como teste de aceitação é um parte do desenvolvimento de software, existe a relação entre cliente e a equipe. A imagemNN refere-se de maneira geral como é concebido o software e a relação entre o cliente e a equipe.


	Os modelos do processo de aceitação é um conjunto de outros modelos que envolve as decisões em cada campo da aceitação. Melkins (2009) demonstra na imagemNN que os modelos que influencia na processo de decisão sobre o produto são: Modelo do processo de aceitação de software, Modelo do processo de tomada de decisão, Modelo de contexto do produto, Modelo dos requisitos de sistema, Modelo de resolução de problemas, Modelo de risco e Modelo de aprontamento. Imagem NN ilustra o relacionamento entre os modelos.




	Ao construir o Modelo do processo de aceitação de software é elaborado o Modelo do processo de tomada de decisão que descreve as atividades chave e os passos de como o sistema-sobre-teste caminha dos requisitos ao produto acabado, também descreve quem toma as decisões e quem provê os dados para essas decisões.



	O processo de aceitação trabalha melhor quando o dono do produto


	Capítulo Ferramenta

	AutoIt versão 3 é uma ferramenta freeware de linguagem script de formato BASIC desenhado para automatizar tarefas de interface com usuário Windows e de uso geral. Esta ferramenta usa uma combinação de simulações em teclas, movimentos do mouse, manipulação e controle de janelas a fim de automatizar tarefas em uma forma não possível ou fiável com outras linguagens (exemplo VBScript e SendKeys). AutoIt é também muito pequena, auto-suficiente e roda nas versões regulares do windows até hoje, sem exigir problemas em tempo de execução.

	As características da ferramenta é uma lista de benefícios a quem busca automação de interface com usuário, sendo as principais: Amplo conjunto de funções; aprendizado fácil da sintaxe; simula movimentos do mouse e precionamento de teclas; manipula janelas e processos; interage com todos contoles de janela padrão; scripts pode ser compilado em executáveis; suporta COM e expressões regulares.

	Essa ferramenta é comumente usada para tarefas repetitivas de interface com usuário. Testadores que precisam fazer uma rotina diversas vezes ao dia pode usar essa ferramenta para agiliar o processo.

	Quando optar por essa ferramenta
	As vantagens identificadas, se relaciona com o momento de usar. Para as equipes que já tem um sistema em andamento e desejam aplicar técnicas para garantir a qualidade. A ferramenta pode apoiar se utilizar os conceitos dos capítulos 2 e 3 , também aplicando na estrutura a seguir.

	Como foi usada para testes de aceitação (instruções de uso para aceitação)

	A estrutura de automação foi centralizada em um Arquivo chamado Accpetance.au3. Esse arquivo central contém uma função AnalyseLine que recebe um argumento sendo cada linha a ser analisada do arquivo de aceitação. A interpretação é feita por comparação, cada linha é verificada a existência das palavras-chave, caso exista chama um comando de ação.

	O arquivo de ação está nomeado como Action.au3, este contém funções de ação com objeto do navegador para controle das atividades.