6º Encontro Mensal da ALATS-SP

Pessoal,

O tema do 6º encontro mensal, promovido pela ALATS-SP, será “Agile e Scrum – O Tsunami da Agilidade na Praia dos Testes: Novos Modelos, Novas Ferramentas”, apresentado pelo Jorge Diz, Mestre em Engenharia Elétrica e Bacharel em Ciência da Computação, ambos pela UNICAMP.

Acredito que será uma excelente oportunidade para compreender melhor a influência que as metodologias e práticas ágeis podem ter na nossa área, assim como trocar experiências sobre o assunto.

Segue abaixo, maiores informações sobre o encontro, retiradas da página da ALATS-SP:

Data: 30 de setembro (quarta-feira)
Horário: 18:30 – 22:00
Local: Av. Paulista, 726 – 17º andar conj. 1707D – próximo a estação de metro Brigadeiro

Objetivo:

Aumentar o contato entre profissionais da área de Teste de Software e Garantia da Qualidade, bem como estimular a troca de conhecimentos, experiências e práticas de sucesso.

Tema do Encontro:

Agile e Scrum – O Tsunami da Agilidade na Praia dos Testes: Novos Modelos, Novas Ferramentas.

Conteúdo:

O modelo de desenvolvimento ágil sacode muitas das confortáveis premissas nas quais se baseava o desenvolvimento de sistemas até poucos anos atrás. A gestão da qualidade de software em geral, e as disciplinas de teste em particular, passam a ser afetadas substancialmente por este novo modelo:muda a inserção do profissional de testes dentro do processo, muda a importância relativa das técnicas de teste, muda a forma e o foco da gestão.

Novos focos e novas necessidades inspiram novas ferramentas. Paradoxalmente, coube aos desenvolvedores ágeis investir grande esforço em ferramental específico para testes e qualidade, mas os profissionais de testes e qualidade não têm participado ativamente deste processo.

Na primeira parte desta palestra, serão apresentadas as premissas do teste de software num contexto ágil, discutindo
como as mudanças do modelo afetam o perfil do profissional de testes do ponto de vista da gestão, da adoção da automação, das novas capacidades e habilidades necessárias, e dos papéis dentro da organização de desenvolvimento.

Na segunda parte, serão apresentadas novas ferramentas de teste originadas na comunidade ágil para suportar as necessidades de teste automatizado: bibliotecas para teste unitário, dublês de teste, (acceptance-)test-driven development, behavior-driven development, arquiteturas para favorecer a testabilidade, linguagens específicas de domínio e inserção do teste automatizado na integração contínua.

Agenda:

18:30 Credenciamento e networking entre os participantes
19:00 Início da palestra
20:00 Coffee break e networking
20:30 Continuação da palestra
21:30 Espaço aberto para discussão de temas da ALATS e da comunidade de Qualidade de Software em geral
22:00 Encerramento

Palestrante:
Jorge Diz, Mestre em Engenharia Elétrica e Bacharel em Ciência da Computação, ambos pela UNICAMP.

Consultor com mais de 25 anos de experiência em tecnologia da informação, abrangendo desenvolvimento, testes, requisitos, liderança de projetos, pesquisa tecnológica e ensino. Atuou principalmente nos setores financeiro e de telecomunicações, em grandes empresas.

Começou a trabalhar com testes em 1994 e a estudar metodologias ágeis em 2000. Apresenta frequentemente palestras sobre tecnologia Java, testes e metodologia em eventos técnicos e acadêmicos, incluindo várias edições do JustJava e XP Brasil. Foi responsável pela trilha de metodologias no TDC (The Developers´ Conference) 2008 em São Paulo.

Atualmente é instrutor na Globalcode, onde se especializou em treinamento de teste de software baseado em ferramentas open source para times ágeis. Possui as certificações CSM, SCJP e SCWCD.

Inscrições:

– Associados ALATS: R$ 25,00
– Não Associados: R$ 30,00

A participação na palestra Vale 3 PDTS para a renovação da CBTS
Reserve pelo e-mail sp@alats.org.br

Fique por dentro das novidades, assine o feed do QualidadeBR.

Anúncios

Para que testar?

Antes de trabalhar com Teste de Software, eu nem sabia que existia essa área, e acredito que mesmo com o crescimento que a nossa área teve nos últimos anos, ainda há muitas pessoas que não devem ter conhecimento que uma das áreas necessária para o desenvolvimento de um software é a de Teste de Software. E falo isso, principalmente pensando nos jovens que estão se formando nas faculdades, pois eu mesmo não tive uma matéria sobre Teste de Software na faculdade e muito menos praticava TDD nas muitas aulas que tive de programação, passando desde Pascal até Java. E olha que não faz tanto assim que me formei, para ser mais preciso irá completar 1 ano no final de dezembro desse ano.

