Gestão sociotécnica do teste de software em projetos de sistemas de informação

Socio-technical management of software testing in information systems projects

Gestão sociotécnica do teste de software em projetos de sistemas de informação

Socio-technical management of software testing in information systems projects

Mauro Tosetto; Carlo Gabriel Porto Bellini

UFPB - Universidade Federal da Paraíba, Brasil

^{Endereço para correspondência}

RESUMO

Na indústria brasileira de desenvolvimento de software para sistemas de informações, observa-se sensibilidade das empresas quanto à necessária melhoria contínua na qualidade do processo produtivo. Uma das formas de tratar a qualidade do desenvolvimento de software - na expectativa de alinhar os processos de negócio do cliente às rotinas computacionalmente programadas no sistema de informações - dá-se por meio do teste de software. O teste de software busca institucionalizar práticas de gestão de projetos e desenvolvimento de produtos de software, com o objetivo de localizar os problemas - e não garantir a sua inexistência. A partir de uma perspectiva sociotécnica e dos modelos teóricos SET (gerencial) e ST-TS (processual) desenvolvidos nesta pesquisa para um melhor entendimento e orientação das atividades de teste, entrevistas em profundidade com dez especialistas em qualidade e teste de software permitiram a identificação e validação de categorias analíticas que mediam a relação entre fatores desses dois modelos, disto derivando-se o modelo organizacional VAST para auxiliar gestores, desenvolvedores e clientes em projetos de software para sistemas de informações empresariais.

Palavras-chave: desenvolvimento de sistemas de informação, teste de software, abordagem sociotécnica, qualidade de processo, gestão de projetos

ABSTRACT

Brazilian companies that develop software for information systems are aware of the pressing need for continuous improvement in process quality. Towards aligning business processes with software routines implemented in an information system, one should address the institutional practices of software testing. From a socio-technical perspective and with the help of two theoretical models developed in this study to outline and guide the testing activities from a managerial and process-based perspective, in-depth interviews with ten experts in software quality and software testing enabled us to identify and validate analytical categories that mediate the relation between those two models. The result was the development of an organizational structure to support managers, developers and customers in software projects for enterprise information systems.

Keywords: information systems development, software testing, socio-technical approach, process quality, project management

1 INTRODUÇÃO

Na indústria brasileira de desenvolvimento de software para sistemas de informações (SIs), observa-se sensibilidade nas empresas quanto à qualidade de seus produtos (Weber et al., 2001), que se assume estar relacionada à qualidade do processo de desenvolvimento (Da Rocha et al., 2001).

Uma forma de abordar a qualidade dá-se por meio do teste de software (TS), que define atividades de verificação e validação com o objetivo de encontrar problemas. A importância da integração da atividade de TS ao desenvolvimento fica evidente quando esta "tem sido considerada cada vez mais como fator essencial para a obtenção de sistemas de software de qualidade" (Herbert, 1999, p. 17). Tal importância é reforçada pelo fato de que menores serão o custo e a dificuldade das correções se mais próximos de sua origem os erros forem detectados (Da Rocha et al., 2001). Não obstante, o TS foi tradicionalmente visto como atividade complementar (Beizer, 1990; Hetzel, 1987).

Nesse panorama, e considerando que a organização desenvolvedora de SI como um todo deve ser formatada segundo uma orientação para a qualidade (Ravichandran e Rai, 2001), o presente artigo define um modelo organizacional de natureza sociotécnica para apoio a TS, modelo esse suficientemente compreensivo e flexível, de modo a ser válido e aplicável por qualquer organização em projetos de software para SI. Em síntese, partiu-se do pressuposto de que uma efetiva gestão do desenvolvimento de SI apoiada em boas práticas de TS e segundo uma perspectiva sociotécnica de trabalho está na raiz da efetividade do sistema resultante (Figura 1).

Como interesse específico, desenvolveu-se tal modelo para aplicação imediata em uma empresa fornecedora de sistemas altamente personalizáveis de gestão para cooperativas de crédito (aqui, chamada de "EmpresaCaso"), de modo que pudesse servir a fins teóricos (validação do modelo proposto) e práticos (eficácia e eficiência da EmpresaCaso no que diz respeito ao desenvolvimento de SI). A escolha da EmpresaCaso como local de estudo deve-se ao fato de um dos autores, à época das investigações, nela haver coordenado a implantação de um ambiente de TS para aprimorar o processo - e, supõe-se, a qualidade do produto final.

Para tanto, mostrou-se necessário: (1) identificar fatores essenciais para a qualidade de TS (disto originando-se o modelo processual ST-TS); (2) identificar fatores essenciais para a qualidade da gestão de TS (disto originando-se o modelo gerencial SET); (3) entender a relação entre os dois conjuntos de fatores; (4) coletar a percepção de especialistas em qualidade e teste de software a respeito de fatores organizacionais que influenciam suas atividades, bem como sobre o modo de essa influência ser exercida; e (5) organizar a teoria e a prática de gestão de TS em um conjunto de fatores críticos alinhados aos pressupostos da gestão da qualidade. O entendimento sistêmico derivado da atenção a esses objetivos deu origem ao modelo teórico-empírico VAST para auxiliar gestores, desenvolvedores e clientes nas atividades de TS em projetos de SI.

2 TESTE DE SOFTWARE

