Q.A Muito mais que Testes
Por mais estranho que pareça ainda é comum achar empresas que não testam seus produtos de software. Isso chega a ser muito diferente se falarmos de outras áreas como a indústria de automóveis por exemplo.
Você já pensou se você compra um carro zero na concessionária e ao sair com o carro ele nem liga, ou pior a porta do carro nem abre? Imagine então andar 10 metros e furar o pneu?
Novo e não funciona! :(
Isso é horrível, não digo que nos dias de hoje isso é improvável que aconteça mas é difícil, mas por que é difícil por que eles testam o carro e as partes do carro. Ao desenvolver software você está fazendo algo que não existia e você precisa sim testar e muito.
Por que Testar Software?
Por uma questão extremamente básica. Como você sabe que funciona? Se não testar não sabe, bugs são inevitáveis, mas isso não significa que você pode entregar um produto de baixa qualidade pra seu cliente. Os testes não garantem a qualidade do produto, mas ajudam nesta garantia, para garantir a qualidade do produto precisamos muito mais do que testes.
Uma fase de testes basta?
Não basta e isso é um erro, na verdade esse tipo de visão é aquela velha herança do modelo de desenvolvimento de software em cascata. Você não pode ter uma fase de testes, os testes devem estar presentes do inicio ao fim do desenvolvimento.
Você deve aplicar vários tipos de testes como por exemplo: testes unitários, testes de regressão, testes de stress, testes de carga, etc... Mas isso ainda não será o suficiente para você.
Qualidade Interna VS Qualidade Externa
Quando falamos de testes vamos estar pegando basicamente a qualidade externa que é aquela qual o cliente vê. Ou seja, se o sistema é funcional, se a tela é ergonomica, se o sistema funciona, se atende as necessidades do cliente. Para isso podemos perceber a ligação de Qualidade de software com duas outras grandes disciplinas da engenharia de software que são os Requisitos e a Gerencia de Configuração.
Agora quando falamos de qualidade interna o furo é bem mais em baixo. Na verdade para manter a qualidade interna é necessário bem mais investimento e infelizmente nem todas as empresas deste país tem essa visão.
A qualidade Interna é aquela que o cliente não vê, mas não pense que ela não influencia na qualidade do produto, por que aqui estão as questões de reutilização, facilidade e velocidade para aplicação de mudanças, acoplamento de código, design e outras tantas coisas importantes.
O que é um Q.A ou SQA?
S.Q.A se refere a garantia de qualidade de software. E Q.A é a garantia de qualidade, como podem ver um é mais amplo do que o outro. Por que em um projeto pode ser que você não entregue só código, por acadar entregando processo, serviço, metodologia e esses são items que não se consegui via código.
Q.A e testes dentro do desenvolvimento de software?
Isso é perfeitamente possível, métodos como o RUP e o Open Up especificam tarefas e papéis para serem desempenhados no desenvolvimento de software envolvendo a disciplina de testes e ainda as disciplinas de Gerência de Configuração e Analise de Requisitos.
O FDD vai um pouco mais além e foca na revisão de código por exemplo que é algo muito importante. Eu já participei de revisões mas na maioria constituídas de revisões de requisitos. As revisões são em certos casos o mecanismo mais eficiente que você tem para melhorar a qualidade do seu produto e do seu processo.
Não esqueça do processo
Use um ciclo de PDCA assim como propõe o Scrum e melhore a qualidade do processo assim você estará melhorando a qualidade do produto também. Você precisa estar sempre avaliando os métodos de desenvolvimento de software para melhorar a qualidade dos mesmos.
Veja que desta forma A garantia da qualidade só vai ser atingida com Testes, Revisões de códigos, design, requisitos, arquitetura, processo. Mas para isso você precisa saber o quanto as coisas vão bem ou vão mal, ai que entram as métricas, um profissional de Q.A normalmente pega todas essas "coisas".
Q.A não é a barreira para problemas
Se você pensar que a equipe de testes ou a equipe de SQA é a barreira pra problemas você terá muitos problemas. Você deve mudar essa cultura e pensar que a qualidade tem que vir em todas as disciplinas, começando pelo desenvolvimento que essa deve ser a primeira barreira, Q.A é a ultima barreira depois disso os bugs já estouraram para o cliente.
Q.A não é só auditoria de processo
Muitos pensam que Q.A é focar em auditar o processo, ou seja, você define um processo e o cara de Q.A diz se o processo está sendo seguido ou não, na verdade é muito mais que isso. Você precisa melhorar o processo se for o caso, precisa se preocupar com a qualidade do produto, com a qualidade dos requisitos, o Q.A ajuda identificar problemas de qualidade em geral, isso não é tarefa de uma única pessoa e sim de toda a equipe.
Você já pensou se você compra um carro zero na concessionária e ao sair com o carro ele nem liga, ou pior a porta do carro nem abre? Imagine então andar 10 metros e furar o pneu?
Novo e não funciona! :(
Isso é horrível, não digo que nos dias de hoje isso é improvável que aconteça mas é difícil, mas por que é difícil por que eles testam o carro e as partes do carro. Ao desenvolver software você está fazendo algo que não existia e você precisa sim testar e muito.
Por que Testar Software?
Por uma questão extremamente básica. Como você sabe que funciona? Se não testar não sabe, bugs são inevitáveis, mas isso não significa que você pode entregar um produto de baixa qualidade pra seu cliente. Os testes não garantem a qualidade do produto, mas ajudam nesta garantia, para garantir a qualidade do produto precisamos muito mais do que testes.
Uma fase de testes basta?
Não basta e isso é um erro, na verdade esse tipo de visão é aquela velha herança do modelo de desenvolvimento de software em cascata. Você não pode ter uma fase de testes, os testes devem estar presentes do inicio ao fim do desenvolvimento.
Você deve aplicar vários tipos de testes como por exemplo: testes unitários, testes de regressão, testes de stress, testes de carga, etc... Mas isso ainda não será o suficiente para você.
Qualidade Interna VS Qualidade Externa
Quando falamos de testes vamos estar pegando basicamente a qualidade externa que é aquela qual o cliente vê. Ou seja, se o sistema é funcional, se a tela é ergonomica, se o sistema funciona, se atende as necessidades do cliente. Para isso podemos perceber a ligação de Qualidade de software com duas outras grandes disciplinas da engenharia de software que são os Requisitos e a Gerencia de Configuração.
Agora quando falamos de qualidade interna o furo é bem mais em baixo. Na verdade para manter a qualidade interna é necessário bem mais investimento e infelizmente nem todas as empresas deste país tem essa visão.
A qualidade Interna é aquela que o cliente não vê, mas não pense que ela não influencia na qualidade do produto, por que aqui estão as questões de reutilização, facilidade e velocidade para aplicação de mudanças, acoplamento de código, design e outras tantas coisas importantes.
O que é um Q.A ou SQA?
S.Q.A se refere a garantia de qualidade de software. E Q.A é a garantia de qualidade, como podem ver um é mais amplo do que o outro. Por que em um projeto pode ser que você não entregue só código, por acadar entregando processo, serviço, metodologia e esses são items que não se consegui via código.
Q.A e testes dentro do desenvolvimento de software?
Isso é perfeitamente possível, métodos como o RUP e o Open Up especificam tarefas e papéis para serem desempenhados no desenvolvimento de software envolvendo a disciplina de testes e ainda as disciplinas de Gerência de Configuração e Analise de Requisitos.
O FDD vai um pouco mais além e foca na revisão de código por exemplo que é algo muito importante. Eu já participei de revisões mas na maioria constituídas de revisões de requisitos. As revisões são em certos casos o mecanismo mais eficiente que você tem para melhorar a qualidade do seu produto e do seu processo.
Não esqueça do processo
Use um ciclo de PDCA assim como propõe o Scrum e melhore a qualidade do processo assim você estará melhorando a qualidade do produto também. Você precisa estar sempre avaliando os métodos de desenvolvimento de software para melhorar a qualidade dos mesmos.
Veja que desta forma A garantia da qualidade só vai ser atingida com Testes, Revisões de códigos, design, requisitos, arquitetura, processo. Mas para isso você precisa saber o quanto as coisas vão bem ou vão mal, ai que entram as métricas, um profissional de Q.A normalmente pega todas essas "coisas".
Q.A não é a barreira para problemas
Se você pensar que a equipe de testes ou a equipe de SQA é a barreira pra problemas você terá muitos problemas. Você deve mudar essa cultura e pensar que a qualidade tem que vir em todas as disciplinas, começando pelo desenvolvimento que essa deve ser a primeira barreira, Q.A é a ultima barreira depois disso os bugs já estouraram para o cliente.
Q.A não é só auditoria de processo
Muitos pensam que Q.A é focar em auditar o processo, ou seja, você define um processo e o cara de Q.A diz se o processo está sendo seguido ou não, na verdade é muito mais que isso. Você precisa melhorar o processo se for o caso, precisa se preocupar com a qualidade do produto, com a qualidade dos requisitos, o Q.A ajuda identificar problemas de qualidade em geral, isso não é tarefa de uma única pessoa e sim de toda a equipe.
