Curso Gratuito de Automação de Testes Para Iniciantes

Disponível no
Youtube

 

Casamento da Qualidade com o Teste de Software

qualidade-teste-software

Casamento da Qualidade com o Teste de Software

  Todos nós ao comprar algum produto, primeiro verificamos a qualidade do mesmo, pensando sempre se ele vai ser durável ou não. E isso vale para todo tipo de objeto, de 1.99 à serviços. Eu vejo sempre meus pais dizendo que os móveis e objetos da época deles eram mais duráveis e os de hoje em dia não possuem essa qualidade. Mas o que é essa tão falada qualidade? Tic tac, Tic tac …. Esgotou seu tempo leitor. Bom vamos ao conceito popular: “Qualidade é o que a pessoa valoriza naquele objeto, naquele exato momento”, ou seja ela é algo subjetivo e pessoal. Não ajudou? Vamos ao exemplo: Você está querendo comprar um chocolate e acha que o de qualidade é da marca X porque ele tem uma textura e consistência que a marca Y não tem. Seu amigo(a) já gosta da marca Y e diz que a qualidade dos chocolates dela são melhores porque possuem mais cacau do que outros ingredientes. Viram cada um tem um conceito pessoal de qualidade. Ela é subjetiva, mas dá valor a um produto e marca. E lá no fundo sabemos que é isso que move o capitalismo! Agora vamos ver a abordagem didática da qualidade. Para Garvin a qualidade é definida em 5 abordagens: 

 

  1. Transcendente: qualidade é sinônimo de excelência, ou seja o melhor em termos de atributos é que tem a qualidade.
  2. Características do Produto: quantidade de atributos que o produto apresenta, que atraem os olhares do consumidor que os interpreta como qualidade.
  3. Baseada no Usuário: é subjetiva e está ligada às preferências do consumidor.
  4. Baseada na produção: atende às especificações, excelência atingida já na primeira vez.
  5. Baseada no valor: o preço é fator decisivo para o consumidor atestar a qualidade. Impera soberana nos tempos atuais.  

  

 Temos aqui a prova que qualidade tem um conceito de difícil entendimento, são muitas variáveis que chegam num mesmo resultado. Mas podemos perceber que tem uma dessas variáveis que nos deixa bem claro o objetivo da qualidade: SER O MELHOR PRODUTO. Então desse ponto no passado várias empresas começaram a pensar? Certamente sim, vamos dar uma volta na história?

  Desde dos primórdios da humanidade se procura a perfeição: as pirâmides do Egito, precisos cálculos matemáticos, durabilidade das obras romanas são alguns exemplos. O código de Hamurabi mostra a ênfase que se dava para a perfeição: 

 1700 a.C.: Art. 25 § 227 – “Se um construtor edificou uma casa, mas não reforçou seu trabalho, e a casa que construiu caiu e causou a morte do dono da casa, esse construtor será morto”; Ninguém hoje em dia irá matar o dono da empresa de smartphone porque ele pegou fogo, entretanto a marca perde dinheiro por ser considerada de baixa qualidade. Vamos adotar aqui a classificação histórica de David Garvin, que possui 4 Eras:

 

  • Inspeção (antes da industrialização)
    • Objetivo era separar o produto bom dos ruins.
    • Qualidade era vista como uma beleza artística.
  • Controle de Qualidade (após a industrialização)
    • Objetivo produzir um produto de acordo com as especificações.
    • Qualidade: vender um produto que corresponda com as especificações.
  • Garantia de Qualidade (década de 30 e 40)
    • Manter a qualidade estável e procurar melhorá-la sempre.
    • Surgem os primeiros trabalhos científicos e as primeiras ferramentas.
  • Gestão da Qualidade Total (década de 60, 70 e 80)
    • Objetivo é a satisfação do cliente.
    • Qualidade é responsabilidade de todos.

  

  O leitor deve estar se perguntando e nos tempos atuais? Continua a mesma coisa?Com certeza não! Vivemos num mundo em que a tecnologia domina tudo e é parte importante da sociedade e da economia. Pense bem tudo é controlado por sistemas, e se esses falham? O que acontece? Então estamos atrelados à qualidade desses sistemas? Sim, pela primeira vez falamos em qualidade de software, mas antes dos conceitos vamos pensar e refletir aqui um pouco? Se os produtos hoje em dia para serem fabricados e criados dependem do software, podemos dizer que se houver uma perda de qualidade nesse produto pode ser que um dos culpados sejam os softwares envolvidos nessa produção? De certo modo sim, quem nunca viu aquela bala que vem sem o embrulho? Aqueles brinquedos que estão pintados em lugares errados (olho na bochecha), tela azul, travamento ao carregar um vídeo entre outros exemplos. Perceba a evolução da excelência da qualidade de software no mundo que criamos, ou seja a importância de quem trabalha com essa área do conhecimento da engenharia de software.REFLITA.

  Segundo a IEEE 610/1990 qualidade de software é: ” O grau em que o sistema, componente ou processo atende os requisitos especificados e as expectativas e necessidades do cliente ou do usuário”. Consegue leitor ver onde essa definição se baseia? Olhe as 5 abordagens de Garvin duas são usadas na qualidade de software: baseada no Usuário e baseado na Produção, ou seja os requisitos e necessidades dos usuários são as características da qualidade mais importantes no software.

  Sabemos que a qualidade é subjetiva mas é a qualidade aplicada no software? Sim também é, sei que você está pensando ou pensou diferente. Olhe bem, para você o que seria qualidade no software?

 

  Tenho certeza que respondeu vários conceitos ou então palavras que são ambíguas como desempenho, escalabilidade, segurança, confiabilidade. Essas palavras são tão abrangentes que nós não respondemos a pergunta. Somente esboçamos uma resposta em uma infinidade de possibilidades. Essa é confusão que foi criada sobre o que é qualidade de software. Então é culpa das normas? Não, elas estão certas em sua totalidade a culpa é nossa por não saber ser mais claro e entender o que é qualidade. Quando você ou alguém responder o que levantamos aqui, tente levar as palavras para um contexto, faça a seguinte pergunta estou comparando isso com o que? Exemplos:

 

  • Nosso processo não é bom. Comparado com o que?
  • A segurança do nosso sistema é péssima. Comparado com o que?
  • O sistema precisa ser rápido. Comparado com o que?

 

 Segundo Marcus Blankenship quando você pergunta isso duas respostas aparecem:

 

  1. A resposta é refinada e fica menos abrangente.
  2. Olhar vazio!

  

 Não é de primeira que vai chegar na resposta desejada, repita o quanto quiser esse método. Sobre o olhar vazio, somente olhe de volta para pessoa com o mesmo olhar e deixo-o pensar, assim você irá sacudir os pensamentos dele(a). E qual é o objetivo disso? Ensinar as pessoas a terem pensamentos mais específicos sobre temas abstratos. Quando todos que trabalham construindo o sistema entenderem aonde querem chegar e o que é qualidade para aquele produto, toda a equipe vai buscar o mesmo objetivo e suas ações estarão voltadas para a mesma direção.

  Certo agora já sabemos o que é qualidade, mas temos que nos aprofundar ainda mais para entendermos pontos importantes para nós analistas de qualidade. Ela se divide em tipos, os dois principais são: qualidade do processo e qualidade de produto. 

  Em qualidade de processo iremos ver duas visões, então vamos começar pela primeira. O que é um processo para você leitor? O IEEE define o processo como uma sequência de passos realizados para um determinado fim. O processo de software é uma série de atividades, práticas, eventos, ferramentas e métodos que garantem na parte técnica e administrativa que o software vai ser desenvolvido com qualidade. O objetivo de uso do processo de software é tornar fácil a produção de sistemas com qualidade, conseguindo atender as necessidades dos usuários finais dentro de um cronograma e orçamento definidos. Outro ponto importante é que o processo de software tem que ser adequado a cada projeto, pois muitas características como tecnologias a serem adotadas e características da aplicação vão ser diferentes. 

  As atividades chaves para o processo de desenvolvimento são: análise e especificação dos requisitos, projeto, implementação e testes. Juntamente com a escolha de qual ciclo de vida será usado no projeto influenciam como o processo vai ser estruturado. Outros fatores que se juntam aos já citados são: tipo de software, paradigma de desenvolvimento, domínio da aplicação, tamanho e complexidade do sistema entre outros. Podemos ver que não é tarefa fácil definir um processo, por isso que não se pode aplicar algo genérico em todos os sistemas que serão feitos.

  Independente do processo podemos ver 4 pontos que aumentam a qualidade do software a ser feito:

 

  1. Alcance: capacidade de lidar com várias tecnologias e outros sistemas.
  2. Trazer o conhecimento da engenharia de software: utilizar os padrões de implementação da engenharia de software de forma correta para haver um aumento de qualidade.
  3. Métricas: as métricas devem orientar o que fazer primeiro ou os próximos passos, senão se tornam somente estatísticas.
  4. Automatização: não são os testes automatizados e sim uma característica que o sistema tem que ter, ele deve ser construído com os 3 pontos acima de forma fluida, ou seja naturalmente sem precisar de um funcionário ou equipe para indicar que o sistema precisa seguir esses pontos. É aqui que se aplica a parte do entendimento da decisão da equipe do que é qualidade daquele produto em questão. Todos seguirão o que foi decidido e esses 4 pontos serão feitos de forma natural.

  

  Nesta visão que estamos estudando também podemos classificar o processo em imaturo ou maduro. Um processo para ser imaturo tem essas características: feito improvisado por profissionais e gerência, não é seguido na sua totalidade, dependente dos profissionais, sem visão de progresso e da qualidade, cumprir o prazo é mais importante que a qualidade do produto, custos de manutenção excessivo. Portanto é um processo descontrolado que afeta a qualidade do sistema que está sendo feito. Já o processo considerado maduro possui as características: as linhas de ação levam em consideração o processo e o trabalho é concluído na sua totalidade, ele é definido, documentado e controlado de forma constante, tem apoio da administração e gerências, é bem controlado, são usadas medições do produto e do processo. Então vemos que há um nível de controle e qualidade elevado no processo todo.

   Muitos de nós tem terror em ouvir falar em normas, eu também tinha na minha graduação, mas temos isso porque não conseguimos aprender e estudar da maneira certa. Alguns acadêmicos acham que decorar já é ensinar e aprender, na minha pequena e humilde opinião não é por aí. Para aprender algo devemos ter uma linha de raciocínio mesmo que seja um material super denso de conceitos, o objetivo não é decorar e sim entender. Mas por que eu estou falando isso leitor? A segunda visão da qualidade do processo é da ISO 12207 (2017) que iremos aprender agora!  

   A ISO 12207 fala de todos os processos do ciclo de vida do software, define os termos para a comunicação (terminologia) e os processos necessários para a organização ou um processo específico. Ela é a base para a melhoria dos processos. Considera o software como parte de um sistema e também trata de aquisição, fornecimento, desenvolvimento, operação, manutenção e descarte. Certo o que é um processo para a 12207? É um conjunto de atividades inter-relacionadas ou interagindo que transformam entradas em saídas, ou seja, atividades que são feitas para dar um resultado. As características principais do processo para a 12207 são: tem que ter um objetivo, o resultado é de valor para uma organização, ele pode quebrar fronteiras e envolver várias empresas.

