Como funcionam os Critérios de Aceitação de uma estória?

Quando terminamos a implementação de uma feature, no universo ágil, não podemos deixar de falar em critérios de aceite.

Critérios de aceitação de uma estória nada mais é que uma lista (tipo um checklist) para verificar se a estória de implementação foi feita de acordo com o que o Product Owner definiu/pediu, atendendo assim os requisitos para a utilização do usuário.

Esses critérios surgem de perguntas que a equipe de desenvolvimento faz ao PO no momento em que a estória está sendo descrita, na busca por obter mais detalhes do que deve ser implementado.

Garantir que o que foi desenvolvido irá realmente gerar valor para o cliente é um desafio, pois precisamos entender verdadeiramente quais são as suas necessidades. Trabalhar com estórias e com Critérios de Aceite bem definidos garante que possamos chegar no melhor possível a ser entregue com o projeto, gerando qualidade e aceitação daquilo que a equipe de desenvolvimento dedicou seu esforço.

Agora, vou deixar abaixo alguns critérios que são utilizados nas estórias de algumas equipes que conheço. As estórias não são fechadas se os criterios não são atendidos.

Critérios de aceite de Qualidade:

• Foram executados os roteiros testes?
• Foi feita a tradução em Inglês?
• Foi feita a tradução em Espanhol?
• Foi feito o link para URL do help?
• Foi criado o json e recurso dos novos menus?
• Foi feito teste com redimensionamento (visão monitor24', visão noteboox, visão tablet, visão celular)?
• Foram implementados os id's dos elementos?
• Foram validadas as rotinas em Chrome, Firefox e Edge?

Até mais! 😀

Quem é o QA dentro do Ágil?

Hoje de manhã eu estava lendo um artigo no caroli.org, que me fez lembrar que eu já falei aqui no blog do P.O, do Scrum Master, do System Team, mas que eu esqueci de falar do Q.A..

QA vem do inglês, Quality Analyst, e significa analista de qualidade no bom português. Este é um papel muito importante dentro das equipes que trabalham com produtos digitais ágeis. Apesar de existir um outro acrônimo de QA, que em inglês significa Quality Assurance e em português é "Garantia de Qualidade", o papel do QA aqui está mais voltado ao analista de qualidade de testes que à garantia de qualidade propriamente dita.

Qual o objetivo de um QA?

O QA, assim como o System Team, deve garantir a qualidade do produto. Mas mais do que isso, ele deve garantir que o software que estamos entregando ao cliente é exatamente o que eles querem. Uma análise aprofundada de testes é realizada. A diferença aqui para o System Team, é que o QA está dentro do projeto ágil enquanto o System Team aparece com maior evidência no final das entregas. Para saber mais sobre o System Team, clique AQUI.

O controle de qualidade parece como o trabalho no estilo "camaleão": muda de responsabilidades diárias à medida que a equipe aprende e cresce, e o projeto passa por mudanças.

O que faz um QA?

O QA ai orquestrar todos no time para garantir que essas tarefas sejam realizadas pelas pessoas mais adequadas para realizá-las. O QA é responsável por entender como  se encaixam todas as atividades relacionadas à qualidade da equipe. Lembrem-se, o teste não é mais de feito exclusivamente por um testador.

No ágil todos estão preocupados com a qualidade do produto. O QA é o especialista de conduz o produto do time à qualidade esperada.

Quais são as responsabilidades do QA?

• Análise de teste: Isso inclui análise de risco e design de teste. O QA faz análise de teste quando pensa num teste exploratório, quando está escrevendo casos de teste de regressão, quando está colaborando nos critérios de aceitação da história, quando está implementando ou mantendo testes automatizados, ou quando está decidindo quais testes de regressão não deve fazer porque não vai ter tempo.
• Estratégia de testes: Os QAs geralmente colaboram com os desenvolvedores na estratégia geral de testes da equipe, já que muitos testes, testes funcionais de baixo nível, testes de contrato de serviço, testes de UI são feitos por desenvolvedores. É importante que os esforços de automação de teste entre os QAs e os desenvolvedores se complementem, porque, de outra forma, pode haver lacunas de cobertura que introduzam riscos ou duplicações que retardam a equipe.
• Análise de negócios: os QAs podem ajudar (e muito) os analistas de negócios a definir critérios de sucesso para as histórias.
• Verificação da história – Como os desenvolvedores terminam as histórias ao longo da iteração, alguém precisa testá-las cuidadosamente para garantir que elas atendam aos critérios de aceitação e às necessidades dos usuários. A equipe confia nos QAs, pois possuem habilidades de teste: rigor e conhecimento de técnicas eficientes para encontrar erros.
• Teste manual: Antes de escrever um teste automatizado, precisamos testar as coisas manualmente para ter uma idéia de como elas funcionam e para ter uma idéia melhor do que automatizar. Esta tarefa normalmente é feita de modo aprofundado pelo QA, mas também é executada por um desenvolvedor.
• Automação de teste: Mais uma tarefa compartilhada com o desenvolvimento. Fazer testes de rotinas manualmente deixa uma grande chance de erro. Muitas vezes, é melhor se a maioria das funcionalidades importantes forem testadas automaticamente.
• Testes exploratórios: é aqui que uma QA brilha, pois tenta descobrir casos e combinações que os desenvolvedores não imaginaram ao escrever o código. Aqui o QA incorpora o usuário leigo e o especialista de negócio para encontrar bugs.
• Teste de regressão: Uma regressão é uma alteração indesejada para a funcionalidade existente. Infelizmente, a experiência que tenho como System Team mostra que as equipes ágeis cortam os testes de regressão com maior frequência do que deveriam. Esta atividade é tão importante quanto os testes exploratórios. Apesar de ser uma tarefa dos QAs, devido ao frequente corte de escopo, é aqui que o System Team brilha! ;)
• DevOps: a maioria dos testes acontece em um "Ambiente de Teste", o que muitas vezes significa que o QA é a primeira pessoa que tem uma necessidade real de um produto implantado em funcionamento. Isso às vezes significa que o QA se torna uma pessoa DevOps para a equipe, pois eles começam a solucionar as falhas de implantação por conta própria.
• Comunicação de Riscos e Defeitos: Pessoas em diferentes papéis precisam de informações diferentes sobre riscos e problemas, apresentadas de diferentes maneiras. O QA precisa ser o mais detalhista e preciso possível quando conversar com um desenvolvedor sobre um defeito.
• Liberação de tomada de decisão: O QA geralmente tem a responsabilidade de fazer, ou participar na tomada de decisões, go/no-go ou vai/não-vai, para novas funcionalidades e produtos.

