TestExpert A sua comunidade de teste e qualidade de software

TEX> O seu livro "Garantia da Qualidade de Software" é uma das maiores referências no Brasil na área de qualidade e teste de software. Na sua opinião, quais são as principais mudanças no panorama nacional em relação à qualidade e teste de software nos últimos anos?

Bartié> São muitos os fatores que estão influenciando as organizações a apostarem cada vez mais em modelos de gestão TI e que entendam as disciplinas de testes e qualidade de software como altamente estratégicas para o sucesso e bom desempenho da empresa como um todo - o Brasil apenas acompanha uma tendência mundial. Com o aumento da dependência tecnológica, a TI ganha importância estratégica, podendo criar diferenciais que podem colocar uma empresa em vantagem competitiva no mercado.

Os projetos de software ampliaram sua dimensão e importância nas organizações, pois agora integram não apenas as áreas internas, mas toda sua cadeia produtiva, envolvendo um grande número de empresas. Os sistemas ampliaram suas plataformas e deixaram de ser executados apenas no ambiente interno e controlado da organização, mas estão presentes nas casas, escolas, lojas, celulares - tudo graças à internet e às tecnologias móveis.

A tendência do aumento da complexidade dos projetos de TI, combinada com a crescente pressão por prazos menores e entregas mais rápidas levam inevitavelmente às organizações adotarem uma estratégia baseada em processos. Apenas contar com o talento humano para conduzir os projetos já não condiz com o nível de investimentos e riscos tolerados em uma operação bem sucedida. Portanto, investir num processo que direcione os profissionais é a estratégia que está sendo adotado por todos os setores da economia.

Os investimentos de testes de software serão cada vez maiores ao passar dos anos, e a proporção entre testadores e desenvolvedores tende a se equilibrar ainda mais. A experiência demonstra que os profissionais de testes podem garantir a estabilidade do produto e aumentar a produtividade da equipe de desenvolvimento, desde que suas ações ocorram em paralelo e em total sinergia. A meta de desenvolvedores e testadores não deve focar na redução da taxa de defeitos, mas na redução acentuada da duração do ciclo do desenvolvimento.

Já a disciplina de qualidade de software tem um caminho muito mais longo a percorrer dentro das organizações. As empresas, à medida que institucionalizam seus processos, devem possuir uma equipe de auditores para validar se os projetos estão sendo conduzidos de acordo com os procedimentos estabelecidos, identificando as quebras de processo e os motivos pelas "não-conformidades" detectadas. Movimentos de adoção ao CMM-I e MPS.br indicam que será uma área que também receberá grandes investimentos no futuro.

O mais importante é perceber que os executivos de TI já demonstram a preocupação em manter investimentos permanentes e crescentes em equipes de testes e qualidade de software, possibilitando que estas ações sejam institucionalizadas dentro da organização. Trata-se de uma tendência irreversível.

TEX> Uma pesquisa realizada por um website britânico identifica as 20 habilidades/conhecimentos mais procurados pelas empresas que contratam profissionais da área de teste de software. Dentre essas habilidades, a certificação de testes ISEB (Information Systems Examinations Board) está em primeiro lugar. Qual a sua opinião sobre esta supervalorização das certificações na área de teste de software?

Bartié> Esta pesquisa demonstra claramente como as empresas estão tratando os testes de software com muito mais seriedade do que no passado, de forma a preocupar-se muito mais com o nível de conhecimento deste profissional, antes de colocá-lo diante de suas atribuições, o que demonstra um efetivo profissionalismo e regulamentação na área de testes de software.

Porém, tenho que concordar que as certificações são muitas vezes mal compreendidas pelos profissionais e empresas, sendo empregadas de forma inadequada pelo mercado. Vejo que alguns profissionais confundem a certificação como um "título de honra ou especialização", quando na verdade trata-se apenas de um instrumento de avaliação do conhecimento teórico de uma determinada área de conhecimento humano.

No passado, era muito comum as empresas aplicarem testes técnicos para avaliar o grau de conhecimento de um determinado profissional. Como o mercado está em constante evolução, foram criadas rapidamente novas carreiras e especializações, tornando o antigo procedimento de avaliação inviável para as empresas. Desta forma, o mercado adotou um novo instrumento para atestar o conhecimento de seus profissionais- as certificações.

A exigência por uma certificação reduz o número de candidatos a uma determinada vaga e garante que os profissionais que participarão do processo de seleção realmente estão comprometidos com sua carreira. Indica que investiram tempo e energia no aperfeiçoamento de seus conhecimentos e possuem as "condições mínimas" para desempenhar suas atribuições. O profissional é realmente avaliado após a fase de recrutamento, onde habilidade, experiência e potenciais serão levantados pelos seus recrutadores.

Outro ponto que devemos deixar muito claro, é que as certificações não são equivalentes e tampouco substituem à experiência prática, o que equivale a dizer que um profissional certificado, à princípio, não é melhor do que o profissional não certificado. A certificação apenas atesta uma base mínima de conhecimentos de um determinado profissional, ou seja, ela não garante que o profissional terá um bom desempenho.