Segundo Pressman (1995, p. 724), qualidade de software é a "conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo software profissionalmente desenvolvido". Para a produção de software com qualidade superior, é essencial haver um processo formal e padronizado de desenvolvimento. Também não é possível alcançar qualidade na ausência de uma garantia de qualidade de software (GQS) que ocorra paralelamente ao desenvolvimento e que verifique e valide suas etapas. Para a implantação de processos de qualidade, normas e padrões como ISO/IEC-12207 e os diversos modelos CMM (de maturidade de competências em processo de software) podem ser empregados (Bartié, 2002).

TS é uma das atividades de verificação e validação de software e tem por objetivo avaliar características ou recursos de um programa de computador (Hetzel, 1987) na busca por defeitos (Pyhäjärvi e Rautiainen, 2004), sendo elemento crítico para a GQS (Da Rocha et al., 2001). TS é, de fato, crucial ao desenvolvimento de software (Huq, 2000), sobretudo quando se entende o papel estratégico dos SIs nas organizações modernas (Chan et al., 1997; Sabherwal e Chan, 2001).

Para realizar TS, a literatura oferece diversas alternativas - cuja discussão foge ao escopo deste artigo. A importância das técnicas disponíveis e dos correspondentes critérios para aplicação é permitir que se faça um planejamento adequado dos casos de teste. Na ausência de um bom planejamento, é provável que se obtenha um conjunto de casos que não possibilite a efetiva localização de erros ou que se faça haver um número excessivo de casos (Beizer, 1990; Myers, 1979). Uma compilação abrangente de alternativas de TS pode ser conferida em Franzen e Bellini (2005); já Kishi e Noda (2006) e Pohl e Metzger (2006) discutem princípios de teste em linhas de produtos de software - talvez a área mais promissora para TS na atualidade; e Jeyaraj e Sauter (2007) apresentam resultados empíricos sobre a efetividade de ferramentas de modelagem e verificação de modelos em projetos de SI.

3 QUALIDADE EM GESTÃO E TESTE DE SOFTWARE PARA

SISTEMAS DE INFORMAÇÕES

Palvia et al. (2001) desenvolvem um modelo sociotécnico para avaliação da qualidade de um SI computacional, modelo esse alinhado a proposições primitivas do tratamento sistêmico da organização do trabalho (cf. Trist e Murray, 1993 e Mumford, 1999). O modelo responde a uma necessidade de longa data para a efetiva aplicação da abordagem sociotécnica à área de SI: ele torna operacionais os principais conceitos e, sobretudo, descreve com clareza as dimensões básicas de análise para qualquer estudo que faça uso dessa abordagem.

Os autores também propõem que se adote uma perspectiva de qualidade que seja multidimensional por natureza, fundamentada em teoria e que permita interpretações diferentes, conforme os indivíduos que a utilizem. Assim, dado que a proposta sociotécnica elabora os sistemas humanos de trabalho como sendo o resultado da interação entre componentes sociais e técnicos, Palvia et al. (2001) entendem os SIs (que são entidades homem-máquina) na forma de dois subsistemas: o técnico (que aborda a natureza da tarefa/processo a ser executada e a tecnologia de apoio) e o social (que aborda os indivíduos responsáveis pelas tarefas e a estrutura/organização necessária para a efetividade do sistema de trabalho). Desenvolvem, então, 39 fatores de qualidade de SI:

• tarefa/processo: dificuldade, escassez, utilidade, confiança, realismo, criticidade, novidade, simplificação;

• tecnologia: interatividade, codificabilidade, operatividade, velocidade, exaustividade, inferência, explicabilidade, aumento, especificidade, precisão, apresentação, compatibilidade, documentação, amigabilidade, modificabilidade;

• indivíduo: estímulo, alívio, não-ameaça, aprovação da gerência, entusiasmo, assistência pessoal, inclusão, ajuda especializada; e

• estrutura/organização: burocratização, educação, adaptatividade, concordância, inovação, desempenho, viabilidade, competitividade.

De acordo com esses autores, a abordagem a ser esposada na avaliação de um SI dependerá do tipo de sistema, sendo improvável que um único método ou modelo possa ser empregado em todas as situações. Na presente pesquisa, porém, dado o caráter exploratório e restrições de orçamento, tempo e acesso às múltiplas organizações da indústria de software, buscou-se adaptar os fatores do modelo de Palvia et al. (2001) para tratar TS independentemente do tipo de SI no qual procedimentos de teste devem ser conduzidos. Vale ressaltar que Palvia et al. (2001) estudaram características de produto (SIs), enquanto aqui se busca uma visão de processo (TS). A adaptação aqui realizada encontra apoio na experiência profissional dos autores da presente pesquisa, na validação dos pressupostos junto a dois pesquisadores externos e na revisão da literatura (e.g., Myers, 1979, Hetzel, 1987, Beizer, 1990, Arthur, 1994, Pfleeger, 1998, Pressman, 1995, Da Rocha et al., 2001, Weber et al., 2001 e Bartié, 2002).

O Quadro 1 apresenta a adaptação dos fatores originais ao contexto de TS, dando origem ao modelo Socio-technical Factors to Testing Software (ST-TS).

Já Ravichandran e Rai (2000) propõem um modelo de natureza sociocomportamental e organizacional que, com base na Gestão da Qualidade Total (GQT), relaciona elementos importantes para um sistema orientado à gestão da qualidade do desenvolvimento de SI. A presente pesquisa utiliza esse modelo para orientar a aplicação dos fatores ST-TS anteriormente descritos.