Vários outros amigos meus, que estudaram em outras faculdades não tiveram tal matéria na grade do curso. Costumo até brincar com o pessoal falando que na faculdade eu só aprendi o que é teste de caixa branca e caixa preta, e foi isso mesmo. Não me disseram que existia uma área que poderia ser responsável pelos testes, quando é necessário testar, como testar, como escrever um caso de teste, como realizar o planejamento, quais técnicas posso usar, e tantas outras dúvidas que tive quando iniciei na área.

E com certeza, essa pergunta “Para que testar?” pode gerar muitas respostas diferentes, dependendo do ponto de vista e do conhecimento da pessoa. E uma das formas de responder essa pergunta, eu usei aqui nesta apresentação. Mas desta vez vou usar uma outra abordagem para falar sobre o assunto, trazendo algumas questões que ajudam a explicar a razão pela qual é necessário testar um software.

Se o software compilou ele está funcionando, então pronto!?

Esse pode ser o pensamento de muitas pessoas, principalmente, daqueles estudantes que nunca ouviram falar em Teste de Software. A compilação de um programa até pode ser vista como a realização de um teste de caixa branca, afinal o compilador irá verificar se não há nenhum erro no código, por exemplo sintaxe, que impeça dele ser compilado.

Mas a compilação por si só não garante que o software esteja funcionando.

Como assim?

No mundo dos projetos de desenvolvimento de software há o famoso escopo, que especifica o que o sistema deverá fazer e o que o mesmo não deverá. E é esse documento que será o referencial do cliente quanto ao seu sistema, se ao entregar o software, algum item do escopo não tiver sido implementado, “coisas horríveis irão acontecer”.

E um dos objetivos do Teste de Software é justamente verificar se tudo que está especificado no escopo foi implementado. Tanto que ele é um dos documentos usados pelo Analista de Teste para poder originar os casos de testes, que serão executados pelos testadores.

O que aconteceria se um software não fosse testado?

Como diria um professor meu “coisas horríveis irão acontecer”. Afinal, a primeira pessoa que irá testar o seu sistema serão os clientes e usuários, e caso eles encontrem alguma inconformidade no seu sistema, o que é bem provável pensando num software que não foi testado, eles não ficaram nem um pouco satisfeitos e o preço pela inconformidade poderá ser muito alto, principalmente nos casos em que há multas contratuais.

Além disso, sistemas que não são testados em fase de desenvolvimento, costumam passar uma boa parte da sua vida pela equipe de manutenção e de suporte. Ou seja, o retrabalho gerado por um software não testado é muito alto!

Todos os softwares são testados?

Todos os softwares deveriam ser testados, mas na realidade poucos são os softwares que são testados de forma efetiva. E um dos motivos principais para que haja necessidade de ser testar algo (em qualquer realidade) é o fato que somos seres humanos, ou seja, estamos sujeito ao erro. Afinal errar é humano!

Há muitas desculpas que fazem com que um software não seja testado, dentre as principais estão:

  • Excesso de confiança dos desenvolvedores;
  • Falta de tempo para o Teste de Software;
  • Não há a cultura de realizar testes;
  • Não há pessoas capacitadas para executar os testes;
  • Desconhecimento da importância do Teste de Software;
  • Os custos com os testes não foram colocados no custo do projeto;
  • Etc.

O que é esse tal de TDD?

Comentei no começo do post sobre TDD, uma tendência muito forte no desenvolvimento do software é que já realidade em várias empresas no Brasil e no mundo. TDD é o acrônimo para Test Driven Development, que em bom português é Desenvolvimento Orientado a Testes.

A idéia é bem simples: antes de partir para o desenvolvimento da funcionalidade você irá escrever testes para ela. Isso mesmo, antes de desenvolver a funcionalidade, você irá desenvolver testes que verifiquem e validem a funcionalidade que será desenvolvida.

Daí você pode está se perguntando, mas como eu farei isso? Há alguma ferramenta que facilite esse trabalho?

Há sim, os chamados frameworks/arcabouços xUnit. Eles permitem que você desenvolva testes, chamados de testes unitários, para as diferentes unidades do seu sistema, como por exemplo funções e classes. Além disso, uma grande vantagem desses frameworks é que eles permitem que você execute os testes de forma automática.