Vamos ver um pouco agora das nomenclaturas:

 

  • Estágio/Fase: período de tempo em que atividades são relacionadas.
  • Disciplina: conjunto de atividades relacionadas.
  • Atividade e tarefa: o processo é quebrado em partes (dividir para conquistar) que são atividades. Elas também são quebradas em partes e formam as tarefas.
  • Para cada tarefa são definidos os passos e decidi-se os procedimentos (tecnologia) que serão utilizados nos passos.
  • Papel: função que as pessoas assumem no processo, ou seja o foco é na função e não na pessoa.
  • Recurso: algo necessário para executar o processo.
  • Artefato: algo gerado pelo processo, seja um artefato intermediário ou final.

  

  Leitor perceba que uma definição está ligada na outra. Isso nos ajuda no entendimento. De tudo isso a ISO 12207 só define: o objetivo do processo, os resultados esperados (ideias do que se quer obter) e quais são as atividades e tarefas. A norma não trata do resto: estágios, modelos de ciclo de vida, passos, ferramentas ou artefatos, tudo isso depende de quem está adaptando a norma para a realidade da empresa. Portanto não tem como usar a norma do jeito que ela está, é necessário mexer e fazer alterações. Temos que fazer uma análise porque dependo da empresa alguns processos da 12207 não precisam ser aplicados. Ela também não define uma ordem das atividades.

 


  

  A 12207 define 4 grupos de processo e dentro de cada um tem vários processos definidos.

