Submitted by Natalia de Souza Gonçalves (natalia.goncalves@ufpe.br) on 2016-09-28T12:23:59Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Dissertacao_Cleydiane_FINAL_Imprimir.pdf: 3971527 bytes, checksum: f06a014d16a761f030bbfccee75d176f (MD5) / Made available in DSpace on 2016-09-28T12:23:59Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Dissertacao_Cleydiane_FINAL_Imprimir.pdf: 3971527 bytes, checksum: f06a014d16a761f030bbfccee75d176f (MD5) Previous issue date: 2016-02-19 / Dívida Técnica (DT) está relacionada a tarefas que devem ser executadas e são acumuladas ao longo de um projeto para serem realizadas posteriormente. A falta de planejamento de tempo e recursos em um projeto, dentre outros problemas, propiciam seu surgimento. DTs não solucionadas tendem a criar dependências e aumentar o grau de complexidade para correção, resultando em maior esforço, custo e retrabalho em um projeto. A sua identificação e gerenciamento ao longo de um projeto é essencial para minimizar seu impacto e consequências negativas. Estudos apontam teste de software como uma das principais áreas impactadas por DTs em projetos de software. Nesta dissertação foram mapeadas, a partir da literatura técnica, 22 possíveis DTs relacionadas ao processo de teste de software, assim como suas causas e indicadores. Elas foram avaliadas por meio de um survey com profissionais da área de teste de software. Como resultados do survey, são apresentados os níveis de concordância obtidos para cada DT, suas causas e indicadores sugeridos. Após essa validação da concordância quanto às DTs, foi identificada a necessidade de vincular soluções às causas de cada DT, para isto foi realizada uma nova revisão de literatura. A partir dos dados das DTs, com suas causas, indicadores e, agora, soluções, foi elaborado um mapa, com objetivo de apoiar profissionais da área de teste de software na gestão de DTs que podem ocorrer no decorrer da execução do processo de teste de software. Após a elaboração do mapa de gestão de dívida técnica, o mesmo foi avaliado a partir de um questionário (baseado na técnica de revisão em pares), por profissionais experientes em teste de software (líderes e consultores). Como resultado desta avaliação, são apresentadas as opiniões e considerações destes profissionais sobre a versão inicial do mapa elaborado. Por fim, é apresentado o resultado final do mapa, com as devidas alterações baseadas nas respostas obtidas no questionário de avaliação do mapa. / Technical Debit (TD) is related to the tasks which have to be executed but are accumulated during the development of a project to be implemented later. The lack of time and resource planning on a project, among other problems, facilitate its emergence. Unsolved TDs tend to create dependencies and increase the degree of complexity for corrections, resulting in bigger efforts, costs and rework on a project. Identifying and managing those issues are essential to minimize the impacts and negative consequences. Studies point out software testing as one of the most affected areas by TDs on a software project. At this dissertation, 22 (twenty-two) possible TDs related to testing software process were mapped from the technical lecture, along with its causes and indicators. They were evaluated through surveys with testing software experts. As result of the survey, it is presented the levels of accordance for each TD, also the suggested causes and indicators. After the accordance validation of the TDs, it was identified a demand to bind solutions to the causes of every TD, for this a new study was made. From the data of the TDs, along with its causes, indicators and solutions, a map was produced in order to support testing software professionals managing TDs that may appear during the testing software process execution. After producing the technical debit management map, the same was submitted for an evaluation, using a questionnaire (based on peer review technique), to testing software experts (leaders and consultants). As result of these evaluations, it is presented the opinions and remarks of those professionals about the final version of the produced map. Finally, it is presented the final result of the map, with the modifications based on the answers obtained through the map evaluation questionnaire.