As certificações não podem ser comparadas nem substituídas pelo tradicional ensino acadêmico (bacharelado, pós-graduação, mestrado e doutorado), pois a experiência acadêmica possibilita aos profissionais terem contato com as mais variadas disciplinas, trocar experiências com professores e colegas, além de proporcionar o confronto dos pensamentos teóricos com a realidade interna das empresas. Toda esta experiência potencializa o conhecimento do profissional, tornando sua base de conhecimento mais sólida e diversificada, possibilitando que suas decisões e estratégias estejam amparadas por uma ampla gama de conhecimentos.

TEX> Fábrica de testes e automação de testes são a bola da vez na área de teste de software da atualidade. Qual a sua opinião sobre o real retorno que tais iniciativas podem trazer para uma empresa que deseja melhorar a qualidade do seu software?

Bartié> Acredito que a área de TI está trilhando os mesmos caminhos que a indústria percorreu nas últimas 5 décadas, combinando os dois elementos vitais que potencializam a produtividade de qualquer organização: foco na padronização e automação dos processos. Qualquer estratégia que não combine estes dois elementos restringirão os benefícios dos investimentos no médio e longo prazo.

Muitos profissionais acreditam que os conceitos industriais não se aplicam às organizações de TI, pois acreditam que os paradigmas do desenvolvimento de software são muito distintos, a começar pelo simples fato de que cada projeto tem suas próprias características, impossibilitando trabalhar com padrões formais nos projetos. Algumas empresas chegam até a utilizar o termo "Ateliê de Software" como uma analogia direta a este pensamento, demonstrando a crença na incompatibilidade dos modelos.

Na verdade, os modelos industriais (produção de carros, aviões e navios) são copiados nos mais variados setores econômicos, seja nos setores da agricultura e pecuária (produção de soja, milho e gado), biomedicina (procedimentos cirúrgicos, exames e diagnósticos) ou mesmo na construção civil (construção de casas, aptos, pontes, túneis). A produtividade e precisão destes setores vêm aumentando consideravelmente ao longo dos anos, exatamente por investirem na padronização e automação de seus processos. Da mesma forma que projetos de TI tem suas particularidades, estes setores também possuem projetos individualizados, mas não deixam de ter um processo altamente padronizado, ágil e controlado.

A padronização garante a institucionalização do conhecimento, formalizado e perpetuado através de processos, possibilitando que profissionais com menos experiência compartilhem o conhecimento e aprendizado dos projetos passados. Isto significa que a padronização não é estática, mas sim evolutiva, adaptando-se às mudanças tecnológicas e aos aperfeiçoamentos gerados pela própria experiência da organização.

A automação de processos é empregada para acelerar o processo de execução, análise e diagnóstico de determinadas atividades, possibilitando que um grande volume de informações e tomada de decisões sejam executadas sem que seja necessário a intervenção humana. A utilização de ferramentas que compartilham informações entre áreas ou que permitem integrar ações de planejamento, acompanhamento e execução também são consideradas automações de processos.

Infelizmente, a falta de cultura da padronização da TI tem levado as empresas investirem apenas na automação de processos, ignorando totalmente a questão da padronização dos projetos. Isto equivale a dizer que muitas empresas estão construindo verdadeiros "Ateliês de Testes Automatizados", sem perceber os efeitos que esta falta de padrões pode provocar no médio e longo prazo.

Quando um projeto de automação de testes é iniciado, devemos encará-lo como um investimento de longo-prazo, pois esta solução deverá acompanhar o ciclo de vida de todo o sistema. Como todos os sistemas deverão ter seus próprios projetos de automação de testes, devemos visualizar um conjunto de soluções automatizadas com a finalidade de validar cada sistema existente.

Sem padronização, cada projeto de automação passa a ser considerada uma solução independente, sem compartilhar nenhum tipo de arquitetura comum. Qualquer aperfeiçoamento que seja necessário realizar nesta automação (controlar evidências, massa de testes, baselines, métricas), deverá impactar individualmente cada projeto, tornando inviável a modificação das automações no longo prazo.

Muitas empresas entendem que a padronização dos projetos são obtidas através da restrição de ferramentas de um único fornecedor (IBM-Rational, HP-Mercury, Borland-Segue, Compuware, AutomatedQA, ou mesmo uma solução Open-Source). Se isto fosse verdade, empresas distintas que utilizam as mesmas ferramentas teriam formas de implementação muito semelhantes, o que está longe de ser uma verdade.

O fato é que as ferramentas foram construídas para serem programadas e não parametrizadas com informações de negócios. Cada organização deverá investir muito tempo e energia para customizar as ferramentas de acordo com suas necessidades e monitorar cada profissional na forma de sua utilização. Pessoas com muita experiência em projetos sabem como os profissionais encontram jeitos diferentes para fazerem as mesmas coisas, o que leva inevitavelmente à despadronização das automações.

Portanto, a única forma de termos efetivamente uma Fábrica de Testes é definindo uma Arquitetura de Testes Unificada, que possibilita uniformizar o gerenciamento dos testes manuais e automatizados, compartilhando componentes que podem ser integrados e reutilizados em várias automatizações, independente da tecnologia que você está adotando hoje ou no futuro.

A criação de uma Arquitetura de Testes Unificada é uma solução muito empregada na indústria, especialmente a automobilística, que possibilita criar carros diferentes numa única plataforma. Isto significa que as automações não serão encaradas mais como projetos isolados, mas uma estratégia corporativa para garantir a criação e evolução das automações dentro das organizações.

