Bitlady, by @anfindeis

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 alg...

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 apa...

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...

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 d...

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...

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 prin...

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...

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 ...

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 a...

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...

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 perspecti...

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. ...

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. Q...

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...

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 dese...