Como você pode ver, é uma tonelada de coisas! Tentando fazer tudo é impossível, mas, por sorte, a qualidade é uma atividade de toda a equipe. Embora seja responsabilidade do QA garantir que as coisas aconteçam, não é necessariamente a responsabilidade deles fazer todo o trabalho!

O que um QA deve aprender para iniciar suas atividades?

A desvantagem de tudo isso é que é difícil dizer a alguém exatamente o que eles devem aprender em sua jornada como QA. O que vou propor aqui, é um compilado de vários QAs de várias empresas. Lembrem-se: isso não é uma receita de bolo, mas sim uma sugestão vinda de pessoas que já passaram pelo caminho das pedras.

1. Aprenda sobre o domínio: entender os diferentes tipos de usuários, entender o que é construído e porquê, entender como a coisa que está sendo construída é dividida em pedaços menores (épicos e histórias). Aqui você não precisa debulhar o código fonte, mas sim sentar e conversar para entender bem o produto.
2. Compreenda os princípios básicos do teste: quais são os diferentes tipos de testes, como deve ser um testador, como aplicar testes diferentes às histórias e Critérios de Aceitação.
3. Saiba documentar um defeito: aprendendo quais informações precisam ser incluídas, como funcionam as ferramentas padrão de rastreamento de erros. Existem ferramentas básicas que já falamos aqui no blog: Lightshot para corte e edição rápida de printscreens (http://bitlady.blogspot.com.br/2016/10/lightshot-uma-ferramenta-de-captura-de.html) e LICEcap ou ScreenToGif para criação de .GIFs (http://bitlady.blogspot.com.br/2017/10/licecap-e-screentogif-ferramentas-leves-para-criar-gifs.html).
4. Aprenda mais sobre o sistema operacional: muitos dos scripts, implantação e solução de problemas mais recentes que você precisa fazer dependem da sua capacidade de entender e navegar em torno do seu sistema operacional. Você precisará entender os conceitos básicos de como os principais sistemas operacionais funcionam: Windows, Linux, OS X, Android, iOS – e você precisará estar confortável trabalhando na linha de comando. Cedo ou tarde, você vai precisar. Então quanto antes se acostumar, melhor.
5. Aprenda tudo sobre o browser: (cookies, preferências de localização, browser strings, etc.)
6. Desenvolva habilidades básicas no Excel: Para testar aplicativos, eles precisam ser preenchidos com dados de teste, e o Excel é uma ferramenta extremamente comum para criar, editar e gerenciar dados de teste. Você precisará trabalhar com grandes conjuntos sem fazer alterações um por um, então aprenda as fórmulas para fazer a edição em lote. Muitas empresas usam Excel para gerenciar casos de teste também, então, quanto mais confortável você estiver com ele, mais eficiente voce será nas suas tarefas.
7. Compreenda como funciona Integração Contínua: Compreenda os princípios por trás da Integração Contínua. Saiba como funciona e o que é testado em que fase do pipeline no Git ou do TeamCity. Lembrando que você não precisa fazer, mas compreender como funciona, ajuda bastante.
8. Conheça os logs: Quando você está investigando erros, você terá que descobrir quais logs procurar, como encontrar coisas nesses logs (como abrir, pesquisar, navegar), como encontrar códigos de erro, e quando é apropriado trazer algo que você encontrar para um desenvolvedor.
9. Entenda os fundamentos da Web: seletores HTTP e HTML / DOM / CSS. Pelo menos o básico é importante.
10. Conheça alguns drivers do navegador (por exemplo, WebDriver / Selenium / Watir): Os drivers do navegador são a maneira principal de testar automaticamente as interfaces de usuário baseadas na web. 
11. Saiba os fundamentos de testes móveis: Além de emuladores e implantação de pacotes construídos para vários dispositivos, esta área fornece uma introdução natural à análise de combinações e permutações. Saiba quando repetir absolutamente tudo em cada navegador em cada dispositivo. Aprenda a técnica de teste “parwise”.

Pessoal, ninguém vem pronto para o mercado para trabalhar como QA (nem depois de 4 ou 5 anos de faculdade). Aqui estão dicas do que estudar para você melhorar suas habilidades e conseguir responder sobre a qualidade de um produto numa sprint. Além disso, no ágil todos da equipe são responsáveis pela qualidade do produto.

O que acontece depois de liberar o produto numa sprint?

De duas, uma:

ou cairá para o System Team estabilizar a versão, de modo integrado com os demais produtos, para então liberar o produto ao final de uma release;

ou você dará o OK final para colocar a versão no mercado.

Você concorda? Deixe sua opinião também!

Referências: Caroli. <http://www.caroli.org/o-que-faz-um-qa/>. Acesso em: 05/10/2017>.

Testes de software no modelo cascata e no modelo agil

Quando o modelo de desenvolvimento muda numa empresa, é possível ouvir muitas pessoas dizendo "Isso não vai dar certo" ou então "Sempre funcionou assim, para que mudar?". A transição de um modelo para outro não é fácil.

Saindo de um modelo cascata para o SAFe (framework ágil, veja outros posts sobre SAFe AQUI) foi possível observar como o processo de desenvolvimento influencia diretamente na maneira de como os testes são efetuados, e durante esta transição pode-se perceber como a qualidade do teste aumentou com a adoção dos processos ágeis. Isto devido a uma maior participação dos analistas de testes em vários níveis do desenvolvimento, e não apenas na execução como também no planejamento.

No processo cascata os testes acontecem apenas ao final de todo o ciclo de desenvolvimento, tornando assim o papel do analista de testes mais reativo. Por outro lado, em um processo ágil o analista de teste se torna mais proativo, pois está diretamente envolvido com a evolução do sistema, trabalhando junto tanto na análise da demanda como ao lado dos desenvolvedores na execução da mesma. Com isto um dos principais benefícios foi poder antecipar as possíveis falhas do que apenas se limitar a encontra-las ao final do ciclo, conforme imagem abaixo:

Modelo cascata e modelo ágil.

E então, já passaram por alguma mudança no modelo de desenvolvimento? Conta como foi!

Até mais, 😊

Referências:

CABRAL, Samuel Pierri. FERNANDES, Anita Maria da Rocha. Teste de Softwares Utilizando um Framework Ágil Escalável. UNIVALI, Florianópolis, SC, Brasil.

Teste de ponto a ponto dos sistemas pelo System Team

O System Team por vezes faz jus à expressão "pau para toda obra". Ja falei bastante sobre o System Team no post anterior AQUI, mas vamos listar aqui algumas de suas atribuições. Depois veremos se não chegamos todos a uma conclusão assim. 😉

• Participamos das releases plannings de todas as equipes onde atuamos, auxiliando no refinamento do backlog para definir a os testes das histórias;
• Criamos novos cenários de testes automatizados;
• Estendemos os cenários de testes para conjuntos maiores de dados;
• Organizamos os casos de testes construídos pelos times individualmente em suítes ordenadas;
• Realizamos teste manual e executamos testes automatizados para novas features e histórias;
• Eealizamos o teste dos requisitos não funcionais do sistema.
• Auxiliamos a identificar problemas e gargalos do produto.

Pensem comigo, nós do System Team temos que conhecer muito sobre os produtos e sistemas que testamos para poder fazer as atividades acima.

O cenário de atuação do System Team

Após os testes efetuados nas equipes de desenvolvimento, entra a equipe de homologação do System Team que realiza o teste de aceitação baseado nos critérios de aceite da feature. Os critérios de aceite já foram previamente definidos pelos analistas de sistemas. Assim é testado e validado se todas as histórias sincronizadas no mesmo código fonte atendem aos critérios de aceite da feature, conforme imagem abaixo. 

Times responsáveis pelos diferentes níveis de teste.

Após a homologação realizada o System Team, através de uma outra equipe de analistas de testes, executa um teste de regressão completo ponto-a-ponto no sistema onde o objetivo é verificar se após a sincronização de todas as features no mesmo branch o sistema continua funcionando como deveria, conforme imagem abaixo.

Teste ponto-a-ponto do System Team.

Nesta etapa o System Team torna-se responsável por documentar e criar casos de testes para áreas do sistema nunca antes mapeadas, gerando assim um grande valor de conhecimento para todos que trabalham com teste na empresa. Na prática, a equipe do System Team torna-se referência na integração dos produtos (fazendo jus à expressão "pau para toda obra"). Outro tipo de teste que o System Team é responsável é o teste de integração com outros sistemas a fim de validar se as novas versões desenvolvidas continuam compatíveis com outros sistemas.

Com a estruturação da equipe para se adaptar ao SAFe onde uma equipe de testes (os QAs) que está junto aos desenvolvedores testa as histórias do usuário, e outra que está junto ao System Team testa as features, a qualidade do teste e a identificação de bugs foi elevada consideravelmente, pois conseguimos detectar defeitos em vários níveis diferentes do processo.

Concordam? Discordam? Comenta aí! 😀 

Referências:

CABRAL, Samuel Pierri. FERNANDES, Anita Maria da Rocha. Teste de Softwares Utilizando um Framework Ágil Escalável. UNIVALI, Florianópolis, SC, Brasil.

Quem é o System Team dentro do Ágil?

Trabalho a pouco mais de 5 meses no System Team. Entrei no time no final da primeira release (iteração) planejada, participei da segunda release inteira e agora estou na terceira release no time do System Team. Já tive altos e baixos, mas vou tentar explicar tudo sobre esse time neste post.

Onde começou o System Team?

No framework ágil SAFe, Times Ágeis não são unidades stand-alone. Pelo contrário, eles são uma parte integral do Trem de Release Ágil (ART/TREM), onde eles coletivamente têm responsabilidade por liberar mais valor. Pense na release como um trem, onde cada vagão é uma equipe. Times operam no contexto do trem, contribuindo para sua visão, colaborando com outros times, e participando em cerimonias chave do TREM. Os times e o trem são inseparáveis; o todo é maior que a soma de suas partes.

Big Picture SAFe - System Team

Afinal, o que é o System Team?

Existe um time específico para a execução dos testes de regressão e integração, criado a partir da implantação do SAFe: o System Team. Esse time tem como função fazer a homologação do sistema após a finalização das features (conjunto de histórias) criadas pelos outros vagões do trem. Ele é composto por analistas de testes mais experientes e com conhecimento aprofundamento do sistema (em teoria). 

Como ocorre a criação desse time durante a transição para o ágil?

Quando o ágil está sendo implementado, é comum começar com a equipe sem ter planejado a estrutura necessária para o trabalho do System Team. Lembre-se de que o System Team trabalha testando os sistemas de forma integrada, como é utilizado pelo cliente e precisa de máquinas boas para os seus testes. Também é comum formar mais de um time de System Team pois as equipes podem ser grandes de acordo com os sistemas e integrações, mas ambos devem testar seus produtos de forma integrada. Os times de System Team auxiliam com a integração de sistema e solução e ajudam a demonstrar a solução evoluindo à medida que ela se desdobra.

Conforme falei neste post aqui, ocorre uma cerimônia chamada de System Demo. Na System Demo é apresentado, de forma integrada, todo o desenvolvimento dos vagões ágeis durante a release. Como o System Team já possui o ambiente de forma integrada, é comum este ambiente ser utilizado para a validação dos produtos para os Product Owners ao final da release. Falo mais sobre System Demo mais abaixo neste mesmo post.

Descrição do Papel System Team

O System Team é um time ágil especial no trem, que possui grande conhecimento nas soluções e por vezes é procurado para fornecer assistência na construção e uso do ambiente de desenvolvimento e testes. Este time executa testes nas soluções de forma integrada e de ponta a ponta. Por este motivo pode fornecer um feedback de forma rápida sobre como está a integração dos sistemas.

Responsabilidades do System Team

... sobre a infraestrutura:

• Pode criar e manter a infraestrutura das soluções integradas, incluindo integração contínua, builds automáticas e automatização de testes;
• Pode criar plataformas e ambientes de demonstração da solução, como podem utilizar o ambiente já existente para tal;
• Pode facilitar os aspectos técnicos de colaboração, tais como prover dados ou serviços, facilidades de hosting, etc. para outras equipes de desenvolvimento do trem.

... sobre integração de sistemas:

• Participa das reuniões de release planning e no refinamento do backlog para definir integração e testes de capacidades e funcionalidades;
• Determina e ajuda a manter decisões e políticas para apropriar modelos de branch;
• Pode participar das dailys de outros times no apoio à atividades diárias.

... sobre testes ponta a ponta e de performance:

• Cria novos cenários de testes automatizados;
• Organiza casos de testes desenhados por times individuais em suítes ordenadas;
• Executa testes manuais e roda testes automatizados para novas funcionalidades e estórias;
• Prioriza testes demorados, refatorados, e roda suítes de testes reduzidas onde aplicável;
• Ajuda os times a criar suítes reduzidas de testes que eles mesmos podem rodar;
• Testa performance da solução contra requisitos não funcionais e ajuda a equipe de Engenharia de Sistema e Solução a identificar falhas e gargalos.

Como o System Team atua nas Demos dos Sistemas e Soluções (System Demo)?

Ao final de cada release os times (vagões do trem) precisam demonstrar a solução desenvolvida no período da release. Normalmente o System Team apoia as outras equipes e ajuda a assegurar que os ambientes de demonstração estão adequados.

Como o System Team atua na liberação dos produtos?

O System Team estabiliza as versões de liberação e possui o conhecimento necessário para testar as integrações dos produtos. O System Team normalmente entendem o que é, o que faz, e quão bem cada entrega atende os requisitos desejados, pois participa das Reviews e, as vezes, das plannings dos demais times ágeis/demais vagões. Nesta perspectiva, o System Team está diretamente envolvido no suporte da liberação, trabalhando com os DevOps e fazendo o que for necessário para ajudar o TREM a preparar, empacotar e liberar a solução. Lembrando que o System Team não faz o trabalho de manutenção de liberar versões que já estão no mercado. O System Team libera versões que ainda não estão no mercado.

Por que dos altos e baixos na equipe do System Team?

Como foi possível compreender após toda a explicação do que o System Team faz e quais são suas responsabilidades, é também possível imaginar o tanto de cobrança que a equipe do System Team tem e qual o seu trabalho. Nós liberamos uma versão nova dos produtos/sistemas a cada fim de release (isto não é uma regra, mas é como funciona onde trabalho hoje). A semana de liberação costuma ser conturbada, pois ainda não finalizamos as estabilizações e cada equipe do trem quer preparar sua apresentação para a posterior aprovação dos Product Owners. Isso quando o ambiente não dá algum problema.

Apesar dos testes serem integrados, temos que testar as funcionalidades novas integradas com as velhas. Aqui temos que deixar claro que NÃO é função do System Team testar as funcionalidades novas desenvolvidas pelos times de desenvolvimento, mas temos que testar impactos e integrações.

Por mais que haja pressão, é comum as equipes de desenvolvimento liberarem seus produtos com testes sem ver seus impactos. Também já vi acontecer de equipes não planejarem seus tempos de testes e testarem seus produtos durante a estabilização do System Team.

Se a equipe do System Team não for forte, acompanhar TUDO, comunicar qualquer deslize e não aceitar algumas liberações, as liberações viram playgrounds e os testes das sprints ficam impossíveis de serem executados!

Referências

System Team Abstract - SAFe. Disponível em: <http://www.scaledagileframework.com/system-team/>. Acesso em: 17 de maio de 2017.

SAFe - um Framework ágil

A sigla SAFe significa Scaled Agile Framework, que em tradução livre seria um framework para

escalonamento ágil. Ele é um framework de desenvolvimento criado pela IBM para permitir às empresas de grande porte a utilização de práticas ágeis. De acordo com o site do framework, ele serve para abranger toda a organização, operando nos níveis de portfólio, programa e time.

Mas por que não colocam o Scrum numa empresa de grande porte, em vez de um framework ágil? 

Essa pergunta é fácil de ser respondida. Empresas de grande porte possuem controle, indicadores (para particição de lucros por exemplo), acionistas e , normalmente, certificações ISO. As certificações ISO requerem um processo que todas os colaboradores da empresa conheçam. Só assim a empresa consegue a recertificaçao.

Como funciona o SAFe?

Retirada do site do framework, a Big Picture do SAFe (abaixo) resume em um fluxograma os processos abrangidos pela metodologia. Nessa figura é possível observar os principais elementos trabalhados pelo framework SAFe, incluindo os conceitos de time, programa e portfólio, que serão detalhados a seguir.

Big Picture SAFe

Partindo do menor nível, temos o conceito de time dentro da metodologia. Esse fluxograma pode ser observado na parte debaixo da figura. Os times são formados por um número médio de sete a dez pessoas, incluindo desenvolvedores, testadores, scrum master (SM) e product owner (PO). O formato de trabalho, dentro dos times, é similar ao conceito de scrum, por meio de sprints. São realizadas entregas em curtos períodos que, somando com as entregas dos demais times, formam um incremento de programa, que agrega valor para o cliente. Além disso, o framework se baseia na utilização das metodologias ágeis Kanban, Scrum e XP para a realização de sprints de desenvolvimento.

O conceito de programa é justamente esse conjunto de vários times trabalhando para realizar as entregas para o cliente. Essa entrega maior é chamada, dentro da metodologia do SAFe, de trem (Agile Release Train), e é composta por 5 ou 6 sprints dos times. Na figura da Big Picture SAFe, essa etapa pode ser observada no fluxograma central. Os papéis que compõe esse processo são o RTE, Product Management, System Architect e Business Owners. Esses atores fazem o controle do backlog de programa, definindo prioridades e encaminhando as demandas para cada time, a nível de Feature. As entregas realizadas pelos times ocorrem por meio da cerimônia de Sprint Demo – apresentação dos itens desenvolvidos a serem aprovados pelo PO.

Já o nível de portfólio é composto por membros que devem ter a visão estratégica da organização. Eles são responsáveis por definir prioridades com o cliente, alocar as demandas no backlog dos times, a nível de Épico (iteração maior), organizar entregas, encaixar as necessidades dos clientes nas demandas para o desenvolvimento, etc.

Referências

Scaled Agile Framework – SAFe. Disponível em: <http://www.scaledagileframework.com/>. Acesso em: 16 de maio de 2017.

Por que algumas pessoas não acreditam no ágil?

Se você trabalha na área de TI, já deve ter vivenciado algum projeto com ágil, ou pelo menos visto alguma iniciativa ágil na sua empresa. Todas as iniciativas, nos mais variados projetos que vi até hoje seguiram as mesmas fases: Negação -> Resistência -> Adaptação/Exploração -> Aceitação/Comprometimento. Das 4 fases, a resistência parece ser a fase mais difícil de se passar, especialmente para os desenvolvedores.

Eu, como testadora, acredito no ágil sim! Sou feliz de fazer parte de uma equipe que também acredita, mas não foi do dia pra noite que o ágil passou a funcionar na nossa equipe. Foram mais de 2 meses até conseguirmos ajeitar o ágil à nossa equipe. Isso pois ele vem para quebrar paradigmas. O pessoal está muito acostumado e apegado ao modelo de projeto cascata, com toda aquela burocracia, que não consegue ver os benefícios do ágil. A primeira impressão parece ser: Ágil é igual a GoHorse, pequenas entregas de valor, danem-se os testadores e documentadores. É aí que começam a vir os problemas de commit, pois mais de um desenvolvedor alterou o mesmo fonte, na mesma linha, e após o merge o sistema simplesmente para; não compila mais.

Gente, sobre o ponto do commit, o caso é uma questão de Gestão de Configuração e em qualquer (absolutamente qualquer) processo de desenvolvimento que se faça (incluindo-se GoHorse) é necessário uma ferramenta de gerenciamento de fonte e um processo de mudança que permita que mais de um desenvolvedor submeta suas implementações. 

Além disso, o ágil diz que todos são responsáveis pelo projeto enquanto equipe na mesma sprint. Não existe essa de "danem-se os testadores e documentadores", pois todos são responsáveis se algo falhar. O desenvolvedor não pode só pensar no mundinho de desenvolvimento. Não existe GoHorse no ágil de jeito algum.

Quanto ao tempo, as pequenas entregas da sprint, são entregas de valor e não qualquer coisa. Para isso é feito todo um detalhamento sobre o que, como e a prioridade das entregas (Sprint Planning). As reuniões diárias também estão aí para que todos saibam o que cada membro da equipe está fazendo e o que ele vai fazer. 

O fato é que no modelo cascata ninguém sabe ao certo o que o colega ao lado está fazendo, salvo o gerente de projetos que quando está muito ocupado manda um e-mail todo dia pela manhã perguntando em quantos por cento está a entrega. Eu não acredito no funcionamento de um projeto no modelo cascata, com projetos engessados, complexos, e com estimativas e prazos de entrega tão reais quanto gnomos.

Ao meu ver, esse argumento de que "Ágil no desenvolvimento não funciona", é só uma desculpa de pessoas acomodadas que não querem mudança, pois as tiram da zona de conforto.

Até mais, :D

Papel do Scrum Master no ágil

Continuando a falar sobre os papéis existentes no ágil clássico, hoje falarei sobre o Scrum Master.

​​"Enquanto o Product Owner está focado em construir o produto correto e a equipe de desenvolvimento está focada em produzir corretamente o produto, e o Scrum Master é o cara que ajuda todos a compreender os valores, princípios e práticas do Scrum."​​

Ele é um Coach​​​

Deve agir como um mentor, um treinador, para a​​ equipe de desenvolvimento e para o P.O. (ajudando-os a entender e cumprir as suas responsabilidades​).

Fazendo uma a analogia com equipes esportivas, é como se o Scrum Master fosse o treinador do time e o Product Owner ​o dono da equipe. Quando surge qualquer problema que a equipe pode, e deve, ser capaz de resolver, a atitude do Scrum Master, como o de qualquer bom treinador, é:

"Eu não estou aqui para resolver seus problemas por você; em vez disso, eu estou aqui para ajudá-lo a resolver seus próprios problemas.“​​

Agora, se o problema é um impedimento que a equipe não pode resolver sozinha, o Scrum Master deve tomar para si a responsabilidade de resolver. Logo, o Scrum Master é responsável por maximizar os resultados do time através do Scrum.​

​Líder servidor

​​​Um líder servidor nunca perguntaria a um membro da equipe…

"Então, o que você vai fazer por mim hoje?"​​

Em vez disso, um líder servidor perguntaria…​

"Então, o que posso fazer hoje para te ajudar e sermos mais eficazes?"​​​​

Autoridade no processo

O Scrum Master é autoridade do processo, deve dominar o processo do Scrum como ninguém.

O Scrum Master tem o dever de garantir que todos da equipe Scrum conheçam os valores, princípios e práticas, juntamente com as abordagens específicas da equipe Scrum. O Scrum Master continuamente ajuda a equipe Scrum a melhorar o processo para maximizar o valor do negócio entregue.​​

​
Escudo contra interferências

O Scrum Master protege a equipe de desenvolvimento de interferências externas para que eles possam manter o foco na entrega de valor a cada sprint.

A interferência pode vir de inúmeras de fontes, desde gestores que querem mudar os membros da equipe no meio de uma sprint até a problemas provenientes de outras equipes.​​​

Não importa qual a fonte da interferência, o Scrum Master atua como um interceptor para que a equipe possa se concentrar na entrega de valor.

​​Removedor de impedimentos

O Scrum Master também assume a responsabilidade de remover qualquer obstáculo que possa inibir a produtividade da equipe (quando os próprios membros da equipe não podem removê-los).​

​​Agente de mudanças

O Scrum Master tem papel fundamental em transmitir o conhecimento sobre o Scrum e sobre as boas práticas associadas aos métodos ágeis, não somente em suas equipes, mas em todos os níveis da organização.​​​

Perfil esperado de um Scrum Master​

• ​​Conhecimento - Precisar dominar os conceitos do SCRUM. Não necessariamente necessita ser um especialista, a nível técnico, nem a nível de negócio, porém são conhecimentos que podem ajudar. 
• ​Questionador - Sempre buscando fazer o time encontrar as respostas para suas próprias perguntas.
• Paciente - Busca fortalecer e amadurecer o time, quanto aos conceitos do Scrum, devendo então ter paciência para apoiar o time nesse processo. 
• Colaborativo - Deve ser colaborativo com o time e P.O., além de incentivar esse tipo de prática dentro da equipe. 
• Protetor - Devendo proteger a equipe de interferências externar e o processo.
• Transparente - Em suas ações e em sua comunicação com os membros da equipe, garantindo o alinhamento das informações.

Você concorda? Deixe sua opinião também!

Até mais. :D

O papél do Product Owner na metodologia ágil

Olá Pessoal,

Esses tempos participei de uma discussão sobre o papel, características e as responsabilidades de alguns papéis que existem na metodologia ágil. Vou começar falando sobre o

Product Owner 

​​​​É um dos os três papéis que constituem a equipe Scrum clássica, (os outros são o Scrum Master e a Equipe de Desenvolvimento).​​​​​​​​ 

O Product Owner é o ponto central do projeto ágil e é quem exerce a liderança sobre o produto que está sendo desenvolvido.

​​É ele quem diz o que precisa e o que não precisa ser feito em relação ao produto que está sendo desenvolvido.​​ Sempre priorizando os itens a serem desenvolvidos de forma a maximizar o retorno sobre investimento. (R.O.I.).

​​

O Product Owner é quem faz a ponte entre a área de negócios e a Equipe Scrum.​​​

De um lado, o Product Owner deve entender as necessidades e prioridades de todos os envolvidos na empresa para agir como seu porta-voz. Neste sentido, ele atua como um gestor do produto, garantindo que a solução correta é desenvolvida. ​​​​

Do outro lado, o Product Owner deve se comunicar com o time scrum para ajudar na ordem em que o produto será construído. O Product Owner também deve garantir que os critérios para aceitação do produto estão especificados e que os testes que verificam esses critérios foram executados para determinar que o produto (ou release) possa ser considerado como pronto ao final do Sprint.

​​​​Principais responsabilidades

Participação no planejamento

​​​O Product Owner é um participante-chave nas atividades de planejamento de Produto, Release e Sprints:

• Durante o planejamento do produto o Product Owner trabalha com todas as partes interessadas da empresa (diretoria, demais departamentos, etc.) para conseguir visualizar o produto ideal.
• Durante o planejamento da release o Product Owner trabalha com as partes interessadas e a equipe Scrum para definir o conteúdo do próximo lançamento.
• Durante o planejamento da Sprint , o Product Owner trabalha com a equipe de desenvolvimento para definir um objetivo para o Sprint.

Grooming do Product Backlog​

É o Product Owner quem supervisiona toda a preparação e refinamento (também chamado de Gromming) do product backlog, o que inclui: criar, atualizar, estimar e PRIORIZAR os itens.

Não é o Product Owner quem realiza todo o trabalho de grooming sozinho e ele, também, não estima os itens sozinho (a equipe deve fornecer os insumos para isso). O P.O. deve sempre buscar o time para alinhamento sobre questões técnicas.

O Product Owner é, no entanto, o principal responsável para que a atividade de Grooming seja feita em prol de um fluxo de entregas que gere valor ao projeto.

Definir os critérios de aceitação e verificar se foram atendidos​

​​​​​​​O Product Owner é responsável por definir os critérios de aceitação para cada item do Product Backlog (o Scrum​ Master é quem o ajuda com isso).

Os critérios de aceitação devem ser criados antes do planejamento da Sprint. A equipe precisa do entendimento completo sobre o item para poder incluí-lo no backlog da Sprint.

O Product Owner é responsável por confirmar se os critérios foram satisfatoriamente atendidos. É interessante que ele possa fazê-lo durante o decorrer da Sprint, para ​​descobrir eventuais erros antes da revisão da Sprint.

Colaborar com a equipe de desenvolvimento

​​​O Product Owner deve colaborar frequentemente com a Equipe de Desenvolvimento de uma forma muito direta e estreita, se possível diariamente​!

Essa é uma das grandes diferenças para os métodos tradicionais. O envolvimento constante do P.O. com a equipe garante o maior entendimento, alinhamento e resposta a mudanças.

Colaborar com o resto da empresa

O Product Owner deve trabalhar em estreita colaboração com toda a comunidade de partes interessadas para recolher necessidades e sintetizar uma visão coerente para orientar o desenvolvimento do produto.​​​​

Partes interessadas internas podem incluir área de marketing, comercial, serviços, etc.. As partes interessadas externas podem incluir clientes, usuários, parceiros, órgãos reguladores, entre outros.

Características/ habilidades pessoais esperadas​

Você concorda? Deixe sua opinião também!

Até mais. :D

Quando considerar um projeto pronto na metodologia ágil? Definição de Pronto - DoD (Definition of Done)

Olá meu povo testador!

Conforme mencionado neste post, uma das palestras que participei num encontro de qualidade promovido pela empresa falou a respeito da definição de pronto. Vou desmistificar um pouco sobre a Definição de Pronto dentro da metodologia ágil.

O que é Definição de pronto?

Equipes ágeis maduras desenvolvem projetos seguindo alto padrão de qualidade. Tal rigor é imposto por meio da DoD – Definition of Done, ou Definição de Pronto. A DoD é uma discussão entre Time de Desenvolvimento (o que inclui o testador/QA) e Product Owner de que toda a entrega atenderá os padrões de qualidade estabelecidos por eles mesmos.

Para que serve o DoD?

É uma forma de se buscar a excelência. A discussão aprofunda a compreensão da equipe dos itens do backlog e os requisitos do produto de cada estória da sprint.

Quando uma estória está pronta?

Vida de Programador - nº1438

Toda mudança é difícil, quando você sai do modelo de desenvolvimento tradicional e vai para o ágil a história não é diferente. Posso dizer que eu vivi o quadrinho do Vida de Programador acima. É difícil de um programador de longa data aceitar que o "pronto" não é mais um status por etapa de desenvolvimento e sim "pronto" de tudo. Ainda percebo que é difícil o programador aceitar que ele precisa se preocupar com tudo também.

É importante frisar que, no ágil, a definição de pronto é decidido pela equipe e ocorre por estória. Então temos que o "pronto" pode ser diferente para cada estória dentro da sprint. ;)

