Quantos exames você já fez em máquinas que poderiam de alguma forma, se mal configuradas, prejudicar a sua saúde? Softwares que lidam com a saúde humana são considerados software de segurança crítica. Preciso comentar que esses softwares devem passar por uma bateria de verificações e validações bem mais rígida que quaisquer outros? Ou explicar os motivos? Estamos lidando com a vida do ser humano, e um erro pode causar danos sérios, quiçá irreversíveis.
Em junho a lei seca, também conhecida como de tolerância zero, fez seu primeiro aniversário. Uma lei que estipula condições de liberdade caso o condutor de um veículo apresente mais de 0,2 grama de álcool por litro de sangue.
Numa pesquisa rápida no Google cheguei ao resultado que na capital paulista em 2005, o álcool foi responsável por 45% das mortes no trânsito. Fora que o álcool é responsável por alterações nos sentidos, favorecendo o acontecimento de outros crimes e acidentes com seu consumo excessivo. Em um cenário caótico como esse, talvez a lei de tolerância zero seja mesmo a melhor opção para um combate radical a esses números absurdos.
A teoria, na minha opinião, é belíssima.
Mas vamos à prática. Como ocorre essa fiscalização? Através de testes de bafômetros. Como aparecem aqueles números? Através de um software! Um software que pode decidir a sua liberdade. Então, se esse software é responsável por algo tão sério, obviamente é um software que passa por uma bateria de verificações e validações bem mais rígida que quaisquer outros, certo?
“The program presented shows ample evidence of incomplete design, incomplete verification of design, and incomplete “white box” and “black box” testing. Therefore the software has to be considered unreliable and untested, and in several cases it does not meet stated requirements.”, é o que diz este artigo.
Vou reforçar em português: O programa apresenta ampla evidência de projeto incompleto, verificação de projeto incompleta, testes caixa branca e caixa preta incompletos. O software deve, portanto ser considerado não confiável e não testado, e em vários casos ele não atende os requisitos.
Este é o software que define ou não se um condutor será penalizado por essa lei. Veja a pena:.
Quem for flagrado com uma dosagem superior a 0,2 gramas de álcool por litro de sangue (equivalente à ingestão de uma lata de cerveja ou um cálice de vinho) pagará multa de 957 reais, receberá sete pontos na carteira de motorista e terá suspenso o direito de dirigir por um ano. Aqueles cuja dosagem de álcool no sangue superar 0,6 g/l (duas latas de cerveja) deverão ser presos em flagrante. As penas poderão variar de seis meses a três anos de cadeia, sendo afiançáveis por valores entre 300 e 1.200 reais. Os infratores também perderão o direito de dirigir por um ano.
Silvio Meira, professor Titular de Engenharia de Software do Centro de Informática da Universidade Federal de Pernambuco em Recife, cientista-chefe do Centro de Estudos e Sistemas Avançados do Recife (C.E.S.A.R) e engenheiro formado pelo Instituto Tecnológico de Aeronáutica (ITA), fala sobre ao assunto no seu blog.
Obviamente não estou questionando a necessidade de controle do álcool nas nossas vias, nem estou questionando a tolerância da lei. Estou questionando as ferramentas utilizadas para verificar o seu comprimento, ou melhor, a falta de comprometimento social das empresas e dos profissionais que liberam esse tipo de aplicação para serem usados pelo mundo.
A equipe desse software precisaria entender que seus clientes não eram seu gerente, o dono da empresa ou em primeira mão o governo que o compraria, mas pessoas que podem em algum momento ao invés de serem protegidas, serem penalizadas por esse produto.
quinta-feira, 9 de julho de 2009
Verificação – Inspeção
Sou uma pessoa privilegiada. Posso começar o post dizendo que ontem estava conversando com meu namorado sobre inspeções (e ele me entendia! :D). E foi isso que motivou o post.
Se você já leu Software Inspection de Gilb e Graham, talvez não tenha muita coisa interessante (ou melhor, nova) nesse post. Se não, eu o convido a refletir comigo sobre uma seção desse livro.
Na sua empresa, vocês inspecionam artefatos? Mesmo? Inspecionam ou 'revisam'? :)
Inspeção formal como estudamos vem da experiência de Michael E. Fagan na IBM, publicada como um artigo em 1974. Nesse livro, Tom Gilbs e Dorothy Graham explanam sobre esse trabalho, também com base em outros casos posteriores e complementares ao de Fagan, e com o suporte também de outras empresas que contribuíram para o livro.
No prefácio há um self-assessment para que você analise o seu processo de inspeção. Segue o mesmo abaixo com uma tradução livre :).
1. Você nega a entrada no processo de inspeção quando o produto a ser inspecionado não saiu de uma inspeção prévia? Se a resposta é não, você realiza primeiramente uma mini inspeção nesses artefatos ou pelo menos em uma amostra deles? Você proíbe a inspeção se os artefatos não estão com nível de qualidade adequado como resultado de uma mini inspeção ou similar?
Sempre – Geralmente – Algumas Vezes – Nunca
2. A reunião de abertura determina os objetivos da inspeção numericamente, e estabelece as estratégias correspondentes para alcançá-los?
Sempre – Geralmente – Algumas Vezes – Nunca
3. Os papéis são designados e definidos em checklists de papéis? Há uma biblioteca com esses checklists disponível para todos os líderes da inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca
4. O líder da inspeção verifica que para cada desvio registrado houve alguma ação do editor?
Sempre – Geralmente – Algumas Vezes – Nunca
5. As taxas de revisão individual e em reunião são atualizadas e comparadas com as taxas ideais, e usadas para planejar a próxima inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca
6. A razoabilidade das taxas é usada como critério de saída?
Sempre – Geralmente – Algumas Vezes – Nunca
7. O número de defeitos restantes após a edição é previsível? Se esse número é muito alto para o tipo de documento, o mesmo falha na inspeção? Em outras palavras, o número estimado de defeitos restantes é um critério de saída?
Sempre – Geralmente – Algumas Vezes – Nunca
8. A eficiência de detecção de defeitos é registrada? Esse dado é usado para estimar os defeitos restantes ao fim do ciclo de inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca
9. A quantidade substancial de desvios encontrados no documento é registrada? (Ex. uma média de 10% a 25% dos desvios registrados resultaram em requisições de mudança (CR))
Sempre – Geralmente – Algumas Vezes – Nunca
10. Líderes de inspeção são formalmente certificados de acordo com um critério documentado? Há uma lista atualizada de líderes certificados? Líderes não certificados são proibidos de rodar uma inspeção de software (a não ser sobre devida supervisão)?
Sempre – Geralmente – Algumas Vezes – Nunca
11. Há melhorias nas regras, procedimentos e checklists regurlamente?
Sempre – Geralmente – Algumas Vezes – Nunca
12. Os resultados das melhorias nos padrões de inspeção são compartilhados com todos os líderes de inspeção e os inspetores?
Sempre – Geralmente – Algumas Vezes – Nunca
13. Há uma biblioteca de materiais de inspeção (formulários, checklists, regras), que seja bem organizados e conhecido, usado por todos os líderes de inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca
14. Há um processo de reunião de brainstorming realizada para analisar as causas-raíz dos defeitos encontrados nos produtos de inspeção? Melhorias pequenas são implementadas imediatamente? Todas as sugestões de melhoria são formalmente registradas?
Sempre – Geralmente – Algumas Vezes – Nunca
15. Alguém ou algum grupo (geralmente o Time de Gerenciamento de Mudança de Processo) implementa melhorias no processo usando o banco de dados de inspeções?
Sempre – Geralmente – Algumas Vezes – Nunca
Agora, uma continha de padaria.
Sempre – 3 pontos
Geralmente – 2 pontos
Algumas Vezes – 1 ponto
Nunca – 0 ponto
E uma avaliação da sua pontuação:
45 (Perfeição)
Você não foi honesto com você mesmo!! :) Ninguém no mundo real alcança a perfeição! Volte e conte de novo a sua pontuação.
Entre 0 e 7
Não é exatamente considerado como nível. Definitivamente o que é feito não é uma inspeção. Fica a dica do livro ;)
Entre 8 e 15
Nível iniciante
Entre 16 e 23
Nível competente
Entre 24 e 31
Nível experiente
Entre 32 e 38
Nível estabelecido
Entre 39 e 45
Nível pioneiro
Claro que tem toda uma análise de perfil para essas pontuações. Mas a idéia do post era chamar atenção pro que se chama se inspeção por ai. Inspecionar não é revisar, passa o olho, etc. Consiste num processo estruturado que deve ser bem estudado antes de ser implementado. Fica a dica do livro que é A fonte para esse assunto.
Dúvidas sobre as perguntas e acusações de má tradução, podem colocar nos comentários para direito de defesa :D
Se você já leu Software Inspection de Gilb e Graham, talvez não tenha muita coisa interessante (ou melhor, nova) nesse post. Se não, eu o convido a refletir comigo sobre uma seção desse livro.
Na sua empresa, vocês inspecionam artefatos? Mesmo? Inspecionam ou 'revisam'? :)
Inspeção formal como estudamos vem da experiência de Michael E. Fagan na IBM, publicada como um artigo em 1974. Nesse livro, Tom Gilbs e Dorothy Graham explanam sobre esse trabalho, também com base em outros casos posteriores e complementares ao de Fagan, e com o suporte também de outras empresas que contribuíram para o livro.
No prefácio há um self-assessment para que você analise o seu processo de inspeção. Segue o mesmo abaixo com uma tradução livre :).
1. Você nega a entrada no processo de inspeção quando o produto a ser inspecionado não saiu de uma inspeção prévia? Se a resposta é não, você realiza primeiramente uma mini inspeção nesses artefatos ou pelo menos em uma amostra deles? Você proíbe a inspeção se os artefatos não estão com nível de qualidade adequado como resultado de uma mini inspeção ou similar?
Sempre – Geralmente – Algumas Vezes – Nunca
2. A reunião de abertura determina os objetivos da inspeção numericamente, e estabelece as estratégias correspondentes para alcançá-los?
Sempre – Geralmente – Algumas Vezes – Nunca
3. Os papéis são designados e definidos em checklists de papéis? Há uma biblioteca com esses checklists disponível para todos os líderes da inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca
4. O líder da inspeção verifica que para cada desvio registrado houve alguma ação do editor?
Sempre – Geralmente – Algumas Vezes – Nunca
5. As taxas de revisão individual e em reunião são atualizadas e comparadas com as taxas ideais, e usadas para planejar a próxima inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca
6. A razoabilidade das taxas é usada como critério de saída?
Sempre – Geralmente – Algumas Vezes – Nunca
7. O número de defeitos restantes após a edição é previsível? Se esse número é muito alto para o tipo de documento, o mesmo falha na inspeção? Em outras palavras, o número estimado de defeitos restantes é um critério de saída?
Sempre – Geralmente – Algumas Vezes – Nunca
8. A eficiência de detecção de defeitos é registrada? Esse dado é usado para estimar os defeitos restantes ao fim do ciclo de inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca
9. A quantidade substancial de desvios encontrados no documento é registrada? (Ex. uma média de 10% a 25% dos desvios registrados resultaram em requisições de mudança (CR))
Sempre – Geralmente – Algumas Vezes – Nunca
10. Líderes de inspeção são formalmente certificados de acordo com um critério documentado? Há uma lista atualizada de líderes certificados? Líderes não certificados são proibidos de rodar uma inspeção de software (a não ser sobre devida supervisão)?
Sempre – Geralmente – Algumas Vezes – Nunca
11. Há melhorias nas regras, procedimentos e checklists regurlamente?
Sempre – Geralmente – Algumas Vezes – Nunca
12. Os resultados das melhorias nos padrões de inspeção são compartilhados com todos os líderes de inspeção e os inspetores?
Sempre – Geralmente – Algumas Vezes – Nunca
13. Há uma biblioteca de materiais de inspeção (formulários, checklists, regras), que seja bem organizados e conhecido, usado por todos os líderes de inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca
14. Há um processo de reunião de brainstorming realizada para analisar as causas-raíz dos defeitos encontrados nos produtos de inspeção? Melhorias pequenas são implementadas imediatamente? Todas as sugestões de melhoria são formalmente registradas?
Sempre – Geralmente – Algumas Vezes – Nunca
15. Alguém ou algum grupo (geralmente o Time de Gerenciamento de Mudança de Processo) implementa melhorias no processo usando o banco de dados de inspeções?
Sempre – Geralmente – Algumas Vezes – Nunca
Agora, uma continha de padaria.
Sempre – 3 pontos
Geralmente – 2 pontos
Algumas Vezes – 1 ponto
Nunca – 0 ponto
E uma avaliação da sua pontuação:
45 (Perfeição)
Você não foi honesto com você mesmo!! :) Ninguém no mundo real alcança a perfeição! Volte e conte de novo a sua pontuação.
Entre 0 e 7
Não é exatamente considerado como nível. Definitivamente o que é feito não é uma inspeção. Fica a dica do livro ;)
Entre 8 e 15
Nível iniciante
Entre 16 e 23
Nível competente
Entre 24 e 31
Nível experiente
Entre 32 e 38
Nível estabelecido
Entre 39 e 45
Nível pioneiro
Claro que tem toda uma análise de perfil para essas pontuações. Mas a idéia do post era chamar atenção pro que se chama se inspeção por ai. Inspecionar não é revisar, passa o olho, etc. Consiste num processo estruturado que deve ser bem estudado antes de ser implementado. Fica a dica do livro que é A fonte para esse assunto.
Dúvidas sobre as perguntas e acusações de má tradução, podem colocar nos comentários para direito de defesa :D
terça-feira, 7 de julho de 2009
Vamos revisar o processo!
Recebi há pouco um e-mail muito legal da STP, com o artigo Is QA About People or Process?. Colei o artigo no final do post para quem tiver interesse.
Achei muito interessante o questionamento feito sobre controle de qualidade. Temos um bug em produção! Vamos rever o processo! :)
O processo de uma empresa deve ser algo vivo, ou seja, deve estar em constante aperfeiçoamento e sim, bugs e métricas relacionadas a esses bugs (bem como outras métricas e outros inputs) são utilizados como base para essas melhorias.
Falta ai uma consideração muito importante: pessoas!
São projetados procedimentos a serem seguidos, mas são pessoas que os vão seguir e onde temos pessoas, temos suscetibilidade a falhas. E nem todas as falhas devem necessariamente ser motivo de revisão no processo.
No artigo abaixo, Edward faz uma comparação interessante entre indústria de manufatura e de software e a aplicabilidade de modelos de qualidade nesses ambientes.
Is QA About People or Process?
By Edward J. Correia
Any time a defect gets through to production, companies have a tendency to reexamine their processes. “If we had tighter processes in place, this would not have happened,” is usually the thinking of management. If you deal with product quality, perhaps your reaction was something like, “Here we go again.”
But is quality control really about process? Can an air-tight process make up for sloppy, apathetic, or time-constrained people? Or, can a meticulous person assure quality despite controls that are less than perfect? Are people or processes most responsible for good quality?
Obviously, quality assurance involves a combination of the two. But according to V. Viswanathan, a quality analyst with international IT services company Virtusa, the answer might also depend on the industry. Having worked in manufacturing as well as software development, he believes that project-related endeavors like software development tend to be person-centric, whereas the manufacturing industry centers on process. “The amount of savings and benefits that occur in the software industry due to process improvement activities may not be really significant,” he says, whereas the Six Sigma process is a cornerstone of manufacturing.
“Six Sigma is mainly applicable to industries where operations or activities are identical,” he points out, hardly a characteristic of software development. “I don’t mean that Six Sigma is not applicable to software development. But by applying Six Sigma, drastic benefits may not be achieved as those that occur in the manufacturing industry."
Part of the Six Sigma strategy for business process improvement is to identify the root cause of a problem and then find and implement a solution. “In order for Six Sigma to be most effective, the operations have to be repeatable,” says Viswanathan. Hence, individual talent plays a far smaller role in manufacturing than in software development. Some of the differences include the following:
In manufacturing, each product is intended to be identical; in software development each product is customized (otherwise there would be nothing to develop).
Processes in manufacturing are the same for each operation; processes in software development vary in terms of content.
Most manufacturing workers perform at a similar level of effectiveness; software development workers’ abilities vary widely, as do their levels of skill and effectiveness.
As is true of many creative activities, the content involved with software projects can vary wildly, and operations related to application development will vary accordingly. “In software, the operations across projects might be similar, but are not identical. You may have the same set of phases…requirement analysis, design, coding, testing, and implementation… between projects. But the details of each are different,” he says.
Therefore, activities that you might have implemented to improve a process or solve a problem in one project may not be valid for another. “Also, the level of success might be different. Even if it is applicable, the consistency of success cannot be maintained across projects,” says Viswanathan. What’s more, errors are inevitable whenever human input is involved. And the places where errors turn up cannot be predicted. Such relative chaos is anathema to manufacturing, which relies on predictability and consistency for maximum output.
Each According to Ability
Perhaps the biggest difference between the software office and factory floor is the way in which each makes use of ability. A nimble factory worker might produce one percent more widgets and be less prone to injury than someone who is clumsy. But a skilled developer can become the basis of an entire industry (think Linus Torvalds).
The most effective software development team is one that combines skilled, competent and caring workers with solid, logical processes that work well and make sense to all involved. Because without buy-in from the team, your processes are not worth the paper they’re printed on.
Achei muito interessante o questionamento feito sobre controle de qualidade. Temos um bug em produção! Vamos rever o processo! :)
O processo de uma empresa deve ser algo vivo, ou seja, deve estar em constante aperfeiçoamento e sim, bugs e métricas relacionadas a esses bugs (bem como outras métricas e outros inputs) são utilizados como base para essas melhorias.
- Se minha empresa tem um processo maduro, então os softwares produzidos por ela serão sempre de excelente qualidade?
- Se minha empresa não tem um processo maduro, então os softwares produzidos por ela serão sempre de baixa qualidade?
Falta ai uma consideração muito importante: pessoas!
São projetados procedimentos a serem seguidos, mas são pessoas que os vão seguir e onde temos pessoas, temos suscetibilidade a falhas. E nem todas as falhas devem necessariamente ser motivo de revisão no processo.
No artigo abaixo, Edward faz uma comparação interessante entre indústria de manufatura e de software e a aplicabilidade de modelos de qualidade nesses ambientes.
Is QA About People or Process?
By Edward J. Correia
Any time a defect gets through to production, companies have a tendency to reexamine their processes. “If we had tighter processes in place, this would not have happened,” is usually the thinking of management. If you deal with product quality, perhaps your reaction was something like, “Here we go again.”
But is quality control really about process? Can an air-tight process make up for sloppy, apathetic, or time-constrained people? Or, can a meticulous person assure quality despite controls that are less than perfect? Are people or processes most responsible for good quality?
Obviously, quality assurance involves a combination of the two. But according to V. Viswanathan, a quality analyst with international IT services company Virtusa, the answer might also depend on the industry. Having worked in manufacturing as well as software development, he believes that project-related endeavors like software development tend to be person-centric, whereas the manufacturing industry centers on process. “The amount of savings and benefits that occur in the software industry due to process improvement activities may not be really significant,” he says, whereas the Six Sigma process is a cornerstone of manufacturing.
“Six Sigma is mainly applicable to industries where operations or activities are identical,” he points out, hardly a characteristic of software development. “I don’t mean that Six Sigma is not applicable to software development. But by applying Six Sigma, drastic benefits may not be achieved as those that occur in the manufacturing industry."
Part of the Six Sigma strategy for business process improvement is to identify the root cause of a problem and then find and implement a solution. “In order for Six Sigma to be most effective, the operations have to be repeatable,” says Viswanathan. Hence, individual talent plays a far smaller role in manufacturing than in software development. Some of the differences include the following:
In manufacturing, each product is intended to be identical; in software development each product is customized (otherwise there would be nothing to develop).
Processes in manufacturing are the same for each operation; processes in software development vary in terms of content.
Most manufacturing workers perform at a similar level of effectiveness; software development workers’ abilities vary widely, as do their levels of skill and effectiveness.
As is true of many creative activities, the content involved with software projects can vary wildly, and operations related to application development will vary accordingly. “In software, the operations across projects might be similar, but are not identical. You may have the same set of phases…requirement analysis, design, coding, testing, and implementation… between projects. But the details of each are different,” he says.
Therefore, activities that you might have implemented to improve a process or solve a problem in one project may not be valid for another. “Also, the level of success might be different. Even if it is applicable, the consistency of success cannot be maintained across projects,” says Viswanathan. What’s more, errors are inevitable whenever human input is involved. And the places where errors turn up cannot be predicted. Such relative chaos is anathema to manufacturing, which relies on predictability and consistency for maximum output.
Each According to Ability
Perhaps the biggest difference between the software office and factory floor is the way in which each makes use of ability. A nimble factory worker might produce one percent more widgets and be less prone to injury than someone who is clumsy. But a skilled developer can become the basis of an entire industry (think Linus Torvalds).
The most effective software development team is one that combines skilled, competent and caring workers with solid, logical processes that work well and make sense to all involved. Because without buy-in from the team, your processes are not worth the paper they’re printed on.
domingo, 5 de julho de 2009
Estudo CTAL: Processo de Teste
No Advanced Software Testing Vol 1 do Rex Black, processo de teste está no segundo capítulo. Segue abaixo um overview desse capítulo.
**
O processo de teste consiste em:
-- Planejar e Acompanhar
-- Analisar e Projetar
-- Implementar e Executar
-- Avaliar critérios de saída e reportar resultados do teste
-- Atividades de fechamento de teste
O foco do livro é dado nas 3 atividades do meio.
Análise e Projeto de Teste
Nas atividades de planejamento, o líder de teste e o gerente de teste trabalham junto aos stakeholders na definição dos objetivos de teste. No template IEEE 829, essa informação fica documentada em “Features to be tested”.
Um pouco mais sobre documentação e norma IEEE 829 em:
- Sem Bugs – Como documentar seus testes
- ANSI/IEEE 829-1983 IEEE Standard for Software Test Documentation –Description
A partir dos objetivos de teste, na fase de análise e projeto, são desenvolvidas as atividades de:
-- Identificar e refinar as condições de teste para cada objetivo de teste
-- Criar casos de teste que exercitem as condições de teste identificadas
Saber o que testar, ainda não é suficiente. É preciso saber em que ordem e o quanto. Para que as áreas mais importantes sejam testadas primeiramente e o esforço de teste seja mais efetivo e eficiente, é preciso priorizar as condições de teste.
Essa definição de prioridades normalmente envolve a determinação do impacto e da probabilidade de um risco de qualidade (Conceito aplicado em estratégia baseada em risco – que fica pra outro post).
Durante o processo, as condições de teste e o risco associado a elas pode mudar conforme as necessidades (ou entendimento das necessidades) do projeto. Essas atividades de priorização e re-priorização ocorrem durante todo o ciclo, da análise e projeto, à implementação e execução, e influencia na avaliação dos critérios de saída e report de resultados.
Objetivos de testes funcionais
Objetivos de teste funcionais podem ser aplicados durante todo o ciclo, em qualquer nível de teste. É importante testar os principais objetivos de teste primeiro para não se deparar com falhas muito graves ao final da execução.
No livro há um exemplo de um vídeo game e a funcionalidade de salvar e resumir o jogo. Um exemplo que eu gosto de usar é o de um telefone celular. Qualquer aplicação para celular deve ser capaz de tratar uma ligação. Ele deve ser interrompido para que o usuário receba a ligação e deve continuar após o término da ligação. Receber uma ligação é a funcionalidade principal do telefone (mesmo que hoje em dia eles praticamente cozinhem pra você), e quem está ligando não pode receber uma mensagem de indisponibilidade porque você está consultando sua agenda, ou porque está jogando, ou usando a calculadora. Esse é um teste que deve estar nos testes unitários, de integração, de sistema e de aceitação. Todos dando uma especial atenção a esse objetivo de teste. Lembrando que o teste começa ainda antes, na revisão de requisitos, de projeto e de código.
Posteriormente no livro é detalhada a estratégia baseada em riscos. Se você não está usando essa estratégia, você necessitará selecionar as entradas e técnicas de acordo com a estratégia utilizada, que claro, deve estar alinhada com o plano de teste, com as políticas de teste, etc.
Há duas escolhas importantes no processo de identificar e documentar as condições de teste:
- O nível de detalhamento das condições de teste na documentação
- A estrutura da documentação para as condições de teste
Há várias maneiras de se estruturar as condições de testes. Uma delas pode ser um paralelismo com a documentação base. Por exemplo, se a sua empresa trabalha com requisitos de marketing e especificações de requisitos, entende-se usualmente que o primeiro é uma descrição alto nível e o segundo, baixo nível. Assim, com base nesses documentos, você pode criar uma estrutura de condições de teste alto nível e uma em baixo nível equivalentemente.
Outra abordagem envolve a análise dos riscos de qualidade, identificando esses riscos para cada funcionalidade e assim temos as condições de teste.
O importante é que o nível de detalhamento deve estar alinhado com a estratégia de testes, que deve estar alinhada com o plano, que está alinhado com as políticas,...
Aproveite para criar a rastreabilidade nesse momento. É sempre mais fácil do que tentar criá-la numa abordagem bottom-up.
Tendo as condições de teste documentadas, o próximo passo é, normalmente, escrever os casos de teste. Há estratégias reativas discutidas no syllabus Foundation que nem sempre têm casos de teste documentados. Esses testes serão escritos utilizando técnicas que serão abordadas posteriormente.
Para os casos de teste, também deverá ser selecionado um nível e uma estrutura que deve ter todo o alinhamento já mencionado acima.
O processo de design depende agora das técnicas selecionadas para o projeto do caso de teste, mas em linhas gerais pode-se dizer que ele contém:
- Pré-condições
- Requisitos de ambiente
- Entradas de teste e outros requisitos de dados para o teste
- Resultados esperados
- Pós-condições
Definir os resultados esperados pode não ser tão trivial, especialmente considerando que esses resultados nem sempre são saídas na tela, mas condições de dados ou de ambiente. Para acuracidade dessa definição usamos o oráculo de teste.
Oráculo de teste
É a fonte que usamos para determinar o resultado esperado de um teste. Podem ser requisitos, um manual, um especialista,... Só não pode ser o código, ou a validade do teste estará comprometida. Seria o mesmo que testar o compilador.
Agora se você está achando que esse oráculo é uma especificação detalhada de testes, para a qual os resultados podem ser perfeitamente mapeáveis, isso é quase uma utopia. Normalmente essas fontes são superficiais, vagas, ambíguas e no caso de mais uma fonte, às vezes contraditórias. É preciso acrescer a elas experiência e um pouco de pessimismo profissional. Isso não acontece apenas no nível de sistema, mas em todos os outros níveis de teste.
Quem nunca teve a experiência de brincar de ping-pong com um bug? Vai pro teste, vai pro dev, vai pro teste, vai pro dev,... Isso decorre muitas vezes da ausência de um oráculo estável e confiável.
Padrões
Especificação de design de teste da IEEE 829:
Nele é descrita uma coleção de casos de teste e as condições de teste que ele cobre num alto nível. Inclui as seguintes seções:
- Identificador da especificação de teste
- Funcionalidades que serão testadas
- Refinamento de abordagem (técnicas específicas, ferramentas, etc)
- Identificação do teste
- Critério de validação (como determinar se a funcionalidade passou ou não no teste)
Essa coleção de testes descrita na especificação de design é também chamada de suíte de teste.
Especificação de casos de teste IEEE 829:
Detalha o caso de teste. Inclui as seguintes seções:
- Identificador da especificação de teste
- Itens de teste (o que vai ser entregue e testado)
- Especificações de entrada (arquivos, entradas do usuário, etc)
- Especificações de saída (resultados esperados, telas, arquivos, etc)
- Requisitos de ambiente (software, hardware, pessoal, etc)
- Requisitos procedurais especiais (permissões, intervenção do operador, etc)
- Dependência entre casos (se necessário para definir as pré-condições)
Casos de teste variam em esforço, duração, número de condições cobertas e podem ser escritos de maneiras diferentes.
ISO 9126:
Esse padrão determina seis características de qualidade de software: funcionalidade, confiabilidade, usabilidade, eficiência, manutenabilidade e portabilidade. Cada característica tem 3 ou mais sub-características. Vide figura abaixo.
O foco da certificação é na funcionalidade, os demais são considerados testes não funcionais, mas alguma dessas características pode sim vir a intervir no teste funcional.
Testes estáticos
São as inspeções, revisões. Todos conhecem a clássica curva de custo de detecção de um defeito ao longo das fases do projeto, certo? Tem um post do Fernando Palma sobre o assunto com uma figurinha do custo da não qualidade.
Fazer a análise e o projeto de teste em cima de uma especificação pode ser a própria revisão.
Métricas
Nessa parte do processo é possível medir:
- percentual de requisitos cobertos pelas condições de teste
- percentual de condições de teste cobertas pelos casos de teste
- número de defeitos encontrados na fase de análise e projeto de teste
Próximo post CTAL-related será sobre Implementação e Execução, continuando o fluxo do processo de teste.
Glossário de termos usados
**
O processo de teste consiste em:
-- Planejar e Acompanhar
-- Analisar e Projetar
-- Implementar e Executar
-- Avaliar critérios de saída e reportar resultados do teste
-- Atividades de fechamento de teste
O foco do livro é dado nas 3 atividades do meio.
Análise e Projeto de Teste
Nas atividades de planejamento, o líder de teste e o gerente de teste trabalham junto aos stakeholders na definição dos objetivos de teste. No template IEEE 829, essa informação fica documentada em “Features to be tested”.
Um pouco mais sobre documentação e norma IEEE 829 em:
- Sem Bugs – Como documentar seus testes
- ANSI/IEEE 829-1983 IEEE Standard for Software Test Documentation –Description
A partir dos objetivos de teste, na fase de análise e projeto, são desenvolvidas as atividades de:
-- Identificar e refinar as condições de teste para cada objetivo de teste
-- Criar casos de teste que exercitem as condições de teste identificadas
Saber o que testar, ainda não é suficiente. É preciso saber em que ordem e o quanto. Para que as áreas mais importantes sejam testadas primeiramente e o esforço de teste seja mais efetivo e eficiente, é preciso priorizar as condições de teste.
Essa definição de prioridades normalmente envolve a determinação do impacto e da probabilidade de um risco de qualidade (Conceito aplicado em estratégia baseada em risco – que fica pra outro post).
Durante o processo, as condições de teste e o risco associado a elas pode mudar conforme as necessidades (ou entendimento das necessidades) do projeto. Essas atividades de priorização e re-priorização ocorrem durante todo o ciclo, da análise e projeto, à implementação e execução, e influencia na avaliação dos critérios de saída e report de resultados.
Objetivos de testes funcionais
Objetivos de teste funcionais podem ser aplicados durante todo o ciclo, em qualquer nível de teste. É importante testar os principais objetivos de teste primeiro para não se deparar com falhas muito graves ao final da execução.
No livro há um exemplo de um vídeo game e a funcionalidade de salvar e resumir o jogo. Um exemplo que eu gosto de usar é o de um telefone celular. Qualquer aplicação para celular deve ser capaz de tratar uma ligação. Ele deve ser interrompido para que o usuário receba a ligação e deve continuar após o término da ligação. Receber uma ligação é a funcionalidade principal do telefone (mesmo que hoje em dia eles praticamente cozinhem pra você), e quem está ligando não pode receber uma mensagem de indisponibilidade porque você está consultando sua agenda, ou porque está jogando, ou usando a calculadora. Esse é um teste que deve estar nos testes unitários, de integração, de sistema e de aceitação. Todos dando uma especial atenção a esse objetivo de teste. Lembrando que o teste começa ainda antes, na revisão de requisitos, de projeto e de código.
Posteriormente no livro é detalhada a estratégia baseada em riscos. Se você não está usando essa estratégia, você necessitará selecionar as entradas e técnicas de acordo com a estratégia utilizada, que claro, deve estar alinhada com o plano de teste, com as políticas de teste, etc.
Há duas escolhas importantes no processo de identificar e documentar as condições de teste:
- O nível de detalhamento das condições de teste na documentação
- A estrutura da documentação para as condições de teste
Há várias maneiras de se estruturar as condições de testes. Uma delas pode ser um paralelismo com a documentação base. Por exemplo, se a sua empresa trabalha com requisitos de marketing e especificações de requisitos, entende-se usualmente que o primeiro é uma descrição alto nível e o segundo, baixo nível. Assim, com base nesses documentos, você pode criar uma estrutura de condições de teste alto nível e uma em baixo nível equivalentemente.
Outra abordagem envolve a análise dos riscos de qualidade, identificando esses riscos para cada funcionalidade e assim temos as condições de teste.
O importante é que o nível de detalhamento deve estar alinhado com a estratégia de testes, que deve estar alinhada com o plano, que está alinhado com as políticas,...
Aproveite para criar a rastreabilidade nesse momento. É sempre mais fácil do que tentar criá-la numa abordagem bottom-up.
Tendo as condições de teste documentadas, o próximo passo é, normalmente, escrever os casos de teste. Há estratégias reativas discutidas no syllabus Foundation que nem sempre têm casos de teste documentados. Esses testes serão escritos utilizando técnicas que serão abordadas posteriormente.
Para os casos de teste, também deverá ser selecionado um nível e uma estrutura que deve ter todo o alinhamento já mencionado acima.
O processo de design depende agora das técnicas selecionadas para o projeto do caso de teste, mas em linhas gerais pode-se dizer que ele contém:
- Pré-condições
- Requisitos de ambiente
- Entradas de teste e outros requisitos de dados para o teste
- Resultados esperados
- Pós-condições
Definir os resultados esperados pode não ser tão trivial, especialmente considerando que esses resultados nem sempre são saídas na tela, mas condições de dados ou de ambiente. Para acuracidade dessa definição usamos o oráculo de teste.
Oráculo de teste
É a fonte que usamos para determinar o resultado esperado de um teste. Podem ser requisitos, um manual, um especialista,... Só não pode ser o código, ou a validade do teste estará comprometida. Seria o mesmo que testar o compilador.
Agora se você está achando que esse oráculo é uma especificação detalhada de testes, para a qual os resultados podem ser perfeitamente mapeáveis, isso é quase uma utopia. Normalmente essas fontes são superficiais, vagas, ambíguas e no caso de mais uma fonte, às vezes contraditórias. É preciso acrescer a elas experiência e um pouco de pessimismo profissional. Isso não acontece apenas no nível de sistema, mas em todos os outros níveis de teste.
Quem nunca teve a experiência de brincar de ping-pong com um bug? Vai pro teste, vai pro dev, vai pro teste, vai pro dev,... Isso decorre muitas vezes da ausência de um oráculo estável e confiável.
Padrões
Especificação de design de teste da IEEE 829:
Nele é descrita uma coleção de casos de teste e as condições de teste que ele cobre num alto nível. Inclui as seguintes seções:
- Identificador da especificação de teste
- Funcionalidades que serão testadas
- Refinamento de abordagem (técnicas específicas, ferramentas, etc)
- Identificação do teste
- Critério de validação (como determinar se a funcionalidade passou ou não no teste)
Essa coleção de testes descrita na especificação de design é também chamada de suíte de teste.
Especificação de casos de teste IEEE 829:
Detalha o caso de teste. Inclui as seguintes seções:
- Identificador da especificação de teste
- Itens de teste (o que vai ser entregue e testado)
- Especificações de entrada (arquivos, entradas do usuário, etc)
- Especificações de saída (resultados esperados, telas, arquivos, etc)
- Requisitos de ambiente (software, hardware, pessoal, etc)
- Requisitos procedurais especiais (permissões, intervenção do operador, etc)
- Dependência entre casos (se necessário para definir as pré-condições)
Casos de teste variam em esforço, duração, número de condições cobertas e podem ser escritos de maneiras diferentes.
ISO 9126:
Esse padrão determina seis características de qualidade de software: funcionalidade, confiabilidade, usabilidade, eficiência, manutenabilidade e portabilidade. Cada característica tem 3 ou mais sub-características. Vide figura abaixo.
O foco da certificação é na funcionalidade, os demais são considerados testes não funcionais, mas alguma dessas características pode sim vir a intervir no teste funcional.
Testes estáticos
São as inspeções, revisões. Todos conhecem a clássica curva de custo de detecção de um defeito ao longo das fases do projeto, certo? Tem um post do Fernando Palma sobre o assunto com uma figurinha do custo da não qualidade.
Fazer a análise e o projeto de teste em cima de uma especificação pode ser a própria revisão.
Métricas
Nessa parte do processo é possível medir:
- percentual de requisitos cobertos pelas condições de teste
- percentual de condições de teste cobertas pelos casos de teste
- número de defeitos encontrados na fase de análise e projeto de teste
Próximo post CTAL-related será sobre Implementação e Execução, continuando o fluxo do processo de teste.
Glossário de termos usados
sábado, 4 de julho de 2009
Off Topic: Horizontes
O assunto não é tão off topic assim, mas como não é exatamente relacionado a testes e qualidade, preferi colocar dessa maneira.
O post é sobre o evento Horizontes: Empreendedorismo e Networking em TIC para Novos Profissionais que ocorreu ontem no auditório da Faculdade de Informática da PUC-RS.
Foi bastante produtivo o evento para conhecer pessoas, fazer contatos, aprender um pouco mais sobre a importância do networking, como fazer networking e sobre o papel de CIO nas empresas.
O evento começou com uma apresentação dos ‘hosts’: Eduardo Arruda, CIO TJ-RS e Presidente da SUCESU-RS; Newton Braga Rosa, Secretário de Inovação de Tecnologia de Porto Alegre; e Avelino Francisco Zorzo, Diretor da FACIN/PUC e Diretor Adjunto de Treinamento e Ensino da SUCESU-RS.
Houve então um painel com o Eduardo Arruda, Newton Braga, Ricardo De Rose (CIO da EPCOS e Vice Presidente da SUCESU-RS) e Guilherme Lessa (CIO do Banco Matone e Presidente do GUCIO-RS).
Ao que interessa:
Newton Braga falou sobre a importância do empreendedorismo, o que é ser um empreendedor, tirando o estigma de que necessariamente um empreendedor é um empresário. Citou uma frase que disse o diretor da SAP ao falar sobre os profissionais que contrataria para o centro que está sendo desenvolvido na TECNOPUC, em que o mesmo afirma que a SAP deseja contratar profissionais auto-motivados e que assumam riscos (controlados). E o que é isso senão um empreendedor?
Falou então da importância de se assumir riscos no seu trabalho, e fez uma colocação bem famosa:
Há dois tipos de funcionários que destroem uma empresa:
- aqueles que não fazem o que lhes é mandado (óbvio..)
- aqueles que fazem apenas o que lhes é mandado (e esses são mais perigosos que os primeiros)
Em seguida, explanou sobre networking e sua importância citando fatos como, por exemplo, que a recolocação no mercado se dá em sua maioria através de networking e não anúncio em jornais e afins.
O ápice da palestra foi uma dinâmica bastante pertinente. Temos o vício de ao chegar a um local qualquer, um evento, uma festa, seja qual for o lugar, e procurar pessoas conhecidas, nos aproximarmos e ficarmos ao lado delas durante o evento. Isso não é networking.
Fomos convidados então a nos organizarmos nas fileiras do auditório de acordo com a data de nascimento de cada um, sendo a primeira fileira ocupada pelos aniversariantes de janeiro, em ordem, a segunda pelos de fevereiro e assim subseqüentemente. Percebemos ainda que apesar de a comunidade de informática ser tão unida e não terem tantos profissionais assim, a grande maioria acabou por ficar ao lado de pessoas que não conhecíamos. Fomos então convidados a nos apresentar e trocar cartões
Hein?!? Trocar cartões? Como assim?
Pergunta: Como você vai para um evento em que espera fazer networking e não tem um cartão de visita? Vários cometeram essa gafe (e eu estou no meio :$). Fica aqui uma dica a todos: se não tem um cartão, faça um agora!!! No próximo evento, mantenha-o próximo e troque cartões, apresente-se, conheça pessoas, faça relacionamentos, pois é neles que se baseiam todas as oportunidades profissionais (e pessoais, pra quem anda procurando, quem sabe? :P)
Após a reviravolta no auditório, todos em lugares trocados, ao lado de ‘desconhecidos’, foi a vez de Eduardo Arruda fazer sua apresentação sobre o que é um CIO. Você sabe?
CIO – Chief Information Officer, o responsável por todas as informações de uma empresa. É uma baita responsabilidade, inclusive uma responsabilidade criminal (consultar a SOX). As empresas precisam de um CIO porque precisam de previsibilidade e é disso que trata a Governança de TI. Empresas confiáveis atraem investimentos.
O CIO deve ser um líder, o que envolve talento e competência. Nem todos têm o talento nato, mas competência é algo que se adquire. Três tópicos relacionados ao líder: inspiração, coaching e delegação.
Tentador foi o último slide, com o salário médio dos CIOs no RS:
Base: 8k
Média: 14k
Mais alto: 25k
É muito trabalho, é muita responsabilidade, e a remuneração está ai. Vale a pena? Essa pergunta foi feita, não foi respondida, e fica em aberto pra vocês pensarem também.
Após o Eduardo, o Ricardo fez uma palestra rápida incentivando a participação em grupos de usuários, eventos, fóruns, leituras de blog, etc. Na sua apresentação tinham slides bem legais dando uma idéia de como nos sentimos quando entramos na faculdade (um monte de gente, uma área toda aberta para caminharmos, e sem saber ao certo pra que lado vamos), depois uma figura de um labirinto complexo, cheio de gente representando a entrada no mercado, onde temos que nos sobressair. Precisamos pensar além, mais que o senso comum, e saber para onde vamos. Em seguida falou sobre a importância do networking nessa caminhada e sobre a necessidade de constante inovação no nosso dia a dia.
Finalizando os painéis, Guilherme Lessa trouxe um slide muito legal:
Há 10 tipos de profissionais
- Aqueles que entendem números binários
- Aqueles que não entendem
Uma abordagem muito legal de valorização do nosso trabalho. Lembram que em outro post falei que somos realizadores de sonhos? Ele tocou nesse mesmo assunto. Fazemos mágica!!! Imagina nosso primeiro antepassado que viu um fax funcionando. Como assim, entra uma folha em branco e depois ela sai escrita?!? E o telefone móvel, e o iphone que revolucionou o próprio telefone? E tantas outras invenções... Somos mágicos! Nós somos a força motriz que está mudando o mundo.
Bom, como eu adoro o que eu faço, eu compro logo essas idéias de que o meu trabalho é o máximo! :)
Lessa então apresentou o GUCIO, um grupo de 40 amigos CIOs que trocam experiências mensalmente dividindo seus sucessos, seus fracassos, aprendendo uns com os outros, que é o sentido de um Grupo de Usuários (GU).
Depois dessas apresentações teve um coquetel, excelente oportunidade pra colocar em prática o que aprendemos sobre networking. Valeu muito a pena o evento e sugiro que quem recebeu o convite mas não foi, da próxima vez não deixe passar essa oportunidade, pois foi bastante enriquecedor.
As apresentações estarão em breve no site da SUCESU-RS.
O post é sobre o evento Horizontes: Empreendedorismo e Networking em TIC para Novos Profissionais que ocorreu ontem no auditório da Faculdade de Informática da PUC-RS.
Foi bastante produtivo o evento para conhecer pessoas, fazer contatos, aprender um pouco mais sobre a importância do networking, como fazer networking e sobre o papel de CIO nas empresas.
O evento começou com uma apresentação dos ‘hosts’: Eduardo Arruda, CIO TJ-RS e Presidente da SUCESU-RS; Newton Braga Rosa, Secretário de Inovação de Tecnologia de Porto Alegre; e Avelino Francisco Zorzo, Diretor da FACIN/PUC e Diretor Adjunto de Treinamento e Ensino da SUCESU-RS.
Houve então um painel com o Eduardo Arruda, Newton Braga, Ricardo De Rose (CIO da EPCOS e Vice Presidente da SUCESU-RS) e Guilherme Lessa (CIO do Banco Matone e Presidente do GUCIO-RS).
Ao que interessa:
Newton Braga falou sobre a importância do empreendedorismo, o que é ser um empreendedor, tirando o estigma de que necessariamente um empreendedor é um empresário. Citou uma frase que disse o diretor da SAP ao falar sobre os profissionais que contrataria para o centro que está sendo desenvolvido na TECNOPUC, em que o mesmo afirma que a SAP deseja contratar profissionais auto-motivados e que assumam riscos (controlados). E o que é isso senão um empreendedor?
Falou então da importância de se assumir riscos no seu trabalho, e fez uma colocação bem famosa:
Há dois tipos de funcionários que destroem uma empresa:
- aqueles que não fazem o que lhes é mandado (óbvio..)
- aqueles que fazem apenas o que lhes é mandado (e esses são mais perigosos que os primeiros)
Em seguida, explanou sobre networking e sua importância citando fatos como, por exemplo, que a recolocação no mercado se dá em sua maioria através de networking e não anúncio em jornais e afins.
O ápice da palestra foi uma dinâmica bastante pertinente. Temos o vício de ao chegar a um local qualquer, um evento, uma festa, seja qual for o lugar, e procurar pessoas conhecidas, nos aproximarmos e ficarmos ao lado delas durante o evento. Isso não é networking.
Fomos convidados então a nos organizarmos nas fileiras do auditório de acordo com a data de nascimento de cada um, sendo a primeira fileira ocupada pelos aniversariantes de janeiro, em ordem, a segunda pelos de fevereiro e assim subseqüentemente. Percebemos ainda que apesar de a comunidade de informática ser tão unida e não terem tantos profissionais assim, a grande maioria acabou por ficar ao lado de pessoas que não conhecíamos. Fomos então convidados a nos apresentar e trocar cartões
Hein?!? Trocar cartões? Como assim?
Pergunta: Como você vai para um evento em que espera fazer networking e não tem um cartão de visita? Vários cometeram essa gafe (e eu estou no meio :$). Fica aqui uma dica a todos: se não tem um cartão, faça um agora!!! No próximo evento, mantenha-o próximo e troque cartões, apresente-se, conheça pessoas, faça relacionamentos, pois é neles que se baseiam todas as oportunidades profissionais (e pessoais, pra quem anda procurando, quem sabe? :P)
Após a reviravolta no auditório, todos em lugares trocados, ao lado de ‘desconhecidos’, foi a vez de Eduardo Arruda fazer sua apresentação sobre o que é um CIO. Você sabe?
CIO – Chief Information Officer, o responsável por todas as informações de uma empresa. É uma baita responsabilidade, inclusive uma responsabilidade criminal (consultar a SOX). As empresas precisam de um CIO porque precisam de previsibilidade e é disso que trata a Governança de TI. Empresas confiáveis atraem investimentos.
O CIO deve ser um líder, o que envolve talento e competência. Nem todos têm o talento nato, mas competência é algo que se adquire. Três tópicos relacionados ao líder: inspiração, coaching e delegação.
Tentador foi o último slide, com o salário médio dos CIOs no RS:
Base: 8k
Média: 14k
Mais alto: 25k
É muito trabalho, é muita responsabilidade, e a remuneração está ai. Vale a pena? Essa pergunta foi feita, não foi respondida, e fica em aberto pra vocês pensarem também.
Após o Eduardo, o Ricardo fez uma palestra rápida incentivando a participação em grupos de usuários, eventos, fóruns, leituras de blog, etc. Na sua apresentação tinham slides bem legais dando uma idéia de como nos sentimos quando entramos na faculdade (um monte de gente, uma área toda aberta para caminharmos, e sem saber ao certo pra que lado vamos), depois uma figura de um labirinto complexo, cheio de gente representando a entrada no mercado, onde temos que nos sobressair. Precisamos pensar além, mais que o senso comum, e saber para onde vamos. Em seguida falou sobre a importância do networking nessa caminhada e sobre a necessidade de constante inovação no nosso dia a dia.
Finalizando os painéis, Guilherme Lessa trouxe um slide muito legal:
Há 10 tipos de profissionais
- Aqueles que entendem números binários
- Aqueles que não entendem
Uma abordagem muito legal de valorização do nosso trabalho. Lembram que em outro post falei que somos realizadores de sonhos? Ele tocou nesse mesmo assunto. Fazemos mágica!!! Imagina nosso primeiro antepassado que viu um fax funcionando. Como assim, entra uma folha em branco e depois ela sai escrita?!? E o telefone móvel, e o iphone que revolucionou o próprio telefone? E tantas outras invenções... Somos mágicos! Nós somos a força motriz que está mudando o mundo.
Bom, como eu adoro o que eu faço, eu compro logo essas idéias de que o meu trabalho é o máximo! :)
Lessa então apresentou o GUCIO, um grupo de 40 amigos CIOs que trocam experiências mensalmente dividindo seus sucessos, seus fracassos, aprendendo uns com os outros, que é o sentido de um Grupo de Usuários (GU).
Depois dessas apresentações teve um coquetel, excelente oportunidade pra colocar em prática o que aprendemos sobre networking. Valeu muito a pena o evento e sugiro que quem recebeu o convite mas não foi, da próxima vez não deixe passar essa oportunidade, pois foi bastante enriquecedor.
As apresentações estarão em breve no site da SUCESU-RS.
Assinar:
Postagens (Atom)