TEX> Você é o diretor executivo e engenheiro de software responsável pelo Framework X-Zone. O que é o X-Zone?

Bartié> Todos nós temos em mente à visão dos atletas olímpicos, que buscam continuamente superar seus limites à cada nova competição, levando sua condição física ao extremo. Atrás dos recordes quebrados, existe uma rígida disciplina de treinamentos aos quais estes são submetidos para tornarem-se campeões em sua modalidade.

A alta competitividade do esporte, pode tornar recordes em resultados comuns em poucos anos, o que exige do atleta uma contínua superação de seus limites. A meta de um campeão é manter-se numa faixa de alto desempenho onde poucos atletas conseguem alcançar - manter-se na faixa extrema de performance ("eXtreme Zone").

A filosofia X-Zone utiliza-se desta analogia para enviar uma clara mensagem às organizações e profissionais que buscam um modelo que promovam a inovação e produtividade em suas organizações. Não é possível alcançar o sucesso sem investimento, esforço e profissionais competentes. Mais difícil que alcançar uma determinada meta organizacional, é mantê-la e melhorá-la ao longo dos anos. Não existem atalhos para a "excelência organizacional".

Na busca pela inovação e melhoria contínua, várias empresas gastam muitos recursos financeiros investindo na customização e integração de ferramentas ou mesmo na construção de soluções caseiras, visando atender determinadas particularidades, sem levar em consideração os custos e restrições destas abordagens no longo prazo.

Sabemos que as pequenas e médias empresas possuem grandes restrições financeiras, comparadas às grandes corporações. Uma falha no planejamento das inovações podem comprometer todo o investimento realizado, fundamental para que a empresa ganhe competitividade no mercado em que atua.

Se somarmos todos os investimentos que cada empresa executa isoladamente para construir sua própria solução proprietária, teríamos condições de construir uma solução nacional que agregue diversas tecnologias e as compartilhe com diversas empresas, transformando essa solução num padrão de mercado. Ter o controle da evolução do produto garante que estas empresas sejam atendidas em suas necessidades, porém sem a exigência de financiar integralmente uma estrutura de profissionais para pesquisar, construir e manter esta solução.

A proposta do projeto X-Zone é exatamente direcionar estes investimentos de risco, executados anualmente por estas empresas, para financiar a criação de um Framework de Testes Brasileiro. Desta forma, as empresas teriam acesso a uma tecnologia de alto valor agregado, possibilitando que os gastos, com pesquisa e construção de soluções individualizadas, sejam diluídos com a adoção de um padrão de mercado, o que cria uma automática aceitação por parte dos Clientes, que exigem de seus fornecedores o aperfeiçoamento contínuo de seus projetos.

É fundamental salientar que o Projeto X-Zone não se restringe apenas na construção de ferramentas e processos, mas na definição de uma "Arquitetura de Testes Unificada". Englobar estes conceitos numa única abordagem reduz o esforço de integrarmos as múltiplas tecnologias existentes, gerando uma economia significativa, além de estabelecer o sonhado padrão corporativo de trabalho. Esta é a definição do Framework X-Zone - padronização dos projetos de testes sem comprometer a agilidade da equipe.

Para que o "Framework X-Zone" seja encarado como um padrão de mercado, este necessita ser adotada por um número significativo de empresas e profissionais, que não apenas acreditam na padronização dos projetos, mas entendem que isto pode ser um diferencial em suas atividades.

O projeto X-Zone será conduzido por uma empresa focada única e exclusivamente na evolução do Framework, não atuando como prestador de serviços de qualquer natureza. Desta forma, a empresa X-Zone não deve ser encarada como uma concorrente das demais empresas nacionais, apenas um fornecedor de soluções que concorrem com as multi-nacionais como IBM, HP, Borland, Compuware entre outras fornecedoras menores de ferramentas.

Para manter-se viável financeiramente, a empresa X-Zone necessitaria de uma fonte lícita de recursos financeiros, exatamente para realizar os investimentos necessários para manter a estrutura de evolução da solução e devolver este investimento em tecnologia e metodologia. Isto exigiria que os membros da Comunidade X-Zone contribuíssem com uma anuidade proporcional ao número de licenças que irá empregar.

Seguindo o modelo de que convencionamos chamar de Open-Design, todos os membros da comunidade poderiam solicitar aperfeiçoamentos e evoluções do Framework X-Zone, de forma a atender as mais variadas necessidades e tecnologias. Uma equipe de Engenheiros de Software iriam priorizar as solicitações que estão aderentes à metodologia proposta e avaliar os itens com maior custo-benefício de criação. Serão 4 versões Betas disponibilizadas anualmente e 2 versões finais liberadas no mesmo período.

Os membros da comunidade que necessitam de maior rapidez ou garantia que um determinado módulo seja implementado num determinado prazo de tempo, poderá contratar este serviço de forma apartada. Porém toda a customização será disponibilizada para todos os membros da comunidade. O projeto adicional nunca deverá trazer impactos à evolução das demais solicitações, pois teremos uma estrutura independente de profissionais para lidar com este projeto.