Processo acordo: acordo que a empresa tem que ter para contratar um software.

Processo organizacionais habilitadores do projeto: a empresa precisa ter esses processos para desenvolver o software, fazer manutenção, operar etc.

Processo de Gerência técnica: processos de gestão, a empresa tem que gerenciar os projetos, seja formal ou informal.

Processos técnicos: são os processos de desenvolvimento o que mais vemos na nossa carreira. A 12207 define vários processos técnicos.

 

 

  Como podemos ver na imagem acima nem sempre um estágio de desenvolvimento vai conter somente um processo. A grande maioria possui mais. Chamo atenção para as disciplinas (estágios) implementação e teste na imagem, aqui temos o ponto de encontro dos noivos qualidade de software e teste de software. Brincadeira a parte, teste de software está incluído na qualidade de software, é uma peça e importante para ela. Por isso o título desse artigo é o casamento da qualidade de software com o teste de software. Uma boa analogia entre os dois é: podemos considerar a qualidade de software um guarda chuvas e o teste juntamente com outras(os) estágios estão debaixo desse guarda chuvas. Podemos ver também que os principais processos da 12207 que tratam de qualidade são: processo de gerência da qualidade, processo de medição garantia da qualidade, processo de verificação e validação. A imagem abaixo mostra isso.

 


 

  Concluindo a 12207 é uma norma que cuida somente dos processos de software, outras normas vão tratar de produto. Provado então que as normas não são chatas, mas sim a maneira que ela é ensinada e estudada. Decorar não é aprender! Defina uma linha de raciocínio como a imagem abaixo para entender as normas.

 


  Iremos falar agora de qualidade de produto, primeiro temos que entender o que é um modelo de qualidade. Eles definem as características de qualidade de um software ou sistema computacional. Exemplos: Boehm, McCall e a família de normas ISO 25000. São usados para auxiliar na especificação de requisitos e para medir e avaliar a qualidade. Vamos trabalhar nesse artigo com a família de normas ISO 25000. Então vamos criar nossa linha raciocínio, do que a norma trata? Dos requisitos e a avaliação da Qualidade do produto de software. Como é a organização do conhecimento da qualidade de software? Existe uma hierarquia: 1- Característica, 2- Subcaracterística, 3- propriedade da qualidade. Então uma característica possui algumas subcaracterísticas que possuem várias propriedades. As propriedades é o que medimos e podem fazer parte de mais de uma subcaracterística. Exemplos: linhas de código, precisão de um cálculo, tempo de garantia etc.