O ponto de partida para Ravichandran e Rai (2000) é o pressuposto de que o desempenho da qualidade é determinado amplamente por fatores sistêmicos em uma organização, não podendo os problemas relacionados à qualidade ser resolvidos por meio de soluções intermediárias. É conceito fundamental para a GQT que as organizações devem ser vistas como um sistema de processos interligados, sendo os fatores desse sistema os determinantes para o desempenho da qualidade. O argumento dá conta de que indivíduos ou tecnologias específicas exercem pouco impacto sobre o desempenho da qualidade e que o comportamento dos envolvidos - indivíduos ou grupos - pode ser manipulado por meio do sistema organizacional. Já no sentido de melhoria de processos, propõem-se modelos de maturidade de competências (e.g., CMM) que definem caminhos evolucionários desde um processo indefinido até um processo disciplinado e em constante melhoria. Contudo, alerta-se que a aplicação de preceitos da GQT perde força quando os mesmos não estão inseridos em um sistema organizacional de apoio à qualidade.

Ravichandran e Rai (2000) identificam cinco construtos essenciais para essa perspectiva de ação (Quadro 2):

• liderança da alta gerência: envolvimento da alta gerência com a melhoria da qualidade e iniciativas de qualidade para a organização desenvolvedora de SI;

• sofisticação da infra-estrutura gerencial: propriedade estrutural da organização no sentido de estabelecer um ambiente orientado à qualidade para processos e práticas de trabalho;

• eficácia da gestão de processos: modo como o desenvolvimento é definido, controlado e melhorado de maneira sistemática;

• participação de interessados: grau em que práticas de trabalho são estabelecidas para que grupos de interessados contribuam efetivamente para a base de conhecimentos; e

• desempenho da qualidade: atendimento de objetivos de produto e de processo.

Ravichandran e Rai (2000) também propõem uma relação de antecedência entre os construtos, assim obtendo um modelo organizacional causal e orientado à qualidade para o desenvolvimento de SI. Segundo esse modelo, metas em qualidade de software são mais facilmente atingidas quando a alta gerência cria uma infra-estrutura gerencial que promove melhorias na modelagem dos processos e encoraja os participantes a fazerem evoluir o desenho do processo de desenvolvimento.

O Quadro 3 apresenta a adaptação dos construtos e seus fatores ao contexto de TS, dando origem ao modelo Structure for Enhancing Test (SET).

O fato de não se conhecer aplicação dos modelos de Palvia et al. (2001) e de Ravichandran e Rai (2000) às práticas institucionais de TS torna original o desenvolvimento dos modelos ST-TS e SET, que permitem um tratamento sistêmico, balanceado (em nível técnico e social) e causalmente orientado à qualidade de processo e de produto.

4 MÉTODO

Os modelos ST-TS e SET foram investigados na prática por meio de um estudo de caso exploratório. A escolha desse método se deve ao fato de o mesmo ser um tipo de pesquisa empírica que possibilita abordar profundamente uma situação contemporânea em seu contexto real, sem que o pesquisador, porém, interfira de modo significativo no objeto em foco (Stake, 2000; Yin, 2001; Palvia et al., 2003; Benbasat et al., 1987).

No presente estudo de caso, a unidade de análise (objeto conceitual de interesse da pesquisa) está representada pelas práticas institucionalizadas de TS em empresas especialistas em desenvolvimento de SI. Como local de pesquisa (objeto real, em que se estudou a unidade de análise), elegeu-se uma empresa fornecedora de sistemas altamente personalizáveis para a gestão de cooperativas de crédito (doravante denominada "EmpresaCaso"). A seleção da EmpresaCaso deve-se a fins teóricos (validação dos modelos ST-TS e SET) e práticos (eficácia e eficiência da EmpresaCaso no que diz respeito ao desenvolvimento de SI); em especial, foi decisivo o fato de um dos autores nela haver exercido, durante toda a pesquisa, atividade profissional como responsável pela definição e implantação de políticas de TS que aprimorassem o processo da empresa - e, estima-se, a qualidade de seus produtos também.

O principal produto ofertado pela EmpresaCaso sofre evolução constante e apresenta uma dinâmica própria de atualizações e correções; ocorre, também, o desenvolvimento de aplicações para o ambiente Web. Atualmente, a EmpresaCaso direciona um volume expressivo de recursos para a correção de rotinas e funcionalidades de SI, dada a alta taxa de retrabalho comum às correções. Tão importante quanto esse tipo de questões internas problemáticas é a satisfação do usuário com os produtos resultantes.

A empresa identificou como prioridade promover, por meio da melhoria do processo de software, a qualidade dos sistemas finais e a conseqüente satisfação do usuário. No âmbito interno, buscou diminuir o retrabalho no desenvolvimento, a fim de que mais recursos pudessem ser destinados a novos projetos. Por necessitar de resultados no curto prazo, a empresa inclusive já havia iniciado um esforço bruto - sem qualquer formalidade de teste e correção de erros. Um dos autores da presente pesquisa, então percebendo a pouca atenção às possíveis causas de problemas de software, propôs-se a definir e implantar uma política organizacional de apoio a TS que fosse integral ao desenvolvimento.

O estudo de caso envolveu as seguintes etapas metodológicas:

• levantamento bibliográfico sobre qualidade e teste de software, objetivando resgatar conceitos e perspectivas sobre o assunto e identificar os modelos básicos para o trabalho (Hoppen et al., 1996);

• adaptação do modelo sociotécnico de Palvia et al. (2001) e do modelo sociocomportamental e organizacional de Ravichandran e Rai (2000) às práticas de TS;