É fundamental compreender que o Framework X-Zone não conflita com os modelos CMM-I, MPS.Br ou ISO, tampouco impõe um determinado processo de trabalho à sua organização, pelo simples fato da arquitetura do Framework X-Zone ser orientado á informações, o que garante que no final dos projetos, além da padronização, a empresa possui um grande repositório de informações de negócios, podendo ser compartilhada e acessada por outras equipes (desenvolvedores, executivos, analistas de negócios), que nunca conseguiram organizar tanto conhecimento de forma tão simples.

O Framework X-Zone possibilita a integração com as mais variadas ferramentas de automação disponíveis no mercado, possibilitando que você possa migrar sua modelagem de testes integralmente para uma ferramenta totalmente diferente da atualmente empregada - um problema recorrente nas empresas fornecedoras de software que necessitam adequar-se às ferramentas de seus clientes.

O projeto X-Zone não está apenas restrito à solução de Testes de Software, mas possui uma arquitetura que possibilita englobar todas as demais disciplinas exigidas nas certificações CMM-I ou MPS.br. Nossa intenção é que outras disciplinas sejam implementadas ao longo dos anos, permitindo que sua empresa esteja aderente aos padrões e normatizações, facilitando o processo de certificação destas empresas.

Para finalizar, gostaria de convidar as empresas a integrarem o Programa X-Zone Beta-Testes, um grupo de 15 empresas, cujo objetivo é participar da estabilização do produto e identificar eventuais pontos de melhoria.

Para maiores informações, enviar um e-mail para cliente@x-zone.com.br ou diretamente para mim.

TEX> Você é diretor de inovação regional da ALATS (Associação Latino Americana de Teste de Software). Quais são as perspectivas de futuro da CBTS (Certificação Brasileira de Testes de Software)?

Bartié> A ALATS é a organização responsável em manter, evoluir, ampliar e padronizar os conceitos sobre Testes de Software cobertos pela certificação CBTS, estabelecendo as regras de aferição e avaliação sobre o conhecimento dos profissionais nesta área de conhecimento. É de sua responsabilidade manter-se totalmente aderente aos padrões internacionais, sem abrir mão de agregar conhecimento e conteúdo metodológico criados por empresas e profissionais brasileiros.

Presença no maior número de estados brasileiros

A ALATS possuiu total interesse em realizar exames e preparatórios em todos os estados, por entender que a CBTS é o resultado do esforço de toda a comunidade de testes brasileira, sendo que todos os profissionais e empresas devem ter a oportunidade de participar e promover esta certificação em sua região.

A ALATS, por ser uma instituição sem fins lucrativos, necessita de parcerias regionais para poder promover eventos e realizar as provas nestes estados. Portanto, somente com a colaboração da comunidade será possível cobrirmos todas as regiões do país.

Internacionalização da CBTS

A ALATS está iniciando o processo de internacionalização da CBTS, através da divulgação desta certificação entre os países latino-americanos. O primeiro passo concreto para alcançar este objeto foi a entrada do Sr. Marcelo de Los Santos como Diretor Regional - Uruguai. Temos um evento da ALATS que está sendo negociado para ocorrer entre maio e junho deste ano no Uruguai.

Esta ação possibilitará o aumento do intercâmbio de conhecimento entre os países latino-americanos, facilitando a integração entre as comunidades de testes destes países e promovendo nossas empresas de TI, potencializando a geração de negócios neste segmento específico.

Comitês de Inovação Regional permanentes

A primeira experiência que tivemos com o Comitê de Inovação ocorreu entre 2006-2007, envolvendo a colaboração de mais de 70 profissionais da área. Uma vez definida os projetos de inovação, a maior dificuldade encontrada foi montar as equipes e definir as tarefas de cada membro, consumindo mais de 50 % do tempo do projeto.

Apesar do esforço, o resultado foi extremamente positivo, gerando uma grande compilação de exercícios e a uma extensão da Base de Conhecimento de Software, chamada de Referência Complementar - CBTS. Tenho que destacar a participação de Fábio Martinho e Cristiane Machado não apenas pela coordenação das atividades, mas pelo comprometimento com o sucesso do projeto, tanto nas datas de entregas e quanto na qualidade do material disponibilizado, resultado da importante contribuição de todos os nossos importantes colaboradores.

Este esforço demonstrou a viabilidade da empregarmos a comunidade de testes para fonte de aprimoramento da CBTS. Portanto, trata-se de uma estratégia da ALATS tornar os Comitês de Inovação permanentes e ativos em cada estado onde esteja presente. Isto significa que, no longo prazo, grupos de profissionais ligados à ALATS estarão contribuindo diretamente com a CBTS, através da compilação de conteúdo e metodologias criados pelos seus integrantes, sempre respeitando as regras de direitos autorais.

Novos Níveis de Certificação da CBTS

Outro desafio de longo prazo da ALATS será a criação de níveis de certificação mais especializados. Com o crescimento da importância dos testes dentro das organizações, as equipes tendem a tornarem-se maiores e mais complexas, tendo de gerenciar um número cada vez maior de pessoas e projetos, trabalhando com prazos mais curtos e maior níveis de controles operacionais.

A necessidade de especialização dos profissionais de testes fará com que a CBTS tenha níveis de certificação mais especializados, atestando que um determinado profissional possui um maior nível de conhecimento e compreensão dentro da disciplina de testes de software.

