O Analista de Testes e o Analista de Requisitos
Você vai desempenhar esses papéis um dia
Janeiro 07, 2016Quando você inicia sua carreira no mercado de trabalho recém saído de um curso superior, é comum que você inicie seu trabalho na área da empresa onde exista a oportunidade. Trazendo um pouco essa discussão para a área de tecnologia é menos provável que você assuma diretamente o trabalho de um analista de negócios por exemplo, pois isso exige uma bagagem maior e demandará mais tempo para que seja adquirida. Vou comentar um pouco sobre dois papéis que existem e provavelmente você irá formalmente ou não desempenhá-los:
Analista de Testes
Vamos falar um pouco sobre o que acontece em uma software house ou fábrica de software. Um exemplo comum é o profissional ainda cursando a faculdade entrar como estagiário e experimentar uma área na empresa onde no momento tenha mais necessidade de mão-de-obra. Como geralmente esse profissional não tem ainda uma experiência em programação e conhece pouco do domínio da empresa as chances dele entrar na equipe de testes e/ou homologação é grande.
Ao se trabalhar na equipe de testes ele precisa dominar o funcionamento do sistema na área que irá testar além de estudar documentação e especificações funcionais das alterações que estão sendo construídas. Por vezes ele também precisa dialogar com o desenvolvedor para dar um retorno sobre os testes que estão sendo realizados ou entender um pouco mais das alterações que estão sendo feitas e os impactos no sistema como um todo.
Além disso é frequente o contato com ferramentas de testes automatizadas, de gerenciamento de bugs (BugTracker) além de já também ter seu tempo gerenciado para trabalhar de acordo com cronogramas. É um trabalho mais cansativo pois o profissional precisa preparar bases de testes, executar rotinas dentro do sistema que podem levar muito tempo para serem feitas e, ao se detectar falhas em testes, reiniciar todo esse trabalho novamente. É aquela história de testes que você estuda em Engenharia de Software mas vai entender na prática somente aqui ;-). Mas é uma fonte de aprendizado sobre o domínio do sistema e caso ele tenha pretensões em outra área não pode deixar a carga de trabalho interferir em seu estudo de programação, por exemplo.
Análise e Levantamento de Requisitos
A transição da área de testes para a área de levantamento de requisitos não é tão difícil pois o conhecimento da área de domínio do sistema já está ali e capacita profissional a discutir com as pessoas que usam diariamente o sistema e entender as necessidades. Porém é importante aqui nesse momento além do conhecimento das minúcias do funcionamento de uma parte específica do software também ter o entendimento do todo, como um colega brincava dizendo "O overview da visão macro" (sic), mais redundante impossível.
Como o sistema se comporta? Qual a relação com outras áreas? Existem atualizações frequentes? Acontecem em lote ou de forma instantânea?
E o levantamento correto de requisitos é muito importante para o sucesso do projeto, o analista de requisitos tem um papel crucial pois não cabe a ele somente escutar as necessidades mas deve ter o espírito crítico aguçado pois muitas vezes não está claro para todas as partes o que realmente querem e de que forma esperam o comportamento do sistema. Esse papel de investigação é bem bacana. Só lembrando que de acordo com o Chaos Report do Standish Group o levantamento incorreto ou incompleto de requisitos e a especificação estão entre os maiores fatores de falhas em projetos. Ah, mas acho que você já viu esses dados pois são conhecidíssimos nas aulas de engenharia de software ou gerência de projetos. Todo professor usa (eu também já usei) ;-).
Aliás o que é uma aula de Engenharia de Software sem a famosa imagem do balanço? É de autoria do Project Cartoon e ficou famosa no mundo inteiro. Preciso colocar ela aqui para você ver mais uma vez:
Mas retomando, trabalhar com levantamento de requisitos é um trabalho investigativo e exigirá de você conhecimento técnico além de habilidades interpessoais, entrevistas e (talvez em menor escala) estudos de documentação. A ferramenta de trabalho de um analista de requisitos é o editor de textos. O detalhamento e a profundidade com que ele escreve e passa para o papel as necessidades irá repercutir nas dúvidas na especificação técnica e até mesmo lá na frente no desenvolvimento destes requisitos. É aqui onde as minúcias devem ser esclarecidas e as perguntas devem ser feitas buscando esgotar todas as possibilidades.
Iremos nos próximos posts falar mais um pouco sobre o cotidiano dos profissionais da área de tecnologia da informação bem como as habilidades técnicas e não técnicas que são esperadas. Acompanhe as postagens e deixe seu comentário aí embaixo. Aproveite e clique em SUBSCRIBE para receber no seu email sempre que uma nova postagem no site for feita.
Cover image credit: http://unsplash.com/@carlheyerdahl