Exemplos de definição de pronto:

- Critérios de aceite da estória atendidos.

      Responsável: Time de Desenvolvimento e Product Owner;

- Testes da estória executados conforme planejamento. Todas as subtasks de testes devem estar finalizadas.

      Responsável: QA (Quality Assurance);

- Todos os defeitos não críticos que não podem ser corrigidos dentro dos limites da sprint adicionados ao backlog do produto e priorizados para a próxima sprint.

      Responsável: todo o time;

- Integração de todas as funcionalidades.

      Responsável: todo o time;

- Todos os requisitos funcionais testados, incluindo os testes positivos e negativos, com o número de testes com base no tamanho, complexidade e riscos.

      Responsável: QA;

- Todos os riscos de qualidade cobertos de acordo com a medida acordada de testes.

      Responsável: QA;

- Documentação escrita, avaliada e aprovada.

      Responsável: Product Owner.

Espero que tenham gostado deste post. Qualquer dúvida, perguntem! :D

Referências: 

Definition of Done. Disponível em: <http://www.mindmaster.com.br/definition-of-done/>.

Apostila da certificação CTFL-AT (já falei sobre ela AQUI): Foundation Level Extension Syllabus Agile Tester. Disponível em: <http://www.bstqb.org.br/uploads/docs/syllabus_ctfl_at_2014br.pdf>.