Lembro a todos que isto é uma tendência já aplicada pelas certificações internacionais, e será natural que a CBTS acompanhe esta tendência. Este assunto também será devidamente discutido com a comunidade de testes, sendo que este movimento será realizado quando o mercado exigir este novo nível de certificação. Portanto, o gráfico apresentado é apenas para efeito de compreensão, não existindo nada de definitivo sobre este assunto.

TEX> Um tema comum nos seus últimos artigos é a disseminação de processo de teste de software formal. O que caracteriza um processo de teste de software formal?

Bartié> A formalização de um processo é muito mais do que simplesmente um "desenho" disponível na "intranet" ou um documento que contemple todas as etapas, atividades e artefatos exigidos. A formalização é um instrumento de institucionalização de uma determinada regra ou procedimento que está sendo apresentando claramente à todas as áreas da organização, oferecendo um entendimento comum sobre uma determinada disciplina, objetivando que esta possa ser replicada, seguida e respeitada por todos os profissionais da empresa.

A formalização de processos faz parte de uma estratégia corporativa de gerenciamento do conhecimento, onde os profissionais mais experientes materializam seu conhecimento e experiência, formatando modelos formais de condução de projetos. Estes profissionais são chamados de Engenheiros de Software e possuem total liberdade para modificar e adaptar a metodologia em função de determinadas situações consideradas novas e não cobertas pelo processo atual. Eles são responsáveis por toda a dinâmica do processo e responde pelas eventuais "quebras de processo" executadas por determinadas áreas e profissionais.

A formalização direciona toda a estratégia de treinamento e reciclagem de profissionais, objetivando que estes estejam aptos a lidar com as mais variadas situações. Os treinamentos devem não apenas valorizar o conhecimento teórico, mas aferir o comportamento do profissional diante de diversos cenários que possam colocá-lo à prova e demonstrar como um processo bem desenhado pode garantir uma perfeita comunicação entre as áreas e evitar imprevistos que provoquem atrasos ou falhas no projeto.

A formalização é muitas vezes confundida com burocratização, pois profissionais menos experientes não conseguem perceber a necessidade de controles dos processos e a necessidade de registros para rastrear a origem do problema ou mesmo entender o que motivou uma determinada falha. São através destes controles que podemos identificar e mensurar com precisão, quais métodos estão sendo mais efetivos na detecção e diagnóstico dos erros, se o ambiente de testes apresenta instabilidade constante prejudicando o desempenho dos testes, ou mesmo avaliando quais profissionais possuem maior produtividade, podendo estabelecer metas individuais de produção e até mecanismos de compensação financeira baseados em critérios objetivos.

A formalização dos processos de testes apresenta maiores ganhos nas seguintes situações:

• quanto mais inexperiente for a equipe;
• quanto mais complexo for o ambiente;
• quanto mais profissionais estejam envolvidos;
• quanto mais projetos simultâneos ocorrerem;
• quanto mais sua organização deseja crescer.

TEX> Com o advento da Internet percebemos um crescimento exponencial na adoção desta plataforma para a construção de aplicações comerciais. No entanto, esta nova plataforma nos leva a lidar com novos desafios sob o ponto de vista do teste de software, tais como: segurança, desempenho e usabilidade. Como você percebe a maturidade dos profissionais, metodologias e ferramentas para dar suporte a esse novo paradigma?

Bartié> A Internet, assim como as tecnologias sem-fio, estão viabilizando novas formas de interação de empresas e pessoas, possibilitando novos meios de relacionamentos e realização de negócios. A primeira reação que temos é acreditar que estas mudanças irão impactar nossos processos e exigir uma grande reestruturação, quando na verdade, é necessário apenas um realinhamento para cobrirmos adequadamente esta nova realidade.

As mudanças tecnológicas influenciam de formas diferentes processos e ferramentas. Os processos exigem pequena adequação para manter-se alinhados com os novos paradigmas tecnológicos, como aconteceu com o Main-Frame, DOS, Linux, Windows e finalmente os Browsers. Todos os sistemas são testados empregando as mesmas técnicas e procedimentos, exigindo apenas um pouco de adaptação para suportá-los. Já as ferramentas mudam radicalmente de comportamento, em função da tecnologia empregada, o que leva a necessidade de lidarmos com as novas tecnologias à medida que novos paradigmas tecnológicos são disponibilizados.

Porém, acredito que exista uma premissa errada, que está afetando muito à forma de como as empresas organizam sua equipe de testes. Pelo fato de testes serem muito abrangentes, vejo que alguns executivos esperam que seus profissionais de testes consigam responder por todos os tipos de testes possíveis. Uma vez, ouvi relatos de uma empresa que alocaram analistas de testes para criar testes unitários, pois acreditavam no conceito de "quem faz não deve testar". Na verdade, os testes unitários devem ser criados e executados pelos próprios desenvolvedores, porém os testes unitários não provam de que um determinado requisito foi implementado.

Entretanto, os testes de caixa-preta não são exclusividade da equipe de testes, podendo também ser executados por uma equipe de homologação ou até por uma equipe especializada. Cada categoria de testes pode exigir habilidades e experiências muito diferentes, o que leva inevitavelmente à descentralização dos testes.