• construção e validação (junto a dois pesquisadores externos) de instrumento de coleta de dados (roteiro de entrevista) para entrevistas em profundidade sobre o impacto de fatores organizacionais no planejamento e execução de TS;

• entrevistas em profundidade junto a dez profissionais com experiência em qualidade e teste de software, abordando fatores e condições necessárias para TS; e

• cruzamento dos resultados da análise de conteúdo das entrevistas com proposições teóricas a respeito da relação entre fatores dos modelos estudados.

4.1 Entrevistados

A seleção de dez entrevistados observou os seguintes passos:

• identificaram-se empresas do pólo gaúcho de software Tecnopuc que já tivessem implantado metodologia de TS e possuíssem pessoas capacitadas na área;

• fez-se contato com as empresas selecionadas, ocasião em que se apresentou a intenção de entrevistar profissionais de TS para validar os modelos teóricos da pesquisa; três empresas do pólo consentiram com o estudo, disponibilizando, juntas, cinco respondentes com qualificação em TS;

• na EmpresaCaso, selecionaram-se quatro profissionais envolvidos com a implantação do processo de TS e com qualificação correspondente; e

• em outra empresa de desenvolvimento de software, selecionou-se um especialista em qualidade de software.

Entre os dez profissionais selecionados, quatro pertenciam ao quadro funcional da EmpresaCaso, e tal número se deve basicamente a dois motivos: (1) a EmpresaCaso é objeto de interesse específico do estudo, visto que a política de TS resultante seria nela inicialmente aplicada; e (2) houve dificuldade para abordar, junto a outras empresas, um número maior de especialistas em TS que pudessem contribuir para a pesquisa.

Uma observação deve ser feita quanto a um dos entrevistados da EmpresaCaso, que exerce a função de programador: sua participação na pesquisa é devida ao fato de o mesmo fazer parte da equipe de metodologia de TS da EmpresaCaso, sendo responsável pela integração dessas atividades às de desenvolvimento.

Optou-se por classificar os respondentes a partir de dois critérios (Quadro 4):

• tempo de experiência em atividades de qualidade e teste de software; e

• função exercida na empresa - dando origem a dois grupos (com exceção de um programador, classificado à parte): gerentes, que são os envolvidos em planejamento e controle de TS, e testadores, que são os responsáveis pelo nível operacional de TS.

Observa-se relação entre o tempo de experiência e a função exercida: com exceção do Entrevistado 4 - que, com apenas um ano de experiência em TS, já ocupa posição gerencial -, nota-se que o tempo de experiência de três anos parece representar um ponto de corte. Assim, passou-se a desconsiderar o tempo de experiência e a adotar a função exercida para dividir os entrevistados em dois grupos: gestores (entrevistados 4, 6, 7, 8, 9 e 10) e operadores (entrevistados 1, 2, 3 e 5).

4.2 Roteiro de Entrevistas

Elaborou-se um roteiro para entrevistas em profundidade formado por 17 questões relacionando fatores SET e fatores ST-TS, conforme discernimento próprio dos autores (Quadro 5).

4.3 Vetores Mediadores entre Gestão e Processo de TS

Por meio de análise de conteúdo das entrevistas, observando os critérios de Lima Filho (citados em Borges, 2000) de aglutinação (reunião de termos conceitualmente semelhantes), desmembramento (separação de termos conceitualmente distintos), determinância (atenção a termos conceitualmente relevantes) e representatividade (atenção a termos enfatizados nas entrevistas), identificaram-se categorias conceituais pelas quais as práticas de gestão influenciam a qualidade de TS (Quadro 6 e Figura 2). Esse conjunto de influências de fatores SET (gerenciais) sobre fatores ST-TS (processuais) por meio de vetores sugeridos por especialistas em qualidade e teste de software constitui o modelo organizacional Vivid Ambience for Software Testing (VAST) de apoio às atividades operacionais e gerenciais de TS em projetos de sistemas de informação. Dada sua complexidade gráfica, tal modelo é aqui representado em diagramas parciais, conforme explicação a seguir.

5 DISCUSSÃO

Nas seções seguintes, apresentam-se os relacionamentos entre fatores SET e fatores ST-TS, relacionamentos esses mediados pelas categorias emergentes da análise de conteúdo (vetores causais). Além do que foi identificado na prática por meio das entrevistas, eventualmente são também sugeridos outros relacionamentos teóricos considerados relevantes para pesquisas futuras e o estabelecimento de um ambiente organizacional de TS mais complexo, conforme discernimento experiencial dos autores.

Nas figuras subseqüentes, utiliza-se a seguinte convenção:

Para cada vetor causal, também se informa o número de gestores ("Ger.") e de operadores ("Op.") que mencionaram a correspondente categoria de influência.

5.1 Estímulo

O fator ST-TS "estímulo" (Figura 3) compreende o estímulo que os profissionais de TS recebem para o trabalho, e é dado pela quantidade de desafios, autonomia e reconhecimento resultantes do uso do sistema. O fator sofre alta influência da categoria "missão e valores", estabelecida pela alta gerência no planejamento estratégico da organização e transmitida aos funcionários. A segunda categoria importante é a "conscientização" dos profissionais em relação às possíveis conseqüências positivas e negativas da execução de TS.

