Empresas no mundo inteiro têm cada vez mais dificuldade para desenvolver e entregar software de qualidade. Os desafios são vários, tais como gerenciar as expectativas do usuário e as mudanças constantes de requisitos, bem como garantir a coesão e o foco do time. Venha ver como o desenvolvimento ágil de aplicações, apoiado sobre o Scrum e o Team Foundation Server 2012, podem ajudar times de desenvolvimento a melhorar seu dia-a-dia de trabalho para entregar software de qualidade a seus clientes.
Acelerando a criação de testes usando IntelliTest (Visual Studio Summit 2015)
Scrum TFS Qualidade
1. Scrum e Team Foundation Server
Qualidade ao longo de todo o ciclo de vida da aplicação
Seminário Paranaense de Qualidade de Software
Curitiba, 29/04/2013
Igor Abade V. Leite
Igor.abade@lambda3.com.br
2. • Igor Abade (@igorabade)
– Microsoft MVP, Visual Studio ALM
– Referência nacional em
Team Foundation Server (TFS)
• Sócio-diretor da Lambda3
– Consultoria
ALM/TFS, Agilidade/Scrum, Arquitet
ura
– Desenvolvimento de Sistemas
– Treinamentos
– Parceira Microsoft Gold ALM
Sobre o Palestrante
3. Menos Teste, Mais Qualidade
Menos teste, mais qualidade
Como equilibrar a equação?
4. Menos teste?!?!
• Teste custa caro
– Novos times
– Maior tempo de projeto
• Desenvolvedores
sempre testaram
• “Sempre entreguei meus
projetos”
• Afinal, preciso mesmo
testar?
Não tenho orçamento
para montar um time
de testes
Testes de unidade? Sem
chance! Meu cliente não
vai pagar para meu time
trabalhar dobrado!
No final meu cliente vai
testar tudo de novo
mesmo...
5. Por que testar?
Exemplos práticos
• USS Yorktown, SmartShip
– Tripulante digitou 0 num campo de um formulário
– “Divide By Zero” desligou a propulsão
– Parado na água por 2h45min
• Ariane 5, vôo 501
– Reaproveitou código do Ariane 4, mas seguiu caminho
diferente devido a mudanças
– Conversão de 64bit para 16bit causou overflow
– Sem tratamento de exceções (melhor desempenho)
• F-22 Raptor
– Em operação no Japão pela primeira vez
– Cruzou Linha Internacional de Data. Computadores
travaram
– Tempo bom permitiu seguir os aviões-tanque ao Havaí
7. “temos um requisito que
mudou, o que precisamos
testar?”
Já ouviu falar disso?
“meus testers gastam
muito tempo
testando a mesma
coisa”
“ferramental é caro
(licenças, processos,
pessoas)”
“devs e testers trabalham em
‘silos’ e não falam/não se
comunicam na mesma língua”
“quando meu
sistema estará
pronto para liberar?”
“desenvolvedores dizem
que os defeitos são
inúteis”
8. • Ping-Pong entre Devs
e Testers
– Bug é “rebatido” de um
lado para o outro
– Enorme esforço
desperdiçado
• Colaboração é baixa
Colaboração com Desenvolvedores
9. • Por que um bug não é
corrigido?
– Dificuldade em
documentar passos de
reprodução do erro
– Falta de visibilidade das
ações do tester
– Diferenças de ambiente
Colaboração com Desenvolvedores
11. O mercado está cada vez mais competitivo
• Nossos clientes precisam
ir cada vez mais rápido
para o mercado.
• Usuários estão
impacientes.
• Adivinha onde vamos
cortar?
12. Controle de Qualidade de Software
• Teste é só um dos
aspectos
• Envolve processo de
desenvolvimento
• É preciso garantir
qualidade em três
momentos: Antes
Durante
Depois
13. Controle de Qualidade:
Antes
• Tudo começa com processo de
desenvolvimento
• “Fazer o certo, do jeito certo, na hora
certa”
– Desenvolvimento Ágil
– Gestão de Requisitos
– Arquitetura / Design
14. ALM: Application Lifecycle
Management
• Gestão do
Ciclo de Vida da
Aplicação
• Coordenação
– Requisitos
– Modelagem
– Desenvolvimento
– Construção
– Testes
– Manutenção e
operações
• Integração do
Time
15. Desenvolvimento Ágil:
O Manifesto Ágil
Indivíduos e interação entre eles
mais que processos e ferramentas
Software em funcionamento
mais que documentação abrangente
Colaboração com o cliente
mais que negociação de contratos
Responder a mudanças
mais que seguir um plano
Ou seja, mesmo havendo valor nos
itens à direita, valorizamos mais os
itens à esquerda.
www.manifestoagil.com.br
16. Lean
Agile
Scrum
XP
Framework de gestão ágil de projetos
Papéis e cerimônias, melhoria contínua
dos times, entrega rápida, limitar
trabalho à capacidade
Cultura ágil, mindset e práticas
Eliminar desperdício
Respeitar as pessoas, foco
principalmente em P&D
Otimizar todo o fluxo
Foco na otimização de todo o processo
de negócios
Práticas de engenharia
Trazer qualidade para dentro do desenvolvimento
– Automação, integração contínua, revisão por
pares etc.
Práticas Ágeis
22. Controle de Qualidade:
Durante
• Qualidade durante construção do código
– Testes de Unidade
– Análise de Código
– Automação de Testes
– Integração Contínua
• Processo de Testes
– Testes Manuais
– Gestão de Laboratório
25. CI:
Continuous Integration
• Integração Contínua é
uma prática
• Integrar código cedo e
com frequência, para
evitar “Integration Hell"
• Objetivo final é “parar e
consertar” o mais cedo
possível
27. Generalista Especialista
Teste Manual Poucos scripts
Cria scripts
para configurar
ambiente, criar
dados
Muitos scripts
Algum
conhecimento
de
programação
Programação
Desenvolve
rotinas de
automação de
testes
Conhecimento
avançado de
programação
Testes de “Caixa Preta”
Testes de “Caixa Branca”
Testes API
70% dos testes
acontecem aqui
Maioria das ferramentas
mira aqui
Processo de Testes
28. Execução e Automação de Testes
• Microsoft Test Manager
– Planejamento, gestão e
execução de casos de
teste
– Coleta dados de sistema
e logs de eventos
– Captura imagens de tela e
vídeos
– Fast-forward para
aplicativos Windows
Forms, WPF e Web
29. Automação de Testes de UI
• CodedUI Tests
– Gravador de Ações
– Geração a partir de casos
de teste manuais
– Scripts resilientes
– .NET (C#, VB)
– Windows
Forms, WPF, Web (IE &
Firefox), outras
plataformas
37. System Center 2012
Operations Manager
• Monitoramento em tempo real de
aplicações
– Solução de problemas na sessão do
usuário
– Coleta de dados de exceções Javascript
• Monitoração de desempenho a partir
da perspectiva do browser
– HTTP, AJAX, JavaScript
• Degradação de Desempenho
– Tamanho de HTML, imagens, scripts, CSS
– Latência de rede, desempenho do
servidor
• Informações Estatísticas
– Contadores por aplicação, página, IP
– Tempo médio de execução no
cliente, falhas/seg, etc.
It is also important to understand where most testing happens in the spectrum of general testing to the more technical specialist testing.The Generalist Testers are usually professional testers with no coding background. Often these testers are experts in the business process or tool that is being developed. On the opposite side of the spectrum is the Specialist. This is a tester with strong coding skills.A fun side note: Microsoft’s testers are usually converted developers and tend to be on the specialist side of the graph.Black-box testing is a method of testing software that tests the functionality of an application as opposed to its internal structures or workings (see white-box testing). Specific knowledge of the application's code/internal structure and programming knowledge in general is not required. Test cases are built around specifications and requirements, i.e., what the application is supposed to do. It uses external descriptions of the software, including specifications, requirements, and design to derive test cases. These tests can be functional or non-functional, though usually functional. The test designer selects valid and invalid inputs and determines the correct output. There is no knowledge of the test object's internal structure.White-box testing (a.k.a. clear box testing, glass box testing, transparent box testing, or structural testing) is a method of testing software that tests internal structures or workings of an application as opposed to its functionality (black-box testing). An internal perspective of the system, as well as programming skills, are required and used to design test cases. The tester chooses inputs to exercise paths through the code and determine the appropriate outputs. It is analogous to testing nodes in a circuit, e.g. in-circuit testing (ICT). While white-box testing can be applied at the unit, integration and system levels of the software testing process, it is usually done at the unit level. It can test paths within a unit, paths between units during integration, and between subsystems during a system level test. Though this method of test design can uncover many errors or problems, it might not detect unimplemented parts of the specification or missing requirements. White-box test design techniques include: Control flow testing Data flow testing Branch testing Path testingAPI testing (application programming interface) – is a specific type of White Box testing of the application focusing on public and private APIs<Question to Audience>Looking at this spectrum, where does most testing happen today? <collect answers and click>Where do most testing tools target today? <collect answers and click>