Evento gratuito de Testes - QA Ninja Conference 2016

Olá meu povo testador!

Hoje começa um evento gratuito de testes de software, chamado QA Ninja Conference 2016. Esse evento terá transmissão ao vivo e gratuita, basta fazer sua inscrição AQUI. Ele ocorre durante essa semana, de 24/10/2016 a 28/10/2016 a partir das 19 hs.

Qual o melhor caminho para testar minha aplicação? 

Como evitar que mudanças causem transtornos e efeitos colaterais no meu software? 

Como técnicas automação de testes podem tornar meu trabalho mais produtivo?

Pensando nisso foi criado um evento, totalmente on-line e gratuito, que vai te ajudar a encontrar respostas para essas perguntas, focado em Qualidade de Software.

http://www.qaninjaconference.com/

Público Alvo: QAs e DEVs com interesse em conhecer e aprender mais sobre Qualidade e Testes de Software.

Seu software testado: Conheça as melhores práticas e ferramentas para realizar variados tipos de testes nos seus projetos.

Testes ágeis: Entendendo tipos de testes sob a perspectiva do desenvolvedor e do usuário final.

Link do evento: http://www.qaninjaconference.com/ Os videos do evento ficarão gravados no Youtube e estão disponíveis nesse link também.

Aproveite! Também comente se você viu o evento e o que achou. :D