Lembra que eu falei que quando você compila você está apenas verificando se o código que você escreveu é compilável, pois então, usando por exemplo o JUnit, um framework para Java, é possível fazer com que ao compilar o seu código os testes que você criou também sejam executados. Ou seja, você também está testando o seu software e ainda de forma automatizada! 🙂

Muitos entusiastas no TDD dizem que os testes automatizados acabam tornando-se uma documentação viva do sistema, e eles estão corretos. Num cenário com testes automatizados, sempre que for necessário realizar uma mudança, ela ser feita com tranquilidade, pois você poderá verificar se a mudança implementada não quebra nada no seu código ou não está de acordo com a documentação, apenas tendo o trabalho de apertar o botão “play” para execução dos testes criados anteriormente.

Mas lógico que para que o TDD possa trazer bons resultados os testes tem que ser bem desenvolvidos, de nada adianta criar um teste que não testa nada. E não pense que usando TDD, você não precisará realizar mais nenhum teste, pois você só está executando os testes unitários, há ainda os testes de integração, sistema e aceitação. 🙂

Conclusão

Testar um software deve ser uma tarefa comum, durante o desenvolvimento do software. Pois é uma forma de aumentar a qualidade do software, a credibilidade da empresa com os seus clientes e maximizar o lucro da empresa. Além é claro, de ser uma das práticas de empresas profissionais, que objetivam entregar uma solução que resolva os problemas dos seus clientes e não uma solução que gere mais problemas para eles.

Além disso, testar não é uma tarefa que deve ser feita só no final do desenvolvimento, até porque, podemos testar antes mesmo de desenvolver. Portanto, devemos buscar usar e conhecer as melhores práticas no nosso trabalho, dentre as quais testar é uma prática essencial. 😉

Fique por dentro das novidades, assine o feed do QualidadeBR.

O melhor da semana 30/08 a 06/09

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários.  🙂

Abraços! E tenham uma ótima semana!

Fique por dentro das novidades, assine o feed do QualidadeBR.

Automatização de testes em duas rodas

Ontem eu fiquei sabendo pelo twitter da Fernanda Thiesen a seguinte notícia: “Robô motoqueiro

Particularmente achei muito legal a notícia! Pois ilustra vários fatos, que também ocorrem no mundo do Teste de Software:

  • Teste é essencial! Ou você acharia que a Castrol iria investir (não gastar!) milhões de dólares para contratar mais de 120 cientistas e engenheiros para desenvolver o Flossie;
  • Automatizar os testes não é uma tarefa fácil! E um dos grandes problemas é não ter a ferramenta certa para a sua aplicação;
  • Há testes que somente podem ser feitos de forma automatizada;
  • Os testes de performance são de grande importância, pense nisso!
  • A coleta das informações e a análise é essencial para uma boa execução de um teste de performance!
  • Diversos tipos de testes podem ser realizados de acordo com a aplicação. A Castrol faz até teste de portabilidade!
  • Testes manuais ainda são necessários! Há cenários que somente o ser humano é capaz de realizar o teste de forma eficaz e satisfatória;
  • Testar de forma efetiva é um diferencial competitivo!

Acredito que a Castrol é um excelente estudo de caso sobre testes automatizados. E um dos pontos que acho mais interessante é fazer a “engenharia-reversa” da situação deles, para saber qual problema originou a criação do robô. Eles devem ter percebido que somente com testes automatizados, seria possível realizar testes de performance de uma maneira mais eficaz, e como essa tarefa não teria como ser feita nem pelo Valentino Rossi, a solução para o problema seria construir o Flossie. Ou seja, para automatizar os testes eles tiveram que desenvolver a sua própria ferramenta.

Flossie

Aproveitando o assunto, no Brateste desse ano pude conferir um braço mecânico que pode usado para testar software. Isso mesmo! Ele é capaz de interagir com um teclado, por exemplo. E conversando com o Marco Bassi, CEO-Grupo HDI, que investiu e incentivou o projeto, ele me disse que o braço mecânico pode automatizar uma série de testes, e abre novas possibilidades para a automatização dos testes. Um exemplo citado por ele foi de um teste com caixa-eletrônico, onde uma das ações necessárias era inserir o cartão, e que antes do braço mecânico só era possível com a ajuda de uma pessoa.

E a moral dessa história toda, é que às vezes ainda precisamos reinventar a roda, pensar em soluções criativas e inovadoras! 🙂

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

http://www.castrolmoto.com/en/home.php