Publicidade - Adsense

Melhoria de metodologia de testes - processo geral (sem documentação ou planejamento)



  • Atualmente, trabalho em uma empresa que desenvolve sistemas públicos em VB. No caso, meus testes são feitos com base em ordens de serviço (não querem que eu teste o sistema em geral, somente mudanças requisitadas pelos clientes).

    Por falta de regra de negócio, o máximo que eu posso fazer é pedir para que o atendimento redija a ordem de serviço de maneira detalhada. Eu pedi (e fui lindamente ignorado) para adotarem o padrão de “Esperado, obtido e Passo a passo” e tentarei convencer o pessoal a adotar esse padrão.

    No meu caso, nessa situação, o que eu poderia fazer para melhorar esse processo de testes?

    Fatores principais:
    1 - Falta de regra de negócio (documentação baseada UNICAMENTE em ordens de serviço)
    2 - Falta de padronização de abertura de ordens de serviço
    3 - Sistema feito em VB



  • Bom, na minha opinião, o que mais impacta seus testes são a falta de requisitos, uma vez que isso deve gerar uma dúvida constante sobre “o que testar ?” kkk …
    Onde trabalho também fazemos desenvolvimento/teste sobre demanda, com abertura de OS, e com pouca descrição de requisitos em muitos casos.
    Não sei qual a possibilidade de comunicação ai, mas aqui conseguimos contornar isso indo direto ao usuário interessado, e obtendo o máximo de informações possíveis dele. Acaba sendo um trabalho misto de requisito/testes, mas que tem dado resultado.
    E uma outra coisa, como usamos especificação por exemplo, sempre que um novo requisito é obtido ele vai para os scripts de teste(Que acaba sendo como uma documentação), e isso garante que aquela informação não é mais perdida.

    Espero ter ajudado um pouco amigo.



  • @thiagofp18 Entendi. Você recomenda alguma mudança nessa burocracia?

    Hoje o que temos é o seguinte:
    1 - O atendimento em conjunto com o cliente abre a ordem de serviço
    2 - O meu superior analisa a OS e à aloca em uma sprint, de acordo com a urgência
    3 - Os devs produzem (em 90% das vezes tendo que retornar para o atendimento, pois nem eles tem acesso à uma regra de negócio e as OSs são abertas de maneira aleatória e sem padronização, as vezes de difícil entendimento)
    4 - Após analisada e solucionada a OS, os devs documentam o que foi feito
    5 - Eu, por meio de interpretação própria de tudo que foi feito anteriormente tenho que entender e testar o que foi modificado no sistema (fluxos, funcionalidades, validações de campos, etc)

    Para melhorar esse processo, você acha que ao invés do esquema ser Atendimento/devs/tester, mudar para Atendimento/tester (planejamento de teste)/ devs/ tester?

    Em sua opinião, o que está de mais errado no processo existente hoje aqui? (além da falta de documentação)



  • Não entendi bem uma coisa, o seu superior que faz a análise da OS, tem contato com o cliente para questiona-lo ?
    Acredito ser importante a entrada do tester ai, pois uma vez que não há requisitos formais muitos questionamentos irão surgir. Não há possibilidade de criar esse canal de comunicação com o usuário?
    Ou pelo menos uma reunião de requisitos(com a participação do usuário) durante o planejamento da sprint, para uma apresentação das atividades?

    Uma sugestão que tenho, é que criar um repositório formal(SVN, GIT, etc…) documentando todo requisito obtido durante os atendimentos dessas OS, para que a informação já obtida não se perca, e vocês possam atualiza-la quando necessária.



  • Entendi. Teoricamente, os funcionários do Atendimento tem todo o entendimento necessário para a abertura da OS. O grande problema é a maneira como eles mandam a OS para nós, testers e devs. No caso, não existe nenhum padrão, e na maioria das vezes falta informação. Sendo assim, quando surgem dúvidas sobre o entendimento do que foi requisitado, eu devo ligar para o setor de atendimento e tirar as dúvidas com o responsável por abrir a OS. Como já dito, eu tentei dar um toque para padronizarem a abertura de OS (esperado, obtido e passo a passo) mas foi em vão.

    Existe um controle de versão, o que não existe são as regras propriamente ditas escritas. Entenda o por que: Temos em média 60 clientes, que utilizam nossos sistemas de IPTU, ISS, Água, etc. (isso no meu setor de tributos). Todos os clientes basicamente usam o mesmo sistema, mas cada um precisa de uma regra em particular diferente (que mudam com MUITA frequência, com bilhões de particularidades cada. Braselelel), graças à isso, praticamente TUDO no sistema é parametrizado e dependente de N regras, o que acaba tornando praticamente impossível uma documentação. (seriam 60 bíblias, cada uma com N alterações diárias. Isso só levando em consideração o setor de Tributos, não levando em conta os outros sistemas de escolas, médicos, etc…)



  • @Dogola contratos públicos são sempre complicados. Segundo o que entendi ( me diga se estiver errado) seus problemas são :

    1. OS sem padrão de preenchimento, o que gera retrabalho e demora para concluir OS
    2. Não te deixam testar coisas fora da OS, o que consequentemente vc nao consegue avaliar impacto da correção em outros itens. Muitas vezes pode descobrir quando estiver em produção
    3. Falta de documentação, com isso se precisar mudar algo vc nao sabe que funcionalidades estão usando. Logo mais erro descoberto quando estiver em produção

    Trabalho em contrato publico sei como é isso.

    Minhas dúvidas :

    1. Seu contrato é ponto de função?
    2. Sua empresa/equipe está com escopo só de desenvolvimento e teste?
    3. vc tem algum processo que usa? Qual?
    4. Vc já viu o edital do desse contrato?
    5. Sabe quais são os SLA’s que sua empresa precisa atender?
    6. Como é o clima do cliente? Eles são abertos a pedido de melhoria? Aceitam bem propostas novas?
    7. Se for ponto de funcao quem faz a contagem?
    8. Quantas pessoas tem sua equipe? Dado a quantidade de cliente e sistemas deve ser relativamente grande


  • @granadeiro Então, eu estou à somente 3 meses aqui então não sei se poderei te responder com exatidão todas as perguntas.

    1 - Não me lembro ao certo, mas por mais que não fosse, como eu trabalho meio que diretamente por meio de instruções do meu superior, questionar isso neste ponto não seria bacana a meu ver.

    2 - A minha equipe, sim.

    3 - No caso, eu analiso as ordens de serviço e o que foi feito, quando vejo a necessidade (complexidade) crio casos de teste, e quando não, realizo o teste da funcionalidade/campos. Caso encontre bugs, volto a OS para execução com as informações “Esperado/obtido/passo a passo”. E em todas as situações, evidencio e salvo em um pptx.

    4 - Não, e nem sei se teria acesso :(

    5 - Desenvolvimento e suporte. Realizando alterações, correções etc. sempre que necessário. (Graças à esse ponto de venda que o controle é difícil)

    6 - Sim, aceitam. Por se tratar de assuntos delicados e extremamente complexos (ou mais burocráticos mesmo) certas vezes nem o cliente sabe exatamente o que quer. Sendo assim, diversas vezes o atendimento os guiam para o caminho certo, com propostas, dicas, etc.

    7 - Não sei te responder.

    8 - 2 testers, meu superior (analisa as OSs, auxilia os programadores, sai no tapa com o atendimento) 3 devs e creio eu, que 8 no atendimento.

    Por mais que eu seja inexperiente, eu não consigo olhar pra tudo isso e pensar que está da melhor maneira que poderia estar. (no caso, o fluxo de teste) Eu queria melhorar e padronizar/profissionalizar mais esse processo.

    A, e obrigado pela atenção!!!



  • Ola @Dogola,
    Vamos em alguns pontos

    1 - Não me lembro ao certo, mas por mais que não fosse, como eu trabalho meio que diretamente por meio de instruções do meu superior, questionar isso neste ponto não seria bacana a meu ver.

    Não vejo problema em perguntar, tudo depende de como e se explicar o porque. Em melhoria de processo é importante saber isso. Se você trabalha com ponto de função precisa ver o racional que usou para chegar ao seu ponto de função. Exemplo: Você na sua proposta informou que 1 PF custa 50,00. Se você considerou só o esforço de implementação é um cenário se você considerou que para produzir aquele ponto precisou do esforço de requisitos, implementação e teste já é outra cenário. No segundo, o seu valor já cobre isso, você poderia fazer essas atividades. No primeiro cenário seu valor não cobre e se incluir vai acabar gerando prejuízo no projeto, como são atividades que não podem deixar de ser feito, pois aumenta o retrabalho a coisa fica mais complicada. Precisará buscar meios para conseguir isso com pouco custo.
    Claro que muda muito de acordo com a cultura da empresa. Você éo melhor para falar de como é ai.

    2 - A minha equipe, sim.

    Se sua equipe tem escopo de teste você em tese poderia fazer tudo que precisa de teste.

    3 - No caso, eu analiso as ordens de serviço e o que foi feito, quando vejo a necessidade (complexidade) crio casos de teste, e quando não, realizo o teste da funcionalidade/campos. Caso encontre bugs, volto a OS para execução com as informações “Esperado/obtido/passo a passo”. E em todas as situações, evidencio e salvo em um pptx.

    4 - Não, e nem sei se teria acesso :(

    Como é empresa publica teve edital. Isso é publico. Deve estar no site do órgão ai. Pergunto isso, porque o edital informa o que o fornecedor é obrigado a entregar e qual o fluxo. Se la fala que precisa fazer alguma documentação pode ser sua saída. Você pode alegar que é importante criar, pois amanhão o órgão pode multar por não ter entregue. Ou mesmo o tribunal de contas. Mas cuidado com isso, pode soar meio pesado. Tem que ir sentindo o clima e ganhando confiança para tocar nesse assunto.

    5 - Desenvolvimento e suporte. Realizando alterações, correções etc. sempre que necessário. (Graças à esse ponto de venda que o controle é difícil)

    SLA seria o acordo de nível de serviço. Tipo tempo médio para atender uma OS de melhoria. Tempo médio para atender erro OS de erro. Quantidade mínima de erro encontrado em release publicada. Se tiver (isso pode ter no edital) é um argumento para justificar testar melhor ou documentar melhor para atender esses SLA’s

    6 - Sim, aceitam. Por se tratar de assuntos delicados e extremamente complexos (ou mais burocráticos mesmo) certas vezes nem o cliente sabe exatamente o que quer. Sendo assim, diversas vezes o atendimento os guiam para o caminho certo, com propostas, dicas, etc.

    7 - Não sei te responder.

    8 - 2 testers, meu superior (analisa as OSs, auxilia os programadores, sai no tapa com o atendimento) 3 devs e creio eu, que 8 no atendimento.

    Por mais que eu seja inexperiente, eu não consigo olhar pra tudo isso e pensar que está da melhor maneira que poderia estar. (no caso, o fluxo de teste) Eu queria melhorar e padronizar/profissionalizar mais esse processo.

    A, e obrigado pela atenção!!!

    Tentar responder de maneira geral porque depende muito de cada situação e empresa e o processo utilizado.

    Vocé poderia propor implantar uma ferramenta para receber esses pedidos. Ai avaliar se vai anexar a OS ou partir dele gerar a OS. Importante a ferramenta ser customizável, pois no formulário onde vai ser aberto você cria campos os com os dados que precisa e os torna obrigatórios.
    Você pode criar workflow para que se a OS não tiver informações suficientes voces devolvem e só iniciar até estar ok.

    Outra possibilidade é ir para um status que não está sob sua repsonsabilidade. Você ou se analista de requisitos faz uma reunião esclarece tudo e coloca na ferramenta. Alguém do cliente só teria que dar ok para falar que está correto.

    quanto a documentação é avaliar se tem que entregar por contato algo ou não. SComo é um produto core que adapta para cliente cliente, provavel que sua ferramenta de controle de versão vc tenha uma linha (branch) para o cor e outra para cada cliente. Dentro de cada ou seguindo a mesma lógica vc precisará criar algo que documento essas regras. Você precisa disso para saber se ao mudar alguma regra se vai impactar em outro cliente.

    O X da questão é como vai documentar. Pode ser:

    • RN,
    • Um documento de word para cada funcionalidade e cliente, onde coloca asregras e divide por assunto
    • Se você automatiza testes unitários ou testes funcionais também serve como uma documentação. Sabendo o que testa você sabe ali pode ser uma RN

    Você não vai conseguir fazer uma força tarefa para do zero documentar tudo. Não vale o custo. O que pode fazer é surgiu um OS na funcionalidade A do cliente 1. como tem atividade ali, documente ali. Amanhã surgiu OS da funcionalidade B do cliente 2. Com o tempo terá algo mais completo.

    Verifique se seus desenvolvedores conseguem criar testes unitários a partir de agora. se para cada OS começar a criar teste unitário com o tempo terá uma suite completa. Com isso você poderá testar muito mais rápido coisa de outras funcionalidade fora da OS para verificar se teve impacto.



  • Boa Tarde! Me desculpem pela demora do retorno.

    Realmente, muito obrigado pela atenção, vocês me ajudaram a ter um horizonte mais afunilado, por assim dizer hahaha.
    Vou levar em consideração as sugestões e tentarei alinhar o fluxo de trabalho que nós temos aqui com o pessoal.
    Abraço! e muito obrigado, mesmo.


 

Publicidade - Adsense

status at

21
Online

2.8k
Usuários

1.7k
Tópicos

5.7k
Posts

});