Uma categoria merecedora de destaque é "bonificação", que se refere a esquemas de recompensa por resultados. Usualmente, afirma-se que esses esquemas têm grande importância para a melhoria da qualidade nas organizações (Osmundson et al., 2003; Kirsch et al., 2002; Ravichandran e Rai, 2000; Blackstone Jr. et al., 1997); porém, na presente pesquisa, verificou-se o contrário. Isso permite sugerir que a bonificação talvez não deva alicerçar iniciativas em qualidade, ao menos em TS. Alguns argumentos dos entrevistados foram que "qualidade é um dever, não um favor" e "atingir as metas estabelecidas é algo previsto no planejamento das atividades de garantia da qualidade"; também se chamou atenção para o fato de que associar recompensas à detecção de erros pode "levar a uma perda de eficiência no processo de TS, pois o testador pode ser tentado a encontrar erros além do escopo definido, assim comprometendo o andamento das atividades conforme planejado".

5.2 Disponibilidade

Por meio do fator ST-TS "disponibilidade" (Figura 4), busca-se estimar a disponibilidade de profissionais especialistas para execução e apoio às atividades de TS. A categoria de maior impacto neste fator é a "capacitação técnica e de negócio" para proporcionar aos profissionais da área condições para que adquiram ou renovem o conhecimento necessário para a proficiência nas atividades de TS. Entre os meios utilizados para a capacitação, citam-se a oferta de cursos e treinamentos externos, a realização de oficinas e incentivos a certificações ou cursos universitários.

A segunda categoria enfatizada nas respostas foi "especialista em TS". O argumento para a importância dessa categoria é que toda atividade, principalmente no estágio inicial de implantação de algo tão complexo como TS, necessita de uma referência dentro da organização, alguém que conheça as idiossincrasias do processo. E a terceira categoria de destaque é "usuário". Supõe-se que existam aspectos quanto à usabilidade de um SI que somente os usuários conseguem identificar, dado que têm uma visão própria de como o sistema deve funcionar - além de serem, em geral, os maiores conhecedores da aplicação do mesmo. Uma alternativa para as categorias "especialista em TS" e "usuário" é a utilização de consultorias.

5.3 Viabilidade

O fator ST-TS "viabilidade" (Figura 5) indica o quanto a elaboração e a adoção de uma metodologia de TS são economicamente viáveis na organização. Isso implica tornar possível que profissionais de TS tenham as condições necessárias para o planejamento e a execução de TS. Observa-se, como categoria mais influente, a necessidade de haver uma "infra-estrutura de desenvolvimento". A justificativa está em que "é preciso existir um processo de software a ser validado" - é preciso saber o que testar. Isso é corroborado pelo fato de que muitas técnicas de TS usam especificações e código-fonte para o estabelecimento dos critérios de teste. Por exemplo, não é viável a elaboração de um diagrama de causa-efeito sem especificação formal do comportamento de um módulo/tela, ou um teste de fluxo de dados sem padrão de endentação de código e nomenclatura de variáveis. Trata-se de haver um processo de desenvolvimento testável em todas as suas etapas.

A segunda categoria mais enfatizada para este fator foi a "liberação de recursos" por parte da alta gerência para apoiar técnicos e gerentes em relação à qualidade e para montar uma infra-estrutura de TS. Embora a referência a essa categoria tenha sido baixa, ela é importante por complementar a anterior; se a primeira categoria viabiliza o planejamento das atividades de TS ("o que" e "como" fazer), a segunda viabiliza a execução propriamente dita ("onde" fazer). Ainda se sugere que este fator sociotécnico possa se refletir em outros fatores organizacionais por meio das categorias "setor dedicado" e "metodologia de TS".

5.4 Automação

O fator ST-TS "automação" (Figura 6) permite que se meça o aproveitamento de ferramentas de automação no processo de TS. Observa-se apenas a categoria "metodologia de TS" de influência sobre o fator, mas sua baixa incidência nas entrevistas a torna questionável. A justificativa para a possível influência é que as ferramentas não fazem os testes sozinhas; elas necessitam de regras e padrões definidos no planejamento de TS. Outras categorias que não foram observadas, mas que os autores julgam importantes, são "liberação de recursos" e "capacitação técnica e de negócios", dado que as ferramentas de automação apresentam custo de aquisição, manutenção e de profissionais capacitados para a efetividade de uso.

Com relação a categorias potencializadas por este fator sociotécnico, a possível influência sobre a categoria "demanda por recursos" baseia-se na idéia de que o uso de ferramentas de automação das atividades de TS contribui para um aumento (em quantidade e qualidade) das mesmas, visto que, quando as ferramentas são corretamente utilizadas por profissionais capacitados, reduz-se o tempo de execução das atividades. Outro ponto que diz respeito à demanda por recursos é a diminuição de trabalho na elaboração de casos de teste, dado que muitas atividades podem ser padronizadas nas ferramentas e, assim, não necessitar de novo planejamento antes da execução. Pode-se sugerir, também, que o uso de ferramentas contribui no sentido de "forçar" a obediência a padrões e metodologias definidas de TS, desde que existentes na organização.

Outras categorias que podem sofrer reflexo do uso de ferramentas de automação são "coleta de dados" e "análise de dados e desempenho". A primeira se justifica quando muitas ferramentas de TS armazenam os testes executados e respectivos resultados, assim forçando um registro histórico de atividades; e a segunda ocorre porque as ferramentas podem gerar relatórios e gráficos que representem situações das atividades de TS, como erros encontrados em cada tipo de teste e tipos de teste que apontaram mais erros.

5.5 Documentação

