Testes e usuários, comofas

Os principais objetivos do teste de software são encontrar defeitos, ganhar confiança sobre o nível de qualidade, prover informações para a tomada de decisão e prevenir defeitos, mas essas coisas podemos encontrar nos livros, (Base de conhecimento de teste de software) nas cartilhas para certificados disponíveis (Syllabus ISTQB) e também em vários blogs na internet.

No meu ponto de vista um critério importante para ser um bom tester é pensar como um usuário final, quando se trabalha em um time de desenvolvimento agil, o tester tem a chance de acompanhar o levantamento dos requisitos, e fazer valer a máxima de que os testes começam na definição do escopo do projeto (Modelo V), garantindo qualidade e entendendo a necessidade e expectativa do usuário final.

Como um tester pode auxiliar o levantamento de requisitos?
Estudar os requisitos enquanto estão no backlog e fazer questionamentos (critérios de aceitação das histórias) sobre os requisitos, entender o que cada história esta pedindo e se os critérios de aceite não precisam de modificações e conversar com o P.O sempre, antes do scrum backlog grooming e durante os testes de aceite.

Também levar os conhecimentos do sistema, das regras de negócio e do perfil do usuário final para otimizar a usabilidade, as funcionalidades e o tempo do usuário, pensar nas coisas que ele faria e não somente nos testes baseados nas técnicas modelagem de testes, (partição de equivalência, análise do valor limite, tabela de decisão) usar o conhecimento do perfil do usuário para prever erros e melhorias antes da entrega do produto.

Sempre há algum detalhe que o usuário não viu, ou alguma funcionalidade que ele esqueceu de mencionar no levantamento de requisitos, por isso uma equipe de qualidade que conheça o cliente e o produto agrega valor a entrega final.

“Não adianta encontrar e consertar erros se o sistema não atende as expectativas e necessidades dos usuários.”

Você esta dizendo que o P.O não precisa fazer o teste de aceite?
O teste de aceite é um ponto importante para verificar se os requisitos foram atendidos e também se atendemos as necessidades do usuário final, e não deve ser extinto, vivas ao Myers.

O ponto principal é levar qualidade no desevolvimento, desde o princípio. Prevendo erros, melhorias e todas as formas possíveis e factíveis de fazer uma entrega perfeita, sem detalhes no layout, sem detalhes nas funcionalidades, performance ou arquitetura.

Medium - medium.com/@FindBugsBR

Muito bom, concordo com boa parte do que dito. Não concordo na questão de pensar como um usuário final, acho que eu nuca conseguiria pensar como um usuário final. Por exemplo, trabalho com um Software voltado para Construção Civil, onde muitos Engenheiros fazem uso de tal, será que eu consigo pensar igual a um Engenheiro com 10 anos de experiência no ramo? outra, mesmo usuários que atuam na mesma função tem percepções usabilidade diferentes com relação ao sistema. Qual usuário eu devo tentar “incorporar”? O que solicitou o produto? Nem sempre quem solicita a implementação é a mesma pessoa que faz uso do sistema. Pensar como usuário final é citado como um critério importante para ser um bom testador, acho que tem coisas mais importantes para se preocupar em ser um melhor testador, mas ai deve ser uma questão de prioridades. É legal essa empatia com o cliente, mas se você quer pensar igual ao usuário, terá que criar primeiramente um equipamento para ler a mente das pessoas.

Outra coisa, prevenir defeitos me remete a QA ( Quality Assurence) acho que nós testadores temos que nos livrar desse conceito de “Garantia da Qualidade”.
Uma vez um colega me perguntou “Você está na garantia de qualidade?” Sim, veio a resposta. “Então, você está autorizado a alterar o código fonte para os programas que você testa?” Não, definitivamente não. "É interessante. Então, como você pode garantir a qualidade? ".

O nosso papel não é garantia de qualidade; não temos controle sobre o cronograma, o orçamento, programador, definição do produto, o modelo de desenvolvimento, relações com os clientes, e assim por diante. Mas quando estamos fazendo o nosso melhor trabalho, estamos fornecendo valiosas informações sobre o estado real do produto e do projeto. Nós estamos ajudando as pessoas que são responsáveis ​​pela qualidade e as coisas que influenciam. “Assistente da Qualidade” é o que fazemos. "
Nós não somos o cérebro do projeto. Ou seja, nós não o controlamos. O nosso papel é fornecer não é percepção extra-sensorial, mas o acréscimo da percepção sensorial . Nós somos os olhos extras, orelhas, dedos, nariz, e paladar para os programadores e gestores. Nós somos extensões de seus sentidos. No nosso melhor, somos como instrumentos de microscópios extremamente sensíveis e bem calibrados, telescópios, microfones super-sensíveis, paquímetros, espectrômetros de massa. Detectores de farejadores de bomba. Nós ajudamos os programadores e os gestores para ver, ouvir e sentir as coisas de outra forma que, no tempo limitado disponível para eles, e na mentalidade de que eles precisam fazer o seu trabalho, eles não podem ser capazes de sentir por conta própria.

Tester

Eu considero uma parte importante este “incorporar o cliente”. As vezes nem é tão difícil assim… Quando se diz que temos que pensar como o usuário não é ter a mesma experiência que o usuário, mas pensar como se você estivesse na frente do PC usando este software. Isto é questão de perspectiva.
Por exemplo, eu trabalho com um software de gestão de operadora de saúde, e eu tinha o plano de saúde de uma operadora que usa este sistema. Certa vez emitindo um relatório como usuário, vi que determinados valores não deveria aparecer para mim, até porque, eu como beneficiário não deveria ter acesso àqueles valores. Eu já havia testado este relatório várias vezes, mas eu só tive esta visão quando eu o usei na “vida real”. Eu não sou duas pessoas, então por que o “eu” testador não encontrou o problema enquanto o “eu” usuário sim? O “eu” testador não tem o mesmo pensamento do “eu” usuário? SIM! Não tem! Quando testo tenho a perspectiva de testador, e quando uso, de usuário, e esta diferença vai além do conceito de pessoa. É como se você fosse uma pessoa diferente para cada situação diferente.
Pensar como outra pessoa é bem isto que foi colocado, é incorporar o usuário. Nem sempre isto é possível, é claro, por isto existem métodos de pesquisa de campo (principalmente para questões de usabilidade), em que é observado o comportamento do usuário, sua rotina, suas tarefas, suas manias, suas expressões faciais, …

Mas contradizendo tudo o que falei, dizer que um testador que tem visão de cliente é bom testador ou que quem não tem visão de cliente é um mal testador… não é bem assim… As carreiras hoje tendem a ser em T, ou de pessoas especialistas generalistas. Saber um pouco de tudo e muito de uma coisa específica. Você pode não ter muito a visão de cliente e ser expert em automação. Outro pode saber o básico de automação e ser expert em visão de cliente, regras de negócio. Outro ainda pode não ter visão de cliente nem de automação, mas ser incrivelmente bom em questões de segurança, invasões… Todos são bons, mas cada um na sua.

A área de qualidade tem espaço para vários perfis =)

Log in to reply

Looks like your connection to Agile Testers was lost, please wait while we try to reconnect.