Έλεγχος Testing Δρ. Μαρία Ι. Ανδρέου. Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 2 Περιεχόμενα Θέματα Ποιότητας Μη-Πειραματικός Έλεγχος (Non-execution-based.

Παρουσίαση με θέμα: "Έλεγχος Testing Δρ. Μαρία Ι. Ανδρέου. Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 2 Περιεχόμενα Θέματα Ποιότητας Μη-Πειραματικός Έλεγχος (Non-execution-based."— Μεταγράφημα παρουσίασης:

1 Έλεγχος Testing Δρ. Μαρία Ι. Ανδρέου

2 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 2 Περιεχόμενα Θέματα Ποιότητας Μη-Πειραματικός Έλεγχος (Non-execution-based testing) Έλεγχος βασισμένος σε πειράματα (Execution- based testing) Τι θα πρέπει να ελεγχθεί; Έλεγχος έναντι αποδείξεων ορθότητας (Testing versus correctness proofs) Ποιος πρέπει να διεξάγει έλεγχο βασισμένο σε πειράματα; Πότε τελειώνει ο έλεγχος

3 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 3 Έλεγχος Υπάρχους δυο βασικοί τύποι ελέγχου  Έλεγχος βασισμένος σε πειράματα (Execution-based testing) και  Μη-πειραματικός έλεγχος (Non-execution-based testing)

4 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 4 Έλεγχος(συνέχ.) “V & V”  Επαλήθευση (Verification) Επιβεβαίωση αν η δραστηριότητα έχει ολοκληρωθεί σωστά  Επικύρωση (Validation) Επιβεβαίωση αν το προϊόν σαν σύνολο ικανοποιεί τις προδιαγραφές του

5 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 5 Έλεγχος(συνέχ.) ΠΡΟΣΟΧΗ  Ο όρος «επαληθεύω» (“verify”) χρησιμοποιείται επίσης για όλους του ελέγχους που δεν βασίζονται σε πειράματα

6 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 6 Ποιότητα Λογισμικού Software Quality Η ποιότητα λογισμικού δεν είναι ισοδύναμο με την «Αρίστευση» (“excellence”) του Είναι ο βαθμός στον οποίο το λογισμικό ικανοποιεί τις απαιτήσεις του Κάθε επαγγελματίας που δουλεύει στην ανάπτυξη λογισμικού εξασφαλίζει ότι η δουλείας του/της είναι ορθή  Η ποιότητα πρέπει να θεμελιωθεί από την αρχή της ανάπτυξης ενός έργου

7 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 7 Επιτροπή Εγγύησης Ποιότητας Λογισμικού Software Quality Assurance (SQA) Τα μέλη της ομάδας SQA πρέπει να διασφαλίζουν (σιγουρεύουν) ότι οι κατασκευαστές κάνουν υψηλής ποιότητας δουλειά (high-quality work)  Στο τέλος κάθε δραστηριότητας  Όταν ολοκληρωθεί το προϊόν Επιπρόσθετα, η διασφάλιση ποιότητας πρέπει να εφαρμόζεται και στην  Διαδικασία ανάπτυξης λογισμικού Παράδειγμα: Standards

8 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 8 Διοικητική Ανεξαρτησία Managerial Independence Πρέπει να υπάρχει διοικητική ανεξαρτησία ανάμεσα  Στην ομάδα των κατασκευαστών και  Στην ομάδα SQA Καμία από αυτές τις δυο ομάδες δεν πρέπει να έχει εξουσία πάνω στην άλλη

9 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 9 Διοικητική Ανεξαρτησία(συνέχ.) Σε επίπεδο διοίκησης πιο υψηλού επιπέδου παίρνεται η απόφαση για το κατά πόσο  Θα γίνει παράδοση ενός προϊόντος εντός των προθεσμιών Αλλά με λάθη, ή  Θα διεξαχθούν περισσότεροι έλεγχοι και η παράδοση του προϊόντος θα γίνει με καθυστέρηση Η απόφαση λαμβάνει υπόψη της τόσο τα συμφέρονται του πελάτη, όσο και τα συμφέροντα της εταιρίας ανάπτυξης λογισμικού

10 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 10 Μη-Πειραματικός Έλεγχος Non-Execution-Based Testing Υποκείμενες αρχές (Underlying principles)  Δεν πρέπει να επανεξετάζουμε (επιθεωρούμε) την δική μας δουλεία  Σύμπραξη (συνεργασία) ομάδας

11 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 11 Walkthroughs Μια ομάδα walkthrough συνίσταται από τέσσερα έως έξι άτομα Περιλαμβάνει αντιπροσώπους από  Την ομάδα που είναι υπεύθυνη για την παρούσα δραστηριότητα  Την ομάδα που θα διεξάγει την επόμενη δραστηριότητα  Την ομάδα SQA Χρειάζεται προετοιμασία πριν την διεξαγωγή του walkthrough  Λίστα από θέματα/στοιχεία Θέματα/στοιχεία που δεν έχουν κατανοηθεί Θέματα/στοιχεία που φαίνεται να μην είναι ορθά

12 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 12 ΔιοίκησηWalkthroughs Ο πρόεδρος της ομάδας walkthrough είναι ένας εκπρόσωπος της ομάδας SQA Σε ένα walkthrough εντοπίζουμε λάθη, Δεν τα διορθώνουμε  Μια διόρθωση που θα προταθεί από την επιτροπή είναι πιθανό να είναι χαμηλής ποιότητας  Το κόστος του να προτείνει μια τέτοια επιτροπή διορθώσεις είναι υψηλό  Δεν είναι όλα τα θέματα/στοιχεία που εντοπίζονται σαν προβληματικά πραγματικά λάθη  Ένα walkthrough δεν πρέπει να διαρκεί περισσότερο από 2 ώρες  Δεν υπάρχει χρόνος σε αυτό το διάστημα για να διορθωθούν τα λάθη

13 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 13 ΔιοίκησηWalkthroughs(συνέχ.) Ένα walkthrough πρέπει να καθοδηγείται από έγγραφα (document-driven), παρά από τους συμμετέχοντες (participant) Διατυπώσεις οδηγούν σε εύρεση λαθών Ένα walkthrough δεν πρέπει ποτέ να χρησιμοποιηθεί για αξιολόγηση επόδοσης should never be used for performance appraisal

14 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 14 Επιθεωρήσεις Inspections Μια επιθεώρηση έχει πέντε κλασικά βήματα  Γενική Επισκόπηση (Overview)  Προετοιμασία, βοηθούμενη από στατιστικές διάφορων τύπων λαθών (aided by statistics of fault types)  Εξέταση (Inspection)  Διορθώσεις και συνέχεια του έργου (Rework)  Παρακολούθηση της προόδου (Follow-up)

15 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 15 Επιθεωρήσεις(συνέχ.) Η ομάδα επιθεώρησης έχει τέσσερα μέλη  Διαιτητής (Moderator)  Ένα μέλος της ομάδας εργασίας στην παρούσα δραστηριότητα  Ένα μέλος της ομάδας που θα διεξάγει την επόμενη δραστηριότητα  Ένα μέλος της ομάδας SQA Ιδικοί ρόλοι παίζονται από τους  Διαιτητή (Moderator)  Αναγνώστης (Reader)  Εγγραφέα (Recorder)

16 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 16 Στατιστικές για Λάθη Fault Statistics Τα λάθη καταγράφονται με βάση την σοβαρότητα τους (Faults are recorded by severity)  Παραδείγματα: Μείζονος σημασίας (σημαντικά, major), ή Ελάσσονος σημασίας (μικρά –minor) Τα λάθη καταγράφονται με βάση τον τύπο τους (Faults are recorded by fault type)  Παραδείγματα λαθών σχεδιασμού: Δεν έχουν καταγραφεί όλες οι προδιαγραφές Τα πραγματικά και τα δομικά επιχειρήματα δεν συμφωνούν

17 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 17 Στατιστικές για Λάθη (συνέχ.) Για μια δεδομένη δραστηριότητα, συγκρίνουμε τον αναλογία (ποσοστό) λαθών με εκείνες των προηγούμενων έργων Λαμβάνουμε μέτρα αν δεν είναι ανάλογος ο αριθμός λαθών σε ένα συστατικό μέρος (artifact)  Το να το ξανασχεδιάσουμε (ή υλοποιήσουμε) από την αρχή είναι μια καλή εναλλακτική λύση Μετατοπίζουμε την προσπάθεια εύρεση λαθών στην επόμενη δραστηριότητα  Ίσως να μην τα καταφέραμε να εντοπίσουμε όλα τα λάθη στην παρούσα επιθεώρηση

18 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 18 Στατιστικές στις επιθεωρήσεις (Statistics on Inspections) Σε επιθεωρήσεις στην IBM εντοπίστηκαν  82% όλων των λαθών που εντοπίστηκαν συνολικά (1976)  70% όλων των λαθών που εντοπίστηκαν συνολικά(1978)  93% όλων των λαθών που εντοπίστηκαν συνολικά(1986) Switching system  ελάττωσε κατά 90% κόστος από τον εντοπισμό λαθών (1986) JPL  4 σημαντικά λάθη, 14 μικρά λάθη σε 2 ώρες (1990)  Εξοικονόμηση $25,000 από κάθε επιθεώρηση  Ο αριιθμός των λαθών ελαττώνεται εκθετικά σε κάθε φάση (1992)

19 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 19 Στατιστικές στις επιθεωρήσεις(συνέχ.) Προσοχή Οι στατιστικές για σφάλματα δεν πρέπει ποτέ να χρησιμοποιηθούν για αξιολόγηση απόδοσης  “Killing the goose that lays the golden eggs”

20 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 20 Σύγκριση Inspections and Walkthroughs Επιθεωρήσεις  Ανεπίσημη διαδικασία δύο βημάτων Προετοιμασίας Ανάλυσης Walkthrough  Τυπική διαδικασία πέντε βημάτων Γενική Επισκόπηση Προετοιμασία Εξέταση Διορθώσεις Παρακολούθηση προόδου

21 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 21 Πλεονεκτήματα και Μειονεκτήματα των Αξιολογήσεων Strengths and Weaknesses of Reviews Οι αξιολογήσεις μπορεί να είναι αποδοτικές/αποτελεσματικές  Τα λάθη μπορούν να εντοπιστούν νωρίς στην διαδικασία ανάπτυξης λογισμικού Οι αξιολογήσεις είναι λιγότερο αποτελεσματικές όταν η διαδικασίας είναι ανεπαρκής (μη ικανοποιητική)  Λογισμικά μεγάλης κλίμακας (Large-scale software) πρέπει να αποτελούνται από μικρότερα αρκετά ανεξάρτητα κομμάτια  Τα έγγραφα της προηγούμενης δραστηριότητας πρέπει να είναι ολοκληρωμένα και διαθέσιμα online

22 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 22 Μετρικές για Επιθεωρήσεις Metrics for Inspections Ρυθμός επιθεώρησης (Inspection rate) π.χ., ο αριθμός σελίδων σε ένα έγγραφο σχεδιασμού που εξετάζονται κάθε ώρα. Πυκνότητα λαθών (Fault density), π.χ. αριθμός λαθών σε χίλιες γραμμές κώδικα (KLOC) που εξετάστηκαν Ρυθμός ανίχνευσης λαθών (Fault detection rate) π.χ., ο αριθμός λαθών που εντοπίζονται κάθε ώρα Αποδοτικότητα στην ανίχνευση λαθών (Fault detection efficiency) π.χ., ο αριθμός των σημαντικών και των μικρότερης σημασίας λαθών που εντοπίστηκαν κάθε ώρα

23 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 23 Μετρικές για Επιθεωρήσεις(συνέχ.) Αύξηση κατά 50% στον ποσοστό ανίχνευσης λαθών μήπως σημαίνει ότι:  Η ποιότητα έχει μειωθεί; ή ότι  Η διαδικασία επιθεώρησης είναι πιο αποδοτική; ή κάτι άλλο;

24 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 24 Έλεγχος βασισμένος σε πειράματα Execution-Based Testing Εταιρίες ξοδεύουν μέχρι και 50% του προϋπολογισμού σε έλεγχο  Και όμως τα προϊόντα λογισμικού που παραδίνονται είναι πολλές φορές αναξιόπιστα Dijkstra (1972)  “Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence”

25 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 25 Τι πρέπει να ελεγχθεί ; What Should Be Tested? Ορισμός: “Ο έλεγχος που βασίζεται σε πειράματα είναι η διαδικασία εξαγωγής συμπερασμάτων στο κατά πόσο το προϊόν έχει συγκεκριμένες ιδιότητες, εν μέρη, αυτά προκύπτουν από την διεξαγωγή πειραμάτων στο προϊόν, σε ένα γνωστό περιβάλλον με κάποιες επιλεγμένες εισόδους.” Αυτός ο ορισμός είναι προβληματικός! Γιατί;

26 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 26 Τι πρέπει να ελεγχθεί ;(συνέχ.) “Συμπέρασμα”  Έχουμε μια αναφορά λαθών, το source code, και συχνά τίποτα άλλο. Πως μπορούμε από αυτά να εξάξουμε σωστά και ολοκληρωμένα συμπεράσματα; “Γνωστό περιβάλλον”  Ποτέ δεν μπορούμε να ξέρουμε με ακρίβεια το περιβάλλον. “Επιλεγμένες είσοδοι”  Μερικές φορές δεν μπορούμε να παρέχουμε/δημιουργήσουμε τις εισόδους που θέλουμε  Χρειάζονται προσημειώσεις (Simulation)

27 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 27 Τι πρέπει να ελεγχθεί ;(συνέχ.) Χρειάζεται να ελέγξουμε την ορθότητα και επίσης:  Χρησιμότητα/ωφελιμότητα (Utility)  Αξιοπιστία (Reliability)  Ευρωστία (Robustness), και  Απόδοση (Performance)

28 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 28 Χρησιμότητα / Ωφελιμότητα Utility Ο βαθμός στον οποίο το προϊόν ικανοποιεί τις απαιτήσεις του πελάτη  Παραδείγματα: Ευκολία στη χρήση Λειτουργικό Οικονομικό

29 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 29 Αξιοπιστία Reliability Ένα μέτρο της συχνότητας και της σημαντικότητας αποτυχιών  Μέσος χρόνος ανάμεσα σε αποτυχίας  Μέσος χρόνος διόρθωσης  Χρόνος (και κόστος) για διόρθωση μιας αποτυχίας

30 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 30 Ευρωστία Robustness Η ευρωστία είναι συνάρτηση των πιο κάτω:  Τη γκάμα των λειτουργικών μερών του λογισμικού.  Την πιθανότητα λήψης μη-αποδεκτού αποτελέσματος δεδομένης έγκυρης εισόδου.  Την επίπτωση/αποτέλεσμα που θα προκύψει από λανθασμένη (μη-έγκυρη) είσοδο.

31 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 31 Απόδοση Performance Ο βαθμός στον οποίο ικανοποιούνται περιορισμοί (απαιτήσεις) για το παραγόμενο λογισμικό αναφορικά με χρόνο (π.χ. χρόνο απόκρισης ή χρόνο διεκπεραίωσης) και χώρο (μνήμη που χρειάζεται για να μπορεί να εκτελεστεί). Λογισμικά Πραγματικού-χρόνου (Real-time) χαρακτηρίζονται από αυστηρούς χρονικούς περιορισμούς (hard real-time constraints) Σε περίπτωση που χαθούν δεδομένα, λόγω του ότι το σύστημα είναι αργό, τότε  Δεν υπάρχει τρόπος αυτά να ανακτηθούν

32 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 32 Ορθότητα Correctness Ένα προϊόν είναι ΟΡΡΘΟ όταν ικανοποιεί τις προδιαγραφές του.

33 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 33 Ορθότητα Προδιαγραφών Correctness of specifications Λανθασμένες προδιαγραφές για ταξινόμηση : Παράδειγμα: η Function trickSort η οποία ικανοποιεί τις πιο πάνω προδιαγραφές :

34 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 34 Ορθότητα Προδιαγραφών(συνέχ.) Λανθασμένες προδιαγραφές για ταξινόμηση: ΟΡΘΕΣ προδιαγραφές για ταξινόμηση:

35 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 35 Ορθότητα (συνέχ.) Τεχνικά η ορθότητα ΔΕΝ είναι μια ικανή και αναγκαία συνθήκη για ένα προϊόν λογισμικού

36 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 36 Πειράματα έναντι Αποδείξεων Ορθότητας Testing versus Correctness Proofs Οι αποδείξεις ορθότητας είναι ένας άλλος εναλλακτικός τρόπος (σε σχέση με τα πειράματα) για να ελέγξουμε αν ένα προϊόν λογισμικού ικανοποιεί τις απαιτήσεις του.

37 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 37 Παράδειγμα απόδειξης ορθότητας Έστω το πιο κάτω κομμάτι κώδικα που θέλουμε να ελέγξουμε αν είναι ορθό.

38 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 38 Παράδειγμα απόδειξης ορθότητας(συνέχ.,) Το flowchart που αντιστοιχεί στο κομμάτι κώδικα της προηγούμενης διαφάνειας

39 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 39 Παράδειγμα απόδειξης ορθότητας(συνέχ.) Add  Input specification  Output specification  Loop invariant  Assertions (See next slide)

40 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 40 Παράδειγμα απόδειξης ορθότητας(συνέχ.)

41 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 41 Correctness Proof Mini Case Study Dijkstra (1972):  “The programmer should let the program proof and program grow hand in hand” “Naur text-processing problem” (1969)

42 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 42 Naur Text-Processing Problem Given a text consisting of words separated by a blank or by newline characters, convert it to line-by- line form in accordance with the following rules: Line breaks must be made only where the given text contains a blank or newline ; Each line is filled as far as possible, as long as No line will contain more than maxpos characters

43 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 43 Episode 1 Naur constructed a 25-line procedure He informally proved its correctness

44 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 44 Episode 2 1970 — Reviewer in Computing Reviews  The first word of the first line is preceded by a blank unless the first word is exactly maxpos characters long

45 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 45 Episode 3 1971 — London finds 3 more faults Including:  The procedure does not terminate unless a word longer than maxpos characters is encountered

46 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 46 Episode 4 1975 — Goodenough and Gerhart find three further faults Including:  The last word will not be output unless it is followed by a blank or newline

47 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 47 Correctness Proof Mini Case Study (contd) Lesson: Even if a product has been proved correct, it must STILL be tested.

48 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 48 6.5.3 Correctness Proofs and Software Engineering Three myths of correctness proving (see over)

49 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 49 Software engineers do not have enough mathematics for proofs  Most computer science majors either know or can learn the mathematics needed for proofs Proving is too expensive to be practical  Economic viability is determined from cost–benefit analysis Proving is too hard  Many nontrivial products have been successfully proved  Tools like theorem provers can assist us Three Myths of Correctness Proving

50 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 50 Can we trust a theorem prover ? Difficulties with Correctness Proving Figure 6.7

51 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 51 How do we find input–output specifications, loop invariants? What if the specifications are wrong? We can never be sure that specifications or a verification system are correct Difficulties with Correctness Proving (contd)

52 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 52 Correctness Proofs and Software Engineering (contd) Correctness proofs are a vital software engineering tool, where appropriate:  When human lives are at stake  When indicated by cost–benefit analysis  When the risk of not proving is too great Also, informal proofs can improve the quality of the product  Use the assert statement

53 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 53 Ποιος Πρέπει να διεξάγει τον Πειραματικό Έλεγχο; Who Should Perform Execution-Based Testing? Ο προγραμματισμός είναι μια εποικοδομητική/παραγωγική/προοδευτική διαδικασία (constructive) Ο έλεγχος δεν είναι καταστρεπτική διαδικασία (destructive)  Ένας επιτυχής έλεγχος βρίσκει ΛΑΘΗ Συνεπώς, ΔΕΝ πρέπει οι προγραμματιστές μα γράφουν και να ελέγχουν το δικό τους κώδικα.  Το ίδιο ισχύει για κάθε συστατικό μέρος του λογισμικού. Όχι μόνο για το κώδικα

54 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 54 Ποιος Πρέπει να διεξάγει τον Πειραματικό Έλεγχο; (συνέχ.) Λύση:  Οι προγραμματιστές διεξάγουν ανεπίσημο έλεγχο του κώδικα τους  Η ομάδα SQA διεξάγει συστηματικό και επίσημο έλεγχο  Οι προγραμματιστές διορθώνουν τα λάθη που εντοπίστηκαν Όλοι οι έλεγχοι πρέπει να  Σχεδιαστούν από πριν και να γνωρίζουμε και τα αποτελέσματα τα οποία αναμένονται, Για να μπορεί να επιβεβαιωθεί αν είναι σωστά τα αποτελέσματα που προκύπτουν από το λογισμικό μας  Διατηρούνται και στη συνέχεια (Retained afterwards)

55 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 55 Πότε Σταματά ο έλεγχος; Μόνο όταν το προϊόν αποσυρθεί οριστικά