O fator ST-TS "documentação" (Figura 7) representa o esforço realizado para documentar as atividades de TS e seus respectivos resultados. Foi observado que, assim como o fator anterior, ele mais exerce do que sofre influência de categorias.

Entre as categorias, identificam-se influências de "metodologia de TS" e "coleta de dados". A primeira se dá porque o ato de registrar atividades de TS (o que foi testado, como foi testado e quais os resultados) pode obedecer um item definido na metodologia de TS - que roga não apenas executar, mas também deixar documentado para posterior consulta. Já a justificativa para a segunda categoria é mais óbvia, uma vez que, se não houver coleta de dados no processo de TS, não haverá dados a organizar e documentar. Embora as duas categorias encontrem apoio na literatura de engenharia de software, o número de ocorrências foi muito baixo para serem consideradas confirmadas na prática.

Quanto às categorias entendidas como influenciadas pela documentação, a de maior ocorrência foi "base de conhecimentos", que seria a explicitação das experiências, soluções propostas a problemas e conhecimentos tácitos, na forma de textos, manuais e apresentações, a fim de que todas as descobertas importantes estejam à disposição dos interessados. Uma segunda categoria relacionada ao fator foi "análise de dados e desempenho", pois os dados naturalmente coletados para documentação podem alimentar métricas que, por sua vez, possibilitariam visualizar o estado do processo de TS dentro da organização.

5.6 Operatividade

Com o fator ST-TS "operatividade" (Figura 8), quer-se medir o quanto a execução de TS ocorre sem prejuízo de outras atividades do desenvolvimento de SI. O fator apresenta apenas uma categoria relevante, que foi o estabelecimento de um "setor dedicado". Isto se deve a que as atividades de TS não podem ficar em segundo plano, embora realizadas conforme disponibilidade de recursos (como tempo, pessoas e tecnologias); pode-se buscar tal objetivo conferindo às equipes de TS e desenvolvimento igualdade de importância. Deve-se introduzir, também, uma definição formal deresponsabilidades para que os profissionais não percam o foco de trabalho, e a execução dos testes deve ocorrer em ambiente controlado que não sofra a interferência de outras atividades de desenvolvimento.

5.7 Evolução e Zero-defeito

Por meio do fator ST-TS "evolução" (Figura 9), verifica-se o esforço empregado no sentido de melhorar o processo de TS. A categoria de maior influência sobre o fator é "observação de mercado", fundamental para que a organização saiba como está (no que diz respeito a TS) em termos comparativos, e se as suas práticas são satisfatórias. Outra categoria de grande influência é "análise de dados e desempenho", pois, para fazer comparações, a organização precisa medir o próprio desempenho. Ademais, com a análise de dados, é possível identificar pontos fracos do processo de TS, o que justifica o surgimento da terceira categoria mais citada nas respostas, o "direcionamento de esforços" - porém não como categoria influenciadora, mas influenciada.

Na análise da evolução, importa compreender o papel do fator ST-TS "zero-defeito" (Figura 10), que mede a aproximação do processo de software à verificação de ausência de defeitos (Myers, 1979; Bartié, 2002). Segundo Myers (1979), ela é inatingível, pois não há como garantir que um software esteja totalmente livre de erros, e, assim, o que se busca é a "não-tolerância a erros dentro de um processo de qualidade de software" (Bartié, 2002, p. 23). As duas categorias mais influentes sobre o zero-defeito são "análise de dados e desempenho" e "estabelecimento de metas". O zero-defeito seria a combinação das duas categorias para medir a diferença entre resultados obtidos e planejados, assim orientando a organização a apresentar uma quantidade cada vez menor de problemas no processo de desenvolvimento e no produto final.

A observação de um dos entrevistados sugeriu entendimento à parte quanto à relação entre os dois fatores ST-TS (evolução e zero-defeito): "é preciso saber administrar a implantação de novas metodologias ou a adoção de novas técnicas, não havendo a necessidade de melhorar um processo que já atinge perfeitamente os objetivos planejados, e deve ser algo que satisfaça as necessidades da empresa". A partir disso, sugere-se a "absorção" do zero-defeito pela evolução, pois a combinação do estabelecimento de metas e da análise de dados e desempenho poderia ser usada para "dosar" os esforços empregados no sentido de melhorar o processo, de acordo com as necessidades da organização. Sugere-se que esse fator tenha reflexos no direcionamento de esforços, dado que apontaria necessidades mais urgentes no processo de TS.

5.8 Não-ameaça

O fator ST-TS "não-ameaça" (Figura 11) aborda o quanto as pessoas envolvidas no desenvolvimento se sentem ameaçadas pelas atividades de TS, visto que estas tendem a apontar a origem dos erros. A única categoria associada ao fator é "finalidade", que envolve a explicitação dos objetivos de TS - no sentido de que o mesmo busca avaliar processos, não pessoas (Pressman, 1995). Contudo, a validade ou relevância desse fator é questionável, dado que poucos entrevistados fizeram referência à única categoria.

5.9 Eficiência

O fator ST-TS "eficiência" (Figura 12) mede a quantidade de esforço necessário para a realização de TS com sucesso (detectando erros). Observou-se que uma única categoria foi associada ao fator, porém a validade da associação é novamente questionável, dado que o número de ocorrências foi muito baixo. A justificativa para uma possível associação pode ser encontrada na literatura sobre TS previamente discutida, segundo a qual uma metodologia de TS corretamente elaborada teria impacto direto em eficácia e eficiência.