Uma equipe de testes atua diretamente nos chamados requisitos funcionais (regras de negócio, usabilidade, navegabilidade, segurança - "restrição de acesso"). Devem trabalhar em paralelo à equipe de desenvolvimento e concentrar-se na estabilização do produto e na redução do ciclo de desenvolvimento. Portanto, possuem um foco e conhecimento menos técnico e mais voltada à negócios.

Uma equipe de homologação atua após a construção e alteração dos inúmeros sistemas envolvidos nas mudanças geradas. Enquanto as equipes de testes já validaram os requisitos funcionais, a equipes de homologação irá concentra-se nos requisitos não-funcionais. Isto requer a montagem de um ambiente similar ao de produção, para que os resultados sejam os mais próximos do real, caso contrário os testes não terão validade. Portanto, estes profissionais possuem uma visão mais superficial sobre as regras de negócios, mas possuem um total domínio sobre o ambiente tecnológico onde estes sistemas serão mantidos.

Testes de Configuração

Um dos paradigmas que o sistema Web traz, é o fato de não podemos padronizar com qual browser nosso sistema será acessado e em que sistema operacional este estará sendo executado, restringindo as formas de implementação do software. Portanto, testes de configuração serão necessários para avaliar o comportamento do software em vários contextos diferentes (browsers diferentes e sistemas operacionais diferentes) ...

- Empregando o Windows (versão X,Y,Z)
- Empregando o Linux (versão X,Y,Z)
- Empregando o Mac-OS (versão X,Y,Z)

- Empregando o IExplorer (versão X,Y,Z)
- Empregando o FireFox (versão X,Y,Z)

Testes de Segurança (Vulnerabilidade)

Em relação à segurança (vulnerabilidade dos sistemas), a maioria das empresas possui profissionais especializados neste assunto, geralmente ligados as áreas tradicionais de Suporte, Infra-Estrutura ou Segurança da Informação.

Minha recomendação é que estas áreas assumam também a responsabilidade pela segurança dos sistemas, uma vez que se trata da "expertise" destes profissionais, mesmo que exista uma equipe de homologação altamente especializada.

Estes profissionais serão facilmente capacitados a adaptarem-se às exigências, procedimentos e artefatos estabelecidos pelo processo de testes. Em relação às ferramentas, estes profissionais já possuem afinidades com ferramentas similares, exigindo pouco esforço de adaptação.

Testes de Desempenho, Carga e Concorrência

Testes de desempenho também não é uma novidade para as empresas, pois a necessidade de mensurar o tempo de resposta dos sistemas vem desde a época dos Main-Frames. É claro que múltiplos acessos podem afetar o desempenho da aplicação Web, da mesma forma que ocorre com um sistema Windows, portanto os paradigmas são muito semelhantes em todas as plataformas.

Ficará a cargo da equipe de homologação desempenhar e executar estes testes, em função de possuírem profundos conhecimentos do ambiente de homologação (montado por eles mesmos). As ferramentas também são familiares a estes profissionais, pois já são empregadas em situações similares de avaliação, seja na avaliação de acesso à Banco de Dados, consumo de recursos em Servidores, monitoração de Tráfego de Redes entre outras coisas.

Testes de Acessibilidade

Com a presença da internet em nossas casas, pessoas portadoras de deficiências podem apresentar dificuldades em operar adequadamente um sistema, impossibilitando que algumas delas tenham acesso a todos os benefícios e comodidades que estão disponibilizadas.

Como as empresas estão cada vez mais preocupadas com a inclusão destas pessoas, não apenas por representar uma parcela significativa da população, mas pela mobilização das empresas no compromisso pela "responsabilidade social", já estão sendo definidos requisitos de acessibilidade que um determinado sistema WEB deve suportar.

Com estes requisitos estabelecidos, podemos estabelecer uma forma padronizada de avaliação do nível de acessibilidade de um determinado sistema, como ocorre hoje, quando avaliamos a estrutura de um prédio, casa ou apartamento.

TEX> Como alguém formado em Administração de Empresas se voltou para a área de tecnologia da informação e tornou-se uma referência na área de testes no Brasil? Compartilhe conosco um pouco da sua trajetória profissional.

Bartié> Na verdade, tenho contato com computadores desde meus 14 anos, quando meu tio, trouxe um equipamento protótipo, chamado de TK-82-C, durante um evento nos EUA. Com o passar de 1 ano, já dominava a programação do equipamento, conseguindo reproduzir os jogos que faziam sucesso em fliperamas, como jogos de labirintos e de perseguição. Eles não tinham gráficos de alta qualidade, mas exigiam algoritmos muito sofisticados.

Carreira Acadêmica

Decidi fazer o colégio técnico para ter mais contato com as novas tecnologias que estavam sendo introduzidas no mercado. Matriculei-me no curso de Processamento de Dados na "ETE Lauro Gomes", onde tínhamos as disciplinas normais e as matérias técnicas adicionais. O curso técnico era em período integral.

Com relação à faculdade, as únicas opções existentes na época eram os cursos tradicionais (Engenharia, Matemática ou Administração) acrescidos de matérias sobre sistema de informação. Como muitos de meus colegas técnicos, decidi pelo curso de "Matemática com ênfase em Sistemas de Informação" na Fundação Santo André.