E como é o modelo de qualidade da 25000? Ele possui as seguintes características: 

 

  • Qualidade do produto: ponto de visto do produto.
  • Qualidade em uso: Representa o quanto o uso do software cumpre as necessidades e atinge metas de um usuário, ou seja, depende do contexto de uso e das características do usuário e da tarefa, hardware, ambiente de operação e ambiente social. “Considera o usuário”.

 

  Outro tópico para entendermos é a divisão do modelo de qualidade do produto. Ele é dividido em 8 características que possuem suas subcaracterísticas.


Vamos aprender o que cada uma significa:

 

  • Adequação Funcional: Trata do quanto o produto prova que as  funções e necessidades levantadas pelos stakeholders estão sendo cumpridas.
  • Eficiência de Execução: Trata do desempenho relativo a quantidade de recursos (rede, memória, processador etc).
  • Compatibilidade: Trata do quanto o produto pode compartilhar recursos e informação com outros produtos.
  • Usabilidade: Trata quanto é fácil usar o produto.
  • Confiabilidade: Trata o quanto o produto executa as suas funções nas condições especificadas e no tempo adequado.
  • Segurança: Trata do quanto as informações são protegidas.
  • Manutenibilidade: Trata o quanto é fácil modificar esse produto.
  • Portabilidade: Trata o quanto é fácil colocar esse produto em um outro ambiente.

 

  Vamos lembrar agora da analogia do guarda chuva da qualidade, todas essas propriedades estão embaixo dele, junto com o teste que na ISO 25000 está na manutenibilidade. Devemos lembrar aqui que essa ISO é só uma base, é impossível atingir  o mais alto grau de qualidade em qualquer produto. E o leitor recorda que a qualidade depende do ponto de vista de cada um? Aqui se aplica essa máxima, mas direcionado ao produto. Então os stakeholders vão entrar em acordo sobre esse tema.

” A qualidade deve ser necessária o suficiente para o produto”

  Antes de finalizarmos mais uma jornada no mundo de QA, vamos falar duas questões que são relevantes. Para você leitor, testador de software tem a mesma função de um QA? Como vimos teste está contido na qualidade de software, portanto o testador é uma parte da qualidade como um todo. O QA nesse caso seria o que cuidaria de todo o processo de qualidade. O que vemos no mercado, como falado no meu último artigo é uma convergência para não existir mais divisão do conhecimento e sim um profissional com muitos saberes. A outra questão é que lá em 2017 a empresa QASymphony dos EUA, levantou 6 razões para dizer que QA é o trabalho do futuro. Adivinhem ela acertou em tudo. Obrigado leitores por lerem até aqui e estejam preparados para nosso próximo artigo. 

 

Aulas, artigos e vídeos que eu indico sobre o tema

 

https://administradores.com.br/artigos/historico-da-qualidade-uma-passagem-pela-producao-e-as-suas-ferramentas

https://administradores.com.br/artigos/um-breve-historico-da-qualidade

https://medium.com/@isabellasilveira/os-pilares-da-qualidade-de-software-e-como-garanti-los-620e9c626e8c

https://medium.com/@marcusblankenship/why-software-quality-is-so-confusing-and-how-to-fix-it-6bc48f2123b7

https://medium.com/qasymphony/6-reasons-why-qa-manager-is-the-job-of-the-future-60c423640569

https://www.youtube.com/watch?v=b2T438aPrHw&t=618s&ab_channel=UNIVESP

https://www.youtube.com/watch?v=TbIkCcxEld4&ab_channel=UNIVESP