9 research outputs found

    Towards a self-evolving software defect detection process

    Get PDF
    Software defect detection research typically focuses on individual inspection and testing techniques. However, to be effective in applying defect detection techniques, it is important to recognize when to use inspection techniques and when to use testing techniques. In addition, it is important to know when to deliver a product and use maintenance activities, such as trouble shooting and bug fixing, to address the remaining defects in the software.To be more effective detecting software defects, not only should defect detection techniques be studied and compared, but the entire software defect detection process should be studied to give us a better idea of how it can be conducted, controlled, evaluated and improved.This thesis presents a self-evolving software defect detection process (SEDD) that provides a systematic approach to software defect detection and guides us as to when inspection, testing or maintenance activities are best performed. The approach is self-evolving in that it is continuously improved by assessing the outcome of the defect detection techniques in comparison with historical data.A software architecture and prototype implementation of the approach is also presented along with a case study that was conducted to validate the approach. Initial results of using the self-evolving defect detection approach are promising

    Best software test & quality assurance practices in the project life-cycle. An approach to the creation of a process for improved test & quality assurance practices in the project life-cycle of an SME

    Get PDF
    The cost of software problems or errors is a significant problem to global industry, not only to the producers of the software but also to their customers and end users of the software. There is a cost associated with the lack of quality of software to companies who purchase a software product and also to the companies who produce the same piece of software. The task of improving quality on a limited cost base is a difficult one. The foundation of this thesis lies with the difficult task of evaluating software from its inception through its development until its testing and subsequent release. The focus of this thesis is on the improvement of the testing & quality assurance task in an Irish SME company with software quality problems but with a limited budget. Testing practices and quality assurance methods are outlined in the thesis explaining what was used during the software quality improvement process in the company. Projects conducted in the company are used for the research in the thesis. Following the quality improvement process in the company a framework for improving software quality was produced and subsequently used and evaluated in another company

    Pakettisynkronointitestauksen automaatio

    Get PDF
    Telecommunications network operators are shifting from circuit switched backhaul technologies into packet switched networks to save costs with increasing traffic loads. Frequency synchronization was inherently provided by the circuit switched network, but has to be provided by other means in packet switched networks. One solution is Precision Time Protocol (PTP), defined in IEEE standard 1588, which can be used to create a master-slave synchronization strategy to a network. Synchronization quality is an essential factor when using any synchronization technology. Packet synchronization quality requirements in different situations are defined in ITU-T recommendation G.8261. The objective of this thesis is to create test automation for ITU-T recommendation G.8261 Appendix VI performance test cases 12 through 17 for Precision Time Protocol. Hypothesis is that this automation will make testing more effective than if testing was done manually, allowing testing of more products in a smaller time frame. Automated test system was planned and implemented with various measurement and impairment devices, and testing software to utilize them and to generate results. As a result, PTP synchronization quality testing efficiency was increased by over 20% while reducing the possibility for human errors.Verkko-operaattorit vaihtavat matkapuhelinverkoissa käyttämiään tekniikoita piirikytkentäisistä pakettikytkentäisiin säästääkseen kustannuksia kasvavien liikennemäärien kanssa. Piirikytkentäisissä verkoissa taajuussynkronointi leviää verkkoteknologian myötä automaattisesti koko verkkoon, mutta pakettikytkentäisissä verkoissa se täytyy tuottaa muilla tavoin. Yksi ratkaisu ongelmaan on Precision Time Protocol (PTP), joka on määritelty IEEE standardissa 1588, ja jolla voidaan luoda verkkoon isäntä–renki -synkronointistrategia. Synkronoinnin laatu on keskeinen tekijä kaikissa synkronointiteknologioissa. Pakettisynkronoinnin laatuvaatimuksia eri tapauksissa on määritelty ITU-T suosituksessa G.8261. Tämän diplomityön tavoitteena on luoda testausautomaatio ITU-T suosituksen G.8261 liitteen VI suorituskykytesteille 12–17 käyttäen PTP:tä. Hypoteesina on, että automaation avulla testauksesta tulee tehokkaampaa, kuin jos samat testit suoritettaisiin manuaalisesti. Näin entistä useammat tuotteet saataisiin testattua entistä lyhyemmässä ajassa. Automatisoitu testausjärjestelmä suunniteltiin ja toteutettiin käyttäen valikoimaa erilaisia mittauslaitteita ja verkkoemulaattoreita, sekä näiden laitteiden hallintaan kehitettyä testausohjelmistoa. Lopputuloksena PTP-synkronointitestauksen nopeus parani yli 20 prosenttia ja inhimillisten virheiden mahdollisuus väheni

    A Technique for Evaluating the Health Status of a Software Module Using Process Metrics

    Get PDF
    Identifying error-prone files in large software systems has been an area where significant attention has been paid over the years. In this thesis, we propose a process-metrics based method for predicting the health status of a file based on its commit profile in its GitHub repository. Precisely, for each file and each bug fixing commit a file participates, we compute a dependency score of the committed file with its other co-committed files. The calculated score is appropriately decayed if the file does not participate in the new bug-fixing commits in the system. By examining the trend of the dependency score for each file as time elapses, we try to deduce whether this file will be participating in a bug fixing commit in the immediately following commits. This approach has been evaluated in 21 medium to large open-source systems by correlating the dependency metric trend against the known outcome obtained from a data set we use as a gold standard

    Analyse comparative du test exploratoire et du test scénarisé : étude empirique

    Get PDF
    Le test exploratoire (TE) est défini comme l'apprentissage, la conception et l'exécution simultanés des tests, tout à fait l'opposé du test scénarisé (TS) prédéfini. L'applicabilité de cette nouvelle approche ne cesse pas d'augmenter dans l'industrie du test de logiciel. Malgré cette expansion et le succès de quelques entreprises qui s'ouvrent dans le domaine de développement du logiciel dans ses expériences d'adoption et d'utilisation de TE, les contextes et les facteurs favorables pour l'adoption de l'approche dans une méthodologie de test ne sont pas toujours bien établis. L'absence des preuves claires de sa productivité annoncée par quelques praticiens dans la littérature s'ajoute à la problématique. Ce travail est une étude exploratoire visant deux objectifs. Premièrement, étudier et analyser les contextes favorisant l'utilisation de TE comme une méthodologie primaire de test à la place des tests scénarisés en élaborant une analyse comparative entre le TE et le TS. Deuxièmement, évaluer sa productivité dans une étude empirique par rapport au TS. Nous avons élaboré un cadre conceptuel de comparaison dans lequel nous avons identifié cinq dimensions: o Les caractéristiques d'utilisation: les raisons de l'utilisation, les caractéristiques du logiciel, le type d'environnement d'affaires, les ressources financières et le temps disponible pour les tests; o Les caractéristiques de gestion: la planifIcation, le contrôle et le suivi des tests, la communication dans le projet de test et la relation avec le client; o Les caractéristiques techniques: les activités de test, l'oracle de test, les risques du logiciel et la couverture de test; o Les caractéristiques du personnel: les caractéristiques des testeurs, la culture de l'organisation; o La productivité: le nombre de défauts détectés, l'importance de défauts détectés. Ce cadre a été utilisé comme base dans l'analyse comparative du TE et du TS. Dans cette analyse, nous avons comparé une approche disciplinée de TS guidé par les patrons de documentation IEEE 829 et une approche libre, semi planifiée de TE représentée par l'approche Session Based Exploratory Testing (SBET). Dans cette comparaison, la productivité a été évaluée par le biais d'une étude empirique que nous avons mise en oeuvre, dans les laboratoires informatiques de L'UQÀM. Malgré les limites du contexte de cette étude empirique, nous avons pu dégager quelques conclusions utiles. Les résultats permettent de montrer que certains facteurs de contexte du projet de test peuvent empêcher l'utilisation de TE comme une méthode principale de test. Nous avons conclu que l'absence de contrôle de couverture de test restreint en plus le type des projets où le TE pourrait être utilisé. Aussi, l'expertise et les qualifications nécessaires pour exécuter le TE pourraient empêcher son utilisation dans les projets de tests où ces qualifications sont manquantes. Les résultats de l'étude empirique ont supporté l'hypothèse relative à l'importance des défauts détectés. D'autres recherches quantitatives sur la productivité de TE sont nécessaires, dont ce travail pourra servir comme point de départ. ______________________________________________________________________________ MOTS-CLÉS DE L’AUTEUR : Test, Test scénarisé, Test exploratoire, Session Based Exploratory Test (SBET)

    Propuesta de Métricas para Proyectos de Explotación de Información

    Get PDF
    Los Proyectos de Explotación de Información requieren de un proceso de planificación para estimar el esfuerzo, el tiempo y medir diferentes aspectos del producto para garantizar la calidad del mismo. Los procesos de desarrollo tradicionales y las métricas usuales de la Ingeniería de Software y la Ingeniería del Conocimiento no son adecuados para estos proyectos, ya que las etapas de desarrollo y los parámetros utilizados son de naturaleza y características diferentes. En ese contexto, se ha definido un Modelo de Proceso de Desarrollo para Proyectos Explotación de Información. No obstante, existe la necesidad de abordar métricas específicas aplicables a este proceso. En esta investigación se propone un conjunto de métricas aplicables al desarrollo de un proyecto de Explotación de Información para PyMEs, centrado en el Modelo de Proceso de Desarrollo mencionado

    In-process metrics for software testing

    No full text

    10 In-Process Metrics for Software Testing

    No full text
    In Chapter 9 we discussed quality management models with examples of inprocess metrics and reports. The models cover both the front-end design and coding activities and the back-end testing phases of development. The focus of the in-process data and reports, however, are geared toward the design review and code inspection data, although testing data is included. This chapter provides a more detailed discussion of the in-process metrics from the testing perspective. 1 These metrics have been used in the IBM Rochester software development laboratory for some years with continual evolution and improvement, so there is ample implementation experience with them. This is important because although there are numerous metrics for software testing, and new ones being proposed frequently, relatively few are supported by sufficient experiences of industry implementation to demonstrate their usefulness. For each metric, we discuss its purpose, data, interpretation, and use, and provide a graphic example based on real-life data. Then we discuss in-process quality management vis-à-vis these metrics and revisit the metric
    corecore