Quando ingressei no mercado de trabalho, percebi que além do prazer em trabalhar com tecnologia, tinha muito gosto por compreender a dinâmica empresarial. A experiência de participar ativamente em áreas estratégicas de empresas multinacionais mostrou-me a importância ter uma visão mais ampla sobre o funcionamento da máquina corporativa. Interrompi o curso de Matemática na metade do 2º. ano e matriculei-me na disciplina de Administração de Empresas.

Por acreditar que todos os fundamentos da administração poderiam ser aplicados integralmente nos projetos de software, resolvi investir em pós-graduações com perfis diferentes. A primeira organizada pelo Instituto Trevisan, ministrada exclusivamente por consultores de 1ª. linha, para ter uma visão pragmática dos métodos e conceitos aplicados no mercado. A outra, organizada pela USP, ministrada por profissionais mais acadêmicos, dando uma visão mais teórica sobre temas que permeiam á realidade e os desafios das organizações.

Carreira Profissional

Com 17 anos consegui meu primeiro emprego como programador Clipper, numa empresa que atuava no setor de automação-industrial. Nesta empresa, tive o primeiro contato com técnicas profissionais de programação e meu exigente gerente-técnico avaliava se todos nossos programas tinham trechos que poderiam tornar-se bibliotecas reutilizáveis.

Tenho que admitir que minha fixação por "Frameworks" vem desde esta época. Apesar deste gerente-técnico não ter definido explicitamente um modelo de desenvolvimento, sua filosofia poderia ser resumida da seguinte forma - o bom programador é aquele que escreve pouco código e resolve muitos problemas. Esta forma de pensar projetos de software passou a influenciar toda minha carreira.

Com 19 anos, resolvi trabalhar como autônomo, desenvolvendo um software de gestão para algumas pequenas industriais em Diadema. Aperfeiçoei todas minhas técnicas de programação e criei meu próprio "Framework de Desenvolvimento". No final de 2 anos, tinha um complexo projeto de gestão de negócios, onde várias áreas estavam sendo atendidas - pedidos, faturamento, boletos, estoque, custos, produção - um pequeno ERP.

Aos 21 anos, fui trabalhar numa empresa de pequeno porte (chamada na época de Software-House), que prestavam serviços para a multinacional Gessy-Lever. Fiquei responsável pelo gerenciamento e criação do sistema de faturamento e distribuição da divisão de laticínios, englobando os sites de São Paulo (Lapa e São José do Rio Preto), Rio de Janeiro (Pavuna) e Minas Gerais (Santa Rita).

Aos 23 anos, fui contratado por uma empresa nacional especializada em Bio-Engenharia, cujos principais produtos eram máquinas de hemodiálise e montagem de marca-passos. A empresa tinha como principal mercado os países europeus, sendo necessário obter o certificado ISO-9000 para garantir a qualidade da cadeia produtiva. As auditorias eram vindas da Inglaterra e os processos de avaliação eram freqüentes. Minha responsabilidade era gerenciar e construir todos os sistemas não cobertos pelo ERP adotado pela empresa, adequando-os às normas e padronizações estabelecidas pela ISO.

Aos 25 anos, trabalhava numa empresa especializada em tecnologias de marketing direto. Fiquei responsável pelo gerenciamento e construção de um Sistema de Apoio à Logística de Vendas da empresa Johnson & Johnson. O projeto equipava os mais de 150 profissionais de vendas da empresa com notebooks de última geração, com um sistema desenhado para integrar o processo de vendas diretamente à organização.