5.10 Política de Apoio ao Teste de Software

O conjunto das influências de fatores SET (gerenciais) sobre fatores ST-TS (processuais) por meio das categorias de análise empiricamente identificadas junto aos especialistas em qualidade e teste de software constitui o modelo organizacional aqui denominado VAST para apoio às atividades operacionais e gerenciais de teste de software em projetos de sistemas de informações empresariais.

6 CONSIDERAÇÕES FINAIS

Ao longo do presente estudo, especialmente durante o levantamento bibliográfico, foi possível confirmar a afirmação de Ravichandran e Rai (2000) de que pesquisas em qualidade de software focam bastante os aspectos técnicos e de engenharia do controle da qualidade, sendo pequena a atenção destinada a aspectos organizacionais da gestão da qualidade. Assim, buscou-se identificar fatores essenciais para a institucionalização de um ambiente organizacional que favoreça a implementação e a manutenção de um processo formal de teste de software (TS) integrado ao desenvolvimento e alinhado a preocupações mais amplas sobre gestão da qualidade.

Para atingir esse objetivo, a pesquisa desenvolveu três modelos: o primeiro (ST-TS) organiza elementos sociotécnicos considerados importantes (embora talvez não suficientes) para a concepção da qualidade do processo de TS; o segundo (SET) estabelece um ambiente organizacional de apoio sistêmico a TS; e o terceiro (VAST) identifica categorias de análise teórico-empíricas que mediam a relação entre fatores dos dois modelos anteriores e indicam propriedades pelas quais elementos organizacionais agem sobre o processo de TS.

A pesquisa, contudo, esteve limitada à empresa que promoveu a iniciativa. Assim, tem-se somente a apreciação positiva e subjetiva daquela empresa quanto ao modelo VAST, sem demonstrações formais da efetividade de sua aplicação para uma série de situações possíveis em TS. Encontra-se apenas em estágio de elaboração um método para investigar tal efetividade, dado que medir as conseqüências da atividade gerencial é sempre de eficácia questionável e requer um caráter longitudinal de análise. Como não foi possível, até o momento, realizar avaliação compreensiva do modelo VAST, não se pode especular se o mesmo será sempre capaz de melhorar as práticas de teste - aumentar a quantidade de erros localizados ou localizá-los com mais economia.

Duas limitações mais específicas devem ser consideradas para uma ampla discussão dos resultados: dificuldade em encontrar mais especialistas em qualidade e teste de software que pudessem contribuir para a pesquisa (o reflexo disso, porém, talvez não tenha sido fundamentalmente prejudicial à riqueza dos resultados, já que os entrevistados efetivos apresentam adequada capacitação em TS) e intensa subjetividade no desenvolvimento dos fatores ST-TS para medir a qualidade do processo de TS (fatores esses derivados de modelo conceitual originalmente formulado para medir qualidade de produto). Portanto, os modelos aqui desenvolvidos devem ser tomados como base para extensa discussão além das fronteiras da empresa em que os mesmos foram validados.

Como recomendações para a indústria, o presente estudo exorta gestores e desenvolvedores de software para sistemas de informações a introduzirem e observarem, de maneira inequívoca e sistêmica, boas práticas de TS. Em um primeiro momento, há que se investir na promoção de uma cultura de gerenciamento do desenvolvimento de software, dado que padronizar a rotina ou propor melhores práticas de processo é de eficácia duvidosa quando se trata de trabalhadores do conhecimento (Scarbrough, 1999); de fato, gerenciar equipes de software envolve desafios não triviais (Faraj e Sproull, 2000).

Em um segundo momento, gestores e desenvolvedores devem ser capacitados no tratamento de fatores tanto técnicos quanto sociais do processo de TS, dado que fatores dessas duas dimensões estão, por pressuposto, na base do alto desempenho de equipes de software (Bellini et al., 2007). Por fim, deve-se buscar a institucionalização da causalidade suposta entre qualidade da gestão de projeto, qualidade do processo de teste e qualidade do produto de software para sistemas de informação.

Sugerem-se os seguintes temas para pesquisas futuras: refinar os componentes dos modelos teóricos ST-TS e SET e vetores de influência, estimar a intensidade desses vetores, organizar toda a rede nomológica de construtos (modelo VAST completo) em um único diagrama, e validá-la na indústria nacional de desenvolvimento de software para sistemas de informações empresariais.

Carlo Gabriel Porto Bellini

Doutor em Administração - UFRGS, 2006

Mestre em Administração - UFRGS, 2001

Bacharel em Ciência da Computação - UFRGS, 1994

Professor-adjunto do Departamento de Administração e

Vice-coordenador do Programa de Pós-Graduação em Administração da UFPB.

Universidade Federal da Paraíba, Programa de Pós-Graduação em Administração.

Telefone: (83) 3216.7454

E-mail: [e-mail]

Recebido em: 23/11/2007

Aprovado em: 10/05/2008

