5 dicas para iniciar como quality assurance engineer

Publicado por Thiago Medeiros no dia qa

image alt text

Aqui na Resultados Digitais, desenvolvemos um produto que deve satisfazer todos os tipos de clientes, inclusive os mais exigentes. Para isto, na área de desenvolvimento do produto, temos uma equipe de desenvolvedores trabalhando ativamente e bem atentos à demanda de produzir algo cada vez melhor. Para assegurar-se da qualidade de cada entrega, temos dentro da RD, a horizontal de Quality Assurance, onde nós, os QA Engineers, realizamos todos os processos e atividades necessárias para garantir que todo o trabalho realizado chegue nas mãos do cliente com todos os requisitos plenamente atendidos.

Mas o que fazemos? As tarefas diárias incluem melhorar os processos dentro dos times ágeis, participar ativamente do flow de entrega das features desde o momento de sua concepção, dando feedbacks ativos, até seu deploy em produção. Especificamos também novas features em linguagem orientada à comportamento seguindo a linha do ATDD (Acceptance Test Driven Development). E claro, desenvolvemos testes de aceitação em frameworks Ruby, como o RSpec, o Capybara, o Poltergeist, o FactoryGirl, o VCR e o SitePrism. Além disso, como Agile Testers, também realizamos testes exploratórios e engajamos todo o time com o mindset de qualidade.

Se você se identificou com o trabalho que estamos fazendo, elaborei 5 dicas para que você obtenha sucesso quando começar a atuar como QA Engineer seja dentro ou fora da RD.

Três coisas que descobrimos sobre experimentação dentro de um produto

Publicado por Luigi Cenatti Gianni no dia gestão

AB Testing

Nós criamos em janeiro deste ano o primeiro time de Produto focado exclusivamente no onboarding do RD Station (se você está curioso sobre o porquê, a resposta tem a ver com retenção). Junto com essa mudança, começamos a testar a aplicabilidade de um processo de experimentação (muito similar a growth hacking) para melhorar o RD Station.

Por que nossos Product Owners viraram Product Managers (e qual a diferença)

Publicado por Raphael Farinazzo no dia gestão

Jogo de xadrez

Quando decidimos que os Product Owners mudariam de papel dentro do time de produto e passariam a ser Product Managers, nem mesmo a troca do nome foi instantânea - e ainda hoje alguém às vezes se descuida e me chama de P.O.! Rótulos à parte, foi uma mudança profunda que até hoje está causando um impacto muito positivo em nossa maneira de desenvolver produto.

Vale ressaltar que em algumas empresas, esses papéis coexistem: o Product Manager define Visão e Roadmap, o Product Owner define estórias de usuário. O PM olha mais para fora (clientes, mercado etc.) e o foco do PO é para dentro (time, entrega). No nosso caso, porém, ambas as responsabilidades passaram a se concentrar no Product Manager. Vou explicar como:

Como foi a Product Camp SP 2016 - a primeira do Brasil!

Publicado por Raphael Farinazzo e Jacqueline Asano no dia gestão

Jacqueline Asano e Raphael Farinazzo na Product Camp SP 2016

Já se vão mais de 80 anos desde que Neil McElroy contratou o primeiro brand man, ou o “MVP do Product Manager”. Desde então, a profissão passou por várias mudanças, especialmente com o Agile Manifesto e o conceito de Lean Startup. Fato é que hoje, se você perguntar para 10 PMs de empresas diferentes, é bem provável que em cada um tenha rotinas, papéis e responsabilidades diferentes. Às vezes, até o nome do cargo muda!

Dicas de Design Orientado a Objetos com Ruby - Parte 1

Publicado por Luiz Cezer Marrone Filho no dia dev

Desenvolvimento de Software

Nos últimos anos o paradigma da Orientação a Objetos vem sendo cada vez mais aplicado e difundindo dentro da comunidade de desenvolvimento de software. Prova disso é a que a grande maioria das novas linguagens que surgiram nos últimos anos obedecem esse paradigma. O desenvolvimento Orientado a Objetos possui diversas vantagens e visa tornar o desenvolvimento mais simples, focado em uma maior abstração e reusabilidade do código.

O que o budismo me ensinou sobre suporte técnico

Publicado por Luciano Marcelino no dia agile, gestão

Bandeirinhas de oração tibetanas

Aqui na Resultados Digitais, quem atende os clientes no suporte técnico são os próprios desenvolvedores. Por um bom tempo, nós rotacionamos os devs que faziam suporte: toda semana três pessoas diferentes atendiam a todos chamados técnicos. No meu caso, o trabalho era atender os tickets(chamados abertos pelos clientes) rapidamente: minha missão era conseguir resolver o problema em poucas horas. Caso contrário, passava o chamado para outros desenvolvedores que fariam uma investigação mais profunda e demorada do problema. Conheça aqui como funcionava esse processo.