Aos 26 anos, trabalhei numa empresa especializada em sistemas de saúde. Fiquei responsável pela definição de uma "Metodologia de Desenvolvimento de Software", de modo à suportar todos as disciplinas necessárias para produzir um software com qualidade. Empregamos a metodologia SDD ('Solution Development Discipline") da Microsoft como principal referência.

Aos 28, trabalhei numa empresa especializada em testes e qualidade de software. Como consultor tive a oportunidade de liderar vários projetos de automação de testes em várias instituições financeiras - BNP, BBA, Fininvest - foram mais de 25 projetos independentes. Depois, fiquei responsável pela padronização de todos os projetos de testes (manuais e automatizados) em todas as plataformas Main-Frame, Windows e Web e nas arquiteturas Front-End, Transacionais e Batch. Fui o Engenheiro de Software responsável pela arquitetura e construção da ferramenta QA-Teste que viabilizaria a padronização dos projetos de testes desta empresa.

Aos 29 anos, ministrei cursos de pós-graduação em UML (Unified Modeling Language) na Faculdade FIAP. Esta experiência credenciou-me para elaborar todo o plano de treinamento e capacitação em Teste de Software da CEF (Caixa Econômica Federal) nos sites de São Paulo, Rio de Janeiro e Brasília, envolvendo o treinamento de mais de 100 profissionais. Este treinamento foi o embrião do livro Garantia da Qualidade de Software publicado em 2002.

Aos 31 anos, fui contratado por uma empresa nacional especializada na tecnologia de auto-atendimento (ATM) e em pagamentos eletrônicos. Integrei uma equipe de Engenheiros de Software que ficaram responsáveis em customizar o RUP (Rational Unified Process) e implementá-los na organização, cuja finalidade à longo prazo seria a certificação CMM nível 3.

Aos 32 anos, ainda na mesma empresa, fui convidado a gerenciar a área de Testes e Qualidade de Software, liderando uma equipe de 25 profissionais, onde estabelecemos um processo de testes formalizado e padronizado. Empregamos os conceitos de automação em diversos sistemas de tecnologias mais variadas (sistemas DOS, OS/2, Unix, MainFrame, Windows), com destaque a arquitetura de testes automatizados em aplicações ATM´s, algo que gerou uma redução de 80% nos prazos de homologação. Instituímos o Planejamento de Testes Integrado, onde analistas de testes de sistemas interdependentes apresentavam e refinavam seus casos de testes, incentivando a colaboração e ampliando a cobertura de testes de todos os sistemas.

Aos 34 anos, voltei a atuar como consultor independente, decidido a popularizar os conceitos de Fábrica de Testes a toda a comunidade de TI e apoiar todas as iniciativas brasileiras que visam o aprimoramento e capacitação dos profissionais nas áreas de testes e qualidade de software.

Hoje, aos 36 anos, estou trabalhando na divulgação do Framework X-Zone, cuja finalidade é fornecer uma solução que padronize as arquiteturas dos testes manuais e automatizados, possibilitando que todos os projetos sejam planejados e conduzidos da mesma forma, possibilitando que inovações sejam incorporadas facilmente sem impactar o legado de testes.

Em breve, espero poder estar integrando o Framework X-Zone com outras disciplinas da Engenharia de Software, possibilitando que sua empresa fique aderente aos padrões CMM-I sem que sejam necessários grandes investimentos em consultorias e ferramentas.

Até lá, conto com o apoio de vocês ...

TEX> Quais são os livros que você recomendaria para os profissionais que tem interesse de ingressar na área de testes de software?

Bartié> Acho que não apenas para os profissionais que estão iniciando na carreira, mas para aqueles que estão há muito tempo atuando como profissionais de TI, minha grande recomendação é entender os processos e a padronização como seus aliados e não como algo negativo que vai prejudicar o seu trabalho.

Ao longo dos anos, percebi que os profissionais com uma abordagem estritamente técnica sobre projetos de testes, apesar de excelentes profissionais, continuaram sem visibilidade dentro da organização, repetindo sua lógica de soluções, sem construir algo que seja maior que o próprio projeto em que participou. São profissionais com uma visão mais imediatista e focada única e exclusivamente no projeto que está executando.

Os profissionais que tiveram mais sucesso, e foram rapidamente lançados à cargos melhor remunerados como Diretorias e Gerencia em Testes de Software são os profissionais mais preocupados com a padronização e controle dos projetos, pois entendem as necessidades da organização. São profissionais que pensam no médio e longo prazo, e compreendem as similaridades entre os projetos e os ganhos em padronizá-los.

Portanto, segue algumas recomendações ...

- Converse com outros profissionais no mercado;
- Busque a Certificação CBTS para fundamentar os conceitos básicos;
- Não seja exclusivamente técnico, pois a tecnologia vai mudar e irá deixá-lo para trás;
- Focalize na gestão, pois somente ela sobrevive com as mudanças tecnológicas;
- Atender o curto prazo é importante, mas sempre tenha um plano para atender o médio e longo-prazo;
- Não tente inventar a roda, este tipo de criatividade não é necessária nas empresas;
- Desconfie do que é muito simples, pois a simplicidade não combina com complexidade;
- Crie modelos que possam ser compartilhados, que não dependam de você ou da "expertise" de alguém;
- Entenda as outras disciplinas, para melhor entender seu papel dentro dos projetos;
- Cuidado com as ondas de novidades, quem mergulha em todas não chega a lugar nenhum;
- Estude algo que complemente seus conhecimentos, pois ampliará sua visão de mundo;
- Sucesso não se mede em meses, mais em anos - foco no longo prazo;

Acho que recomendar livros da área pode ser redundante, pois acredito que existam várias fontes com boas indicações. Recomendo a leitura das obras nacionais, pois além de uma ampla cobertura teórica, são ótimas fontes de referência, não apenas para os profissionais que estão iniciando, mas para executivos e gestores da área.

Segue abaixo, os livros que inspiram minha visão de mundo:

- A Empresa Flexível (Alvin Tofler);
- Previsões e Premissas (Alvin Toffler);
- Os Ciclos de Vidas das Organizações (Ichak Adizes);
- A Meta (Eliyahu Goldratt);
- Mais do que sorte, um Processo de Raciocínio (Eliyahu Goldratt);
- Um Mundo sem Empregos (William Bridges);
- Visão 2020 (Stan Davis e Bill Davidson);

Sobre Alexandre Bartié:

Alexandre Bartié é Administrador de Empresas e pós-graduado em Capacitação Gerencial e em Gestão Empresarial. Há 17 anos, trabalha no gerenciamento de processos voltados à qualidade e engenharia de software atuando em grandes empresas. Diretor de Inovação da ALATS (Associação Latino-Americana de Teste de Software), Diretor-Técnico e Engenheiro responsável pelo Framework Brasileiro de Testes X-Zone (www.x-zone.com.br). É autor do livro "Garantia da Qualidade de Software".