• ARTHUR, L.J. Melhorando a qualidade do software Rio de Janeiro: Infobook, 1994.
• BARTIÉ, A. Garantia da qualidade de software Rio de Janeiro: Elsevier, 2002.
• BEIZER, B. Software testing techniques Scottdale: Coriolis Group, 1990.
• BELLINI, C.G.P.; PEREIRA, R.C.F.; BORENSTEIN, D. Managing customer teams in information systems customization. XXXI EnANPAD Rio de Janeiro: ANPAD, 22-26/09/2007.
• BENBASAT, I.; GOLDSTEIN, D.K.; MEAD, M. The case research strategy in studies of information systems. MIS Quarterly, v. 11, n. 3, 1987, pp. 369-386.
• BLACKSTONE JR., J.H.; GARDINER, L.R.; GARDINER, S.C. A framework for the systemic control of organizations. International Journal of Production Research, v. 35, n. 3, 1997, pp. 597-609.
• BORGES, G. Comércio eletrônico: atributos relevantes no processo de decisão de compra Dissertação (Mestrado em Administração). Porto Alegre: UFRGS, 2000.
• CHAN, Y.E.; HUFF, S.L.; BARCLAY, D.W.; COPELAND, D.G. Business strategic orientation, information systems strategic orientation, and strategic alignment. Information Systems Research, v. 8, n. 2, 1997, pp. 125-150.
• DA ROCHA, A.R.C.; MALDONADO, J.C.; WEBER, K.C. (Orgs.). Qualidade de software São Paulo: Prentice Hall, 2001.
• FARAJ, S.; SPROULL, L. Coordinating expertise in software development teams. Management Science, v. 46, n. 12, 2000, pp. 1554-1568.
• FRANZEN, M.B.; BELLINI, C.G.P. Arte ou prática em teste de software? REAd, v. 11, n. 3, 2005.
• HERBERT, J.S. Teste cooperativo de software Tese (Doutorado em Ciência da Computação). Porto Alegre: UFRGS, 1999.
• HETZEL, W. Guia completo ao teste de software Rio de Janeiro: Campus, 1987.
• HOPPEN, N.; LAPOINTE, L.; MOREAU, E. Um guia para avaliação de artigos de pesquisa em sistemas de informação. REAd, v. 2, n. 2, 1996.
• JEYARAJ, A.; SAUTER, V.L. An empirical investigation of the effectiveness of systems modeling and verification tools. Communications of the ACM, v. 50, n. 6, 2007, pp. 63-67.
• KIRSCH, L.J.; et al. Controlling information systems development projects: the view from the client. Management Science, v. 48, n. 4, 2002, pp. 484-498.
• KISHI, T.; NODA, N. Formal verification and software product lines. Communications of the ACM, v. 49, n. 12, 2006, pp. 73-77.
• MUMFORD, E. Routinisation, re-engineering, and socio-technical design. In: CURRIE, W.L.; GALLIERS, B. (Orgs.). Rethinking management information systems New York: Oxford University Press, 1999, pp. 28-44.
• MYERS, G.J. The art of software testing New York: John Wiley & Sons, 1979.
• OSMUNDSON, J.S.; MICHAEL, J.B.; MACHNIAK, M.J.; GROSSMAN, M.A. Quality management metrics for software development. Information & Management, v. 40, n. 8, 2003, pp. 799-812.
• PALVIA, P.; MAO, E.; SALAM, A.F.; SOLIMAN, K.S. Management information systems research: what's there in a methodology? Communications of the AIS, v. 11, 2003, pp. 289-309.
• PALVIA, S.C.; SHARMA, R.S.; CONRATH, D.W. A socio-technical framework for quality assessment of computer information system. Industrial Management & Data Systems, v. 101, n. 5, 2001, pp. 237-251.
• PFLEEGER, S.L. Software engineering Upper Saddle River: Prentice-Hall, 1998.
• POHL, K.; METZGER, A. Software product line testing. Communications of the ACM, v. 49, n. 12, 2006, pp. 78-81.
• PRESSMAN, R.S. Engenharia de software São Paulo: Makron Books. 1995.
• PYHÄJÄRVI, M.; RAUTIAINEN, K. Integrating testing and implementation into development. Engineering Management Journal, v. 16, n. 1, 2004, pp. 33-39.
• RAVICHANDRAN, T.; RAI, A. Quality management in systems development: an organizational system perspective. MIS Quarterly, v. 24, n. 3, 2001, pp. 381-415.
• SABHERWAL, R.; CHAN Y.E. Alignment between business and IS strategies: a study of prospectors, analyzers, and defenders. Information Systems Research, v. 12, n. 1, 2001, pp. 11-33.
• SCARBROUGH, H. The management of knowledge workers. In: CURRIE, W.L.; GALLIERS, B. (Orgs.). Rethinking management information systems New York: Oxford University Press, 1999, pp. 474-496.
• STAKE, R.E. Case studies. In: DENZIN, N.K.; LINCOLN, Y.S. (Orgs.). Handbook of qualitative research Thousand Oaks: Sage, 2000, pp. 236-247.
• STAMELOS, I.; ANGELIS, L.; MORISIO, M.; SAKELLARIS, E.; BLERIS, G.L. Estimating the development cost of custom software. Information & Management, v. 40, n. 8, 2003, pp. 729-741.
• TRIST, E.; MURRAY, H. (Orgs.). The social engagement of social science. Volume II: the socio-technical perspective Philadelphia: University of Pennsylvania Press, 1993.
• WEBER, K.C.; DA ROCHA, A.R.C.; DO NASCIMENTO, C.J. (Orgs.) Qualidade e produtividade em software São Paulo: Makron, 2001.
• YIN, R.K. Estudo de caso Porto Alegre: Bookman, 2001.

Datas de Publicação

• Publicação nesta coleção
  23 Fev 2011
• Data do Fascículo
  2008

Histórico

• Aceito
  10 Maio 2008
• Recebido
  23 Nov 2007