Encontro de testadores 2016 - Blumenau/SC

Ontem, eu participei de um evento anual que proporcionou um encontro com todos os profissionais de testes de software da empresa onde trabalho, aqui em Blumenau/SC. Mais ou menos 70 profissionais de testes se reuniram. O foco deste ano foi falar sobre o ágil. Eu já havia comentado, num post aqui no blog, que estamos migrando os projetos do formato cascata para o ágil. 

Este encontro ainda vai render vários posts sobre ágil aqui no blog (meu Trello de ideias está cheio :D ). Então vou dar um gostinho do que vi ontem:

Ágil - O que é? Como funciona? Um pouco da experiência de quem já viveu essa transição e fazer acontecer.
Os 10 mandamentos do QA - A teoria e exemplos reais. Post aqui.

Definição de Pronto, DoD - Quando uma entrega está pronta? Post aqui.

User eXperience - O que é e como um testador ajuda um designer a melhorar a experiência de uso de um software?

Fora o OneMinuteTalk, Fishbowl e o Game interativo que tivemos usando o smartphone.

Aguardem! :D

Até onde um processo bem definido garante a qualidade de um produto?

Muito se fala em melhoria de processos para desenvolvimento de software. É cada vez mais comum encontrar empresas que possuem um grupo ou setor dedicado à melhoria contínua dos seus processos. Processos estes, baseados nas melhores práticas de metodologias e modelos de mercado, praticados no mundo inteiro.

Enquanto algumas empresas possuem um setor dedicando 100% de tempo para analisar, ajustar, criar e manter processos, outras empresas possuem grupos. Esses grupos de pessoas trabalham nos mais variados setores da empresa e, normalmente, possuem uma quantidade de horas limitada por semana para se dedicar à melhoria dos processos. Tanto os grupos quanto os setores têm por objetivo fazer com que os processos sejam entendidos por todas as pessoas da empresa, sem que ocorra dupla interpretação sobre a forma de trabalhar. 

Para não haver uma interpretação errada do processo, todos os colaboradores da empresa devem ser envolvidos, pois são eles quem utilizam estes processos. Quando isso ocorre, todos se sentem parte importante da organização. Os colaboradores irão:

• Reportar quando existe algo errado num processo existente;
• Reportar quando uma situação não foi contemplada pelo processos;
• Informar que uma situação nova ocorre e não existe um processo para suportar esta nova situação;
• Reportar quando um processo não é mais utilizado;
• Reportar quando um processo definido não é entendido ou possui mais interpretações;
• Reportar quando uma equipe ou pessoa não segue o processo ou segue de forma incompleta.

A garantia da qualidade com um processo bem definido deve estar em todas as áreas, seja na análise, no desenvolvimento, nos testes, na documentação, etc.. Todos saem ganhando, mas em nenhum momento este processo garante a qualidade do produto.

Estamos lidando com pessoas, que são falhas. Além disso, um processo bem definido tende a gerar a burrocracia. No fim, para abrir uma simples tarefa de erro temos todo um processo a ser seguido. O simples se torna complexo. Quanto mais complexo o processo, mais suscetível a erros. Quando erros de processos são pegos, mais o processo é engeçado. Aí vemos uma bola de neve. Como solução, muitas empresas recorrem ao ágil. Claro, o ágil quer eliminar toda a burrocracia gerada até então. Cada item de processo dispensável é eliminado.

Chego a conclusão de que nós mesmos somos os culpados por engeçar o processo, por querer controlar cada pingo no "i" digitado, por desmotivar os colaboradores com processos absurdamente grandes que controlam situações que poderiam ser simples. Quero deixar claro que não sou contra controlar processos, mas todos devemos ter cuidado com o quanto controlar.

Até mais! :)

Minha opinião sobre a prova de certificação da CTFL-AT

Olá Pessoal,

Mês passado fui aprovada na prova de certificação CTFL-AT (Certified Tester Foundation Level - Agile Tester), do BSTQB/ISTQB. Hoje eu vou lhes contar aqui um pouco sobre a certificação e preparação para a prova da CTFL-AT.

O que é a CTFL-AT?

É uma certificação com validade internacional em testes de software, feita para testadores que trabalham com ágil. Ela ainda é nova: foi criada em 2014. Então, se você trabalha/quer trabalhar com testes de software em locais que trabalham com alguma metodologia ágil, esta é uma ótima opção.

Tem pré-requisitos?

Tem sim. Para fazer esta certificação você precisa primeiro ser certificado CTFL.

Qual era a minha motivação para fazer a prova?

A empresa onde trabalho começou a implantar ágil este ano. Muitos projetos ainda estão em fase inicial de implantação dentro dos projetos (incluindo o que eu trabalho), enquanto alguns poucos já estão com o ágil bem maduro na equipe. Eu queria aprender sobre o ágil. Já tinha lido muito sobre a teoria e como o ágil funciona, mas nada era focado sobre como o ágil é usado para testes de software. Quando eu e meus amigos estávamos estudando pra CTFL, vimos que tinha uma certificação que eu não sabíamos que existia: a CTFL-AT. Decidimos que se passássemos na CTFL, iríamos emendar a certificação do módulo ágil. E foi o que aconteceu. :D

Como eu me preparei para a prova? 

Comecei a me preparar logo depois da inscrição, assim que recebi o resultado de aprovação na prova da CTFL, cerca de 2 meses antes da prova da CTFL-AT. Novamente usei o Trello para me ajudar a organizar os estudos com um checklist. A minha "receitinha" de estudos foi praticamente igual a que usei pra CTFL: 

• Ler a apostila pela 1ª vez, marcando partes importantes;
• Ler a apostila pela 2ª vez, somente partes marcadas;
• Fazer simulados diversos encontrados na internet;
• Fazer simulado oficial, disponibilizado em inglês no site da ISTQB (link AQUI, lembrando que o  Sample Exam é o simulado e o Answer Sheet dá a alternativa correta e a explicação) (não tem simulado oficial no site brasileiro da BSTQB até a presente data);
• Ler a apostila pela 3ª vez, identificando os erros cometidos após o simulado oficial em inglês;

Últimas duas semanas antes da prova: 

• Foco no simulado oficial em inglês;
• Releitura das partes marcadas na apostila.

Como foi a prova?

O estilo da prova é bem parecido com a da CTFL. Foram 40 questões, feitas em 1 hora. Foi assustador num primeiro momento, pois parecia que eu tinha lido a apostila errada (meu amigo também achou isso). Mas eu tinha estudado tanto que não perdi minha confiança.

O tamanho de algumas questões também assustava um pouco, o simulado em inglês do site ajudou a ter uma noção de como seria a prova, e se confirmou na dificuldade. A prova é objetiva. Algumas questões precisam de interpretação de texto. Haviam situações em que todas as respostas estavam certas, mas que você precisava indicar a mais apropriada para determinada situação. Conversando com meu amigo, novamente chegamos à conclusão de que a prova era diferente entre nós.

Vale a pena fazer a prova e tirar a certificação CTFL?

Vale! O material é ótimo e fala bastante sobre como testes se encaixam numa equipe ágil. Esclareceu muitas dúvidas que eu tinha. Além disso, esta é a certificação mais barata da BSTQB: R$ 200,00. Após ter feito a prova (nem sabia do resultado ainda), pude ajudar mais com a implantação do ágil na equipe que trabalha comigo. Só por isso já vi que tinha valido a pena.

Conclusão!

Para você que quer aprender mais sobre testes ágeis, faça a certificação! A prova é difícil, mas você aprende muito.

Até mais! :D

Problemas que uma equipe de testes pode enfrentar no início da implantação da metodologia ágil - Scrum

No Scrum, todos da equipe são responsáveis por uma Sprint. Será? O que acontece quando a equipe de testes é chutada para fora da equipe? O que acontece se a equipe de desenvolvimento achar que testes não é necessário dentro da Sprint "deles", considerando-os como uma "Sprint paralela" ao desenvolvimento? Eu vivi isso e vou te contar neste post.

Toda mudança possui vários altos e baixos, e passamos por basicamente 4 estágios:

- 1º você rejeita

- 2º você tenta um boicote à mudança

- 3º você aceita

- 4º você coopera com a mudança

Quando começou a implantação da metodologia ágil, no meu local de trabalho, não foi diferente. Mas eu, como parte da equipe de teste, via algumas interpretações corretas e outras absurdas da metodologia. Contextualizando a ordem dos fatos:

• A empresa sentiu necessidades de mudança, pois viu que outras empresas levam metade do tempo para fazer grandes entregas (possivelmente com um grande incentivo do novo diretor de desenvolvimento);
• Começou um projeto piloto para implantação da metodologia;
• Adquiriram ferramentas específicas para auxiliar no gerenciamento de Sprints;
• Liberaram um documento com a política de funcionamento do processo ágil na empresa (mais parecia um cópia e cola de um site cheio de erros de português e loops no processo);
• Começou uma onda de mudanças, onde algumas equipes foram avisadas que a partir de X data poderiam migrar seus projetos para a ferramenta e trabalhar com o processo em ágil.

Se vocês ficarem bem atentos, verão várias inconsistências:

• A empresa acreditou que as pessoas chaves do projeto sabiam como funciona a metodologia ágil e um simples documento seria o bastante para aplicar ágil nos projetos;
• Migrar projetos do modo cascata pro ágil? Sem coordenação ou acompanhamento de um gerente de projetos?
• Fizeram do trabalho de faculdade de alguém um documentos de processo de funcionamento ágil? É isso mesmo?

Enfim, o problema estava claro pra toda a equipe de testes que teve de se adaptar. A adaptação não é um problema! A equipe de testes geralmente é bastante flexível, pois estamos acostumados com mudanças no processo de trabalho e mudanças de projetos de trabalho. O problema é que nem todos os analistas de testes/testadores dos produtos sabiam como se impor e alguns projetos viraram um caos.

No modo tradicional de desenvolvimento, o cascata, as equipes eram acostumadas a iniciar testes só depois que a implementação está pronta. Na metodologia ágil isso deixa de existir. A equipe de testes está testando partes antes de estarem concluídas, está dando ideias de situações que os programadores devem prever durante a implementação, pois a equipe de testes conhece o negócio e antecipa a ação que o cliente usará.

Eu vi uma equipe criar Sprints sem atividade de testes. Os testadores estavam num tipo de "sprint paralela" e atrasada do projeto. Você não leu errado, o sentimento era de total descaso com testes! Assim que a equipe de desenvolvimento acabava toda a implementação envolvida de uma Story, a mesma era encerrada. A Sprint acabava e uma nova Sprint era planejada! E testes? Os testadores precisavam buscar no "limbo do projeto" as Storys encerradas para então fazer um teste integrado. Não recebiam nenhum alerta de encerramento da Story e um controle paralelo era necessário. O desenvolvimento levando os créditos de que a Sprint foi um sucesso, encerrada no tempo planejado. SEM TESTES é só um detalhe? Ao meu ver, a Sprint só é um sucesso quando a equipe de testes dá seu aval de "Testes OK".

Isso parece um belo boicote à mudança. Jeff Sutherland, do livro "Scrum - a arte de fazer o dobro de trabalho em metade do tempo", disse que todos na equipe deveriam ser responsáveis pelas Sprints. Eu via que isso não estava acontecendo naquela equipe. O desenvolvimento não sentia que testes deveriam fazer parte da equipe. Para piorar, a pessoa que deveria apoiar e coordenar os trabalhos em testes ouviu todo esse problema e ficou por isso mesmo.

Recebi um retorno da não conformidade que abri, dizendo que era uma situação grave e deveria ser combatida. Quando a bagunça da equipe em questão acabar eu apresento a solução aqui no blog. Vale lembrar que esta é a única equipe que vi deixar testes de lado enquanto usavam metodologia ágil (não, eles não tem testes unitários para garantir coisa alguma). Mais alguém está achando que a metodologia usada por essa equipe mais parece GO HORSE?

Resumo da história: O pessoal de testes precisa se impor. Precisam mostrar que testes é importante sim dentro da Sprint e brigar por isso. O modo tradicional de testes, de testar somente quando a entrega já está pronta, não funciona na metodologia ágil. Testes unitários não garantem integração de produtos. Os testes de integração DEVEM entrar na Sprint! Cadê a responsabilidade da equipe toda em fazer uma entrega rápida e sem impactos para clientes?