Μενού

Πώς εμπλέκονται οι υπεύθυνοι δοκιμών στις τεχνικές TDD, BDD & ATDD

how testers are involved tdd

Δοκιμάστε Το Όργανο Μας Για Την Εξάλειψη Των Προβλημάτων

Επισκόπηση των τεχνικών TDD, BDD και ATDD:

TDD, BDD & ATDD είναι οι όροι που έχουν φέρει επανάσταση στον κόσμο των δοκιμαστών στο Agile και έχουν κερδίσει επίσης ορμή. Αλλαγή στη νοοτροπία των ελεγκτών απαιτεί επίσης την εκμάθηση νέων δεξιοτήτων και το πιο σημαντικό, αλλαγή της στάσης και του τρόπου εργασίας.

Σε αντίθεση με την απομόνωση, οι υπεύθυνοι δοκιμών πρέπει να συνεργαστούν και να συνεργαστούν με τους προγραμματιστές

  • Κοινή χρήση των δοκιμαστικών περιπτώσεων
  • Συμμετοχή στο γράψιμο των κριτηρίων αποδοχής των ιστοριών
  • Παροχή συνεχών σχολίων στους ενδιαφερόμενους
  • Συνεργασία για την έγκαιρη επίλυση των ελαττωμάτων.
  • Δώστε προτάσεις και πληροφορίες για τη βελτίωση της ποιότητας των παραδοτέων
  • Αυτοματοποίηση

Οι δοκιμαστές συμμετέχουν στο Agile

Προτού ξεκινήσω τη συζήτηση σχετικά με τη συμμετοχή ενός δοκιμαστή σε αυτές τις πρακτικές, ας προσπαθήσουμε πρώτα να κατανοήσουμε τις έννοιες πίσω από αυτούς τους όρους:

Τι θα μάθετε:

Δοκιμαστική ανάπτυξη

Εξετάστε την παραδοσιακή προσέγγιση της ανάπτυξης λογισμικού όπου ο κώδικας γράφεται πρώτα και μετά δοκιμάζεται. Η δοκιμαστική ανάπτυξη ή το TDD είναι μια προσέγγιση που είναι η ακριβής ΑΝΤΙΣΤΡΟΦΗ της παραδοσιακής ανάπτυξης. Σε αυτήν την προσέγγιση, οι δοκιμές γίνονται πρώτα και στη συνέχεια γράφεται ο κώδικας.

Ταραγμένος?!!

Πώς μπορούμε να δοκιμάσουμε ένα λογισμικό που δεν έχει ακόμη αναπτυχθεί;

Ναί!! Αυτή είναι μια δοκιμαστική εξέλιξη ή TDD.

Το TDD λειτουργεί σε μικρές αυξήσεις όπου:

  • Το τεστ γράφεται πρώτα
  • Η δοκιμή εκτελείται - η οποία θα αποτύχει (για προφανείς λόγους)
  • Ο κωδικός είναι γραμμένος (ή refactored) μόνο για να περάσει η δοκιμαστική θήκη
  • Η δοκιμή εκτελείται ξανά
  • Εάν η δοκιμή περάσει, προχωρήστε στην επόμενη δοκιμή ELSE ξαναγράψτε / τροποποιήστε τον κωδικό για να κάνετε την δοκιμαστική επιτυχία

Επιτρέψτε μου να το εξηγήσω μέσω ενός διαγράμματος ροής:

Διάγραμμα ροής TDD

Τώρα, πρέπει να καταλάβουμε το γεγονός ότι το TDD δεν μιλά για τις δοκιμές που κάνουν οι δοκιμαστές. Αντίθετα, αυτή η προσέγγιση μιλάει για τις δοκιμές που κάνουν οι προγραμματιστές.

Ναί!! Το μαντέψατε σωστά !! Είναι η δοκιμή μονάδας.

Το τεστ που γράφεται πρώτα δεν είναι το τεστ που γράφουν οι δοκιμαστές, αλλά είναι το τεστ μονάδας που γράφουν οι προγραμματιστές. Έτσι, θα επαναδιατυπώσω τα βήματα ως:

  • Το τεστ UNIT γράφεται πρώτα
  • Εκτελείται η δοκιμή UNIT - η οποία θα αποτύχει (για προφανείς λόγους)
  • Ο κωδικός είναι γραμμένος (ή refactored) μόνο για να περάσει το τεστ
  • Η δοκιμή UNIT εκτελείται ξανά
  • Εάν η δοκιμή περάσει, προχωρήστε στην επόμενη δοκιμή ELSE ξαναγράψτε / τροποποιήστε τον κωδικό για να κάνετε την δοκιμαστική επιτυχία

Τώρα, το ερώτημα που προκύπτει εδώ είναι - εάν το TDD είναι δουλειά προγραμματιστή, ποιος είναι ο ρόλος του δοκιμαστή σε αυτήν την προσέγγιση;

Λοιπόν, έχοντας πει ότι το TDD είναι δουλειά του προγραμματιστή, αυτό δεν σημαίνει ότι οι υπεύθυνοι δοκιμών δεν εμπλέκονται σε αυτό. Οι υπεύθυνοι δοκιμών μπορούν να συνεργαστούν κοινοποιώντας τα σενάρια δοκιμής που αποτελούνται από:

  • Οριακή τιμή θήκες
  • Μάθημα ισοδυναμίας δοκιμές
  • Κρίσιμες επιχειρηματικές περιπτώσεις
  • Περιπτώσεις λειτουργικότητας επιρρεπείς σε σφάλματα
  • Εξασφάλιση επιπέδων

Αυτό που θέλω να πω είναι - οι υπεύθυνοι δοκιμών πρέπει να συμμετέχουν στον καθορισμό των σεναρίων δοκιμής μονάδας και να συνεργάζονται με τους προγραμματιστές για να εφαρμόσουν το ίδιο. Οι υπεύθυνοι δοκιμών πρέπει να παρέχουν τα σχόλιά τους σχετικά με τα αποτελέσματα των δοκιμών.

Εάν θέλουμε να εφαρμόσουμε το TDD, οι υπεύθυνοι δοκιμών πρέπει να αναβαθμίσουν τα σετ δεξιοτήτων τους. Πρέπει να είναι πιο τεχνικοί και να επικεντρώνονται στη βελτίωση των αναλυτικών και λογικών δεξιοτήτων τους.

Οι δοκιμαστές θα πρέπει επίσης να καταβάλουν προσπάθεια να κατανοήσουν την τεχνική ορολογία που χρησιμοποιούν οι προγραμματιστές και, εάν είναι δυνατόν, πρέπει να έχουν μια πανοραμική θέα του κώδικα. Με παρόμοιο τρόπο, οι προγραμματιστές πρέπει να μπουν στα παπούτσια του δοκιμαστή και να προσπαθήσουν να βρουν πιο εξελιγμένα σενάρια που θα κάνουν τη μονάδα δοκιμή πιο στιβαρή και σταθερή.

Τόσο οι προγραμματιστές όσο και οι υπεύθυνοι δοκιμών πρέπει να πατήσουν ο ένας στον άλλον παπούτσια, σε αντίθεση με την παλιά παραδοσιακή προσέγγιση όπου οι προγραμματιστές δεν έδωσαν πολύ βάρος στις δοκιμές μονάδας επειδή βασίστηκαν στους δοκιμαστές για την εύρεση σφαλμάτων και ελαττωμάτων και οι δοκιμαστές δεν ήθελαν να επιδοθούν να μάθουν τα τεχνικά πράγματα επειδή πιστεύουν ότι η δουλειά τους τελειώνει μετά την εύρεση των ελαττωμάτων.

Ανάπτυξη βάσει συμπεριφοράς

Το Behavior Driven Development ή το BDD είναι μια επέκταση του Test Driven Development.

Το BDD, όπως υποδηλώνει το όνομα, απεικονίζει τις μεθόδους ανάπτυξης ενός χαρακτηριστικού βάσει της συμπεριφοράς του. Η συμπεριφορά εξηγείται βασικά με παραδείγματα σε μια πολύ απλή γλώσσα που μπορεί να γίνει κατανοητή από όλους στην ομάδα που είναι υπεύθυνη για την ανάπτυξη.

Μερικά από τα βασικά χαρακτηριστικά του BDD είναι τα εξής:

  • Η γλώσσα που χρησιμοποιείται για τον καθορισμό της συμπεριφοράς είναι πολύ απλή και σε μία μορφή στην οποία μπορεί να γίνει κατανοητή από όλους - τόσο τεχνικά όσο και μη τεχνικά άτομα που συμμετέχουν στην εφαρμογή
  • Δίνει μια πλατφόρμα που επιτρέπει στα τρία amigos (προγραμματιστής, tester και PO / BA) να συνεργάζονται και να κατανοούν την απαίτηση. Καθορίζει ένα κοινό πρότυπο για την τεκμηρίωσή του
  • Αυτή η τεχνική / προσέγγιση συζητά την τελική συμπεριφορά του συστήματος ή πώς πρέπει να συμπεριφέρεται το σύστημα και ΔΕΝ μιλά για το πώς πρέπει να σχεδιαστεί ή να εφαρμοστεί το σύστημα
  • Τονίζει και τις δύο πτυχές της ποιότητας:
    • Πληροίτε την απαίτηση
    • Κατάλληλο για χρήση

Γιατί BDD;

Λοιπόν, γνωρίζουμε ότι η διόρθωση ενός ελαττώματος / έντομο στο μεταγενέστερο στάδιο οποιουδήποτε κύκλου ανάπτυξης είναι αρκετά δαπανηρό. Η διόρθωση των ελαττωμάτων παραγωγής δεν επηρεάζει μόνο τον κώδικα αλλά και το σχεδιασμό και τις απαιτήσεις του. Όταν κάνουμε το RCA (Ανάλυση αιτίας ρίζας) οποιουδήποτε ελαττώματος, τις περισσότερες φορές, καταλήγουμε στο συμπέρασμα ότι το ελάττωμα ουσιαστικά οφείλεται σε παρανόητες απαιτήσεις.

Αυτό συμβαίνει ουσιαστικά επειδή όλοι έχουν διαφορετικές ικανότητες να κατανοήσουν τις απαιτήσεις. Ως εκ τούτου, τεχνικά και μη τεχνικά άτομα μπορεί να ερμηνεύουν την ίδια απαίτηση διαφορετικά, κάτι που μπορεί να οδηγήσει σε ελαττωματική παράδοση. Επομένως, είναι ζωτικής σημασίας όλοι οι άνθρωποι στην ομάδα ανάπτυξης να κατανοήσουν την ΙΔΙΟΤΗΤΑ απαίτηση και να την ερμηνεύσουν με τον ίδιο τρόπο.

Πρέπει να διασφαλίσουμε ότι όλες οι αναπτυξιακές προσπάθειες κατευθύνονται και επικεντρώνονται στην ικανοποίηση των απαιτήσεων. Προκειμένου να αποφευχθεί οποιοδήποτε είδος ελαττώματος 'απαίτηση - απώλεια', ολόκληρη η ομάδα ανάπτυξης πρέπει να τα ευθυγραμμίσει για να κατανοήσει την απαίτηση που είναι κατάλληλη για χρήση.

Η προσέγγιση BDD επιτρέπει στην ομάδα ανάπτυξης να το κάνει: -

  • Ορισμός μιας τυπικής προσέγγισης για τον ορισμό της απαίτησης στα απλά αγγλικά
  • Παροχή οριστικών παραδειγμάτων που εξηγούν τις απαιτήσεις
  • Παρέχετε μια διεπαφή / πλατφόρμα που επιτρέπει στους τεχνικούς (προγραμματιστές / δοκιμαστές) και μη τεχνικούς (PO / BA / Customer) να συνεργάζονται και να ενώνονται και να βρίσκονται στην ίδια σελίδα για να κατανοήσουν και να εφαρμόσουν τις απαιτήσεις

Πώς να εφαρμόσετε το BDD;

Υπάρχουν πολλά διαθέσιμα εργαλεία στην αγορά για την εφαρμογή της BDD. Ονομάζω μερικά εδώ:

  • Αγγούρι
  • Καταλληλότητα
  • Συμφωνία
  • JBehave
  • Ροή προδιαγραφών

Παράδειγμα:

Ας προσπαθήσουμε να κατανοήσουμε το BDD με ένα παράδειγμα. Για την περίπτωσή μου, χρησιμοποιώ το αγγούρι (αγγούρι):

Εξετάστε μια απλή περίπτωση όπου θέλουμε να επιτρέψουμε μόνο σε πιστοποιημένους χρήστες να εισέλθουν στον ιστότοπο XYZ.

Το αρχείο Gherkin (αρχείο χαρακτηριστικών) θα έχει ως εξής:

Χαρακτηριστικό: Πύλη εγγραφής δοκιμής

Περίγραμμα σεναρίου: Έγινε είσοδος έγκυρου χρήστη

Δεδομένος: Ο πελάτης ανοίγει την πύλη εγγραφής

Πότε: ο χρήστης εισάγει το όνομα χρήστη ως '' και τον κωδικό πρόσβασης ως ''

Επειτα: ο πελάτης θα πρέπει να μπορεί να δει τη φόρμα.

Παραδείγματα :

| χρήστης | κωδικός πρόσβασης |

| χρήστης1 | pwd1 |

| χρήστης2 | pwd2 |

Μπορούμε να δούμε πώς μια συγκεκριμένη απαίτηση τεκμηριώνεται χρησιμοποιώντας απλά αγγλικά. Τα τρία amigos μπορούν να συνεργαστούν για το σχεδιασμό των αρχείων χαρακτηριστικών και συγκεκριμένα δεδομένα δοκιμής μπορούν να τεκμηριωθούν στην ενότητα παραδείγματος. Το BDD παρέχει ένα μέσο για να φέρει προγραμματιστές, υπεύθυνους δοκιμών και επιχειρήσεις σε ένα τραπέζι και να καθιερώσει μια κοινή κατανόηση των δυνατοτήτων που θα εφαρμοστούν.

Η προσέγγιση BDD εξοικονομεί προσπάθεια και κόστος και ελέγχει εάν υπάρχουν ελαττώματα μετά την ανάπτυξη της παραγωγής, καθώς η συνεργασία των πελατών και των προγραμματιστών ήταν καθ 'όλη τη διάρκεια του κύκλου ανάπτυξης της δυνατότητας.

Οι ομάδες ανάπτυξης μπορούν να χρησιμοποιήσουν αυτά τα αρχεία χαρακτηριστικών και να τα μετατρέψουν σε εκτελέσιμα προγράμματα για να δοκιμάσουν ένα συγκεκριμένο χαρακτηριστικό.

Πως?

Λοιπόν, πρέπει να μάθετε Αγγούρι / Fitnesse για αυτό !!

Ανάπτυξη βάσει δοκιμής αποδοχής

Το Acceptance Test Driven Development ή το ATDD είναι μια τεχνική όπου ολόκληρη η ομάδα συνεργάζεται για να καθορίσει τα κριτήρια αποδοχής ενός επικού / ιστορίας πριν αρχίσει πραγματικά η εφαρμογή. Αυτά τα τεστ αποδοχής υποστηρίζονται από κατάλληλα παραδείγματα και άλλες απαραίτητες πληροφορίες.

Τις περισσότερες φορές, τα BDD και ATDD χρησιμοποιούνται εναλλακτικά. Η προσέγγιση ATDD μπορεί επίσης να εφαρμοστεί χρησιμοποιώντας τη μορφή Given-When-Then, ακριβώς όπως γράφουμε χαρακτηριστικά στην προσέγγιση BDD.

Ας προσπαθήσουμε γρήγορα να συνοψίσουμε τις διαφορές μεταξύ των 3 προσεγγίσεων:

  • Το TDD είναι πιο τεχνικό και είναι γραμμένο στην ίδια γλώσσα στην οποία εφαρμόζεται η δυνατότητα. Εάν η δυνατότητα υλοποιηθεί σε Java, γράφουμε JUnit δοκιμές . Ενώ το BDD & ATDD είναι γραμμένο σε απλή αγγλική γλώσσα
  • Η προσέγγιση TDD επικεντρώνεται στην εφαρμογή ενός χαρακτηριστικού. Ενώ το BDD επικεντρώνεται στη συμπεριφορά του χαρακτηριστικού και το ATDD επικεντρώνεται στη λήψη των απαιτήσεων
  • Για να εφαρμόσουμε το TDD πρέπει να έχουμε τεχνικές γνώσεις. Ενώ οι BDD & ATDD δεν απαιτούν τεχνικές γνώσεις. Η ομορφιά του BDD / ATDD έγκειται στο γεγονός ότι τόσο τεχνικοί όσο και μη τεχνικοί άνθρωποι μπορούν να συμμετάσχουν στην ανάπτυξη της δυνατότητας
  • Δεδομένου ότι το TDD έχει εξελιχθεί, δίνει περιθώρια για καλό σχεδιασμό και επικεντρώνεται στην πτυχή της ποιότητας «Απαίτηση συνάντησης». λαμβάνοντας υπόψη ότι το BDD / ATDD επικεντρώνεται στο 2αρπτυχή της ποιότητας που είναι 'Κατάλληλο για χρήση'

Όλες αυτές οι τεχνικές βασικά μιλούν για την προσέγγιση «δοκιμή-πρώτη», σε αντίθεση με την προσέγγιση «δοκιμή-τελευταία» που χρησιμοποιείται στις παραδοσιακές μεθοδολογίες ανάπτυξης.

Καθώς τα τεστ γράφονται πρώτα, οι δοκιμαστές παίζουν πολύ σημαντικό ρόλο. Όχι μόνο οι υπεύθυνοι δοκιμών πρέπει να έχουν έναν τεράστιο τομέα και επιχειρηματικές γνώσεις, αλλά πρέπει επίσης να διαθέτουν καλές τεχνικές δεξιότητες, ώστε να μπορούν να προσθέσουν αξία στην ανταλλαγή ιδεών κατά τη διάρκεια των συζητήσεων των 3 amigos.

Με τις έννοιες όπως το CI (Continuous Integration) και το CD (Continuous Delivery), οι υπεύθυνοι δοκιμών πρέπει να συνεργαστούν καλά με τους προγραμματιστές και να συνεισφέρουν εξίσου στον τομέα ανάπτυξης και λειτουργίας.

αριστερή εσωτερική ένωση έναντι αριστερή εξωτερική ένωση

Επιτρέψτε μου να συνοψίσω αυτήν τη συζήτηση με τη διάσημη δοκιμαστική πυραμίδα στο Agile:

Δοκιμάστε την πυραμίδα στο Agile

Το χαμηλότερο στρώμα αυτής της πυραμίδας αποτελείται από το στρώμα δοκιμής μονάδας. Αυτό το στρώμα είναι το επίπεδο θεμελίωσης. Επομένως, είναι αυτοκρατορικό ότι αυτό το στρώμα είναι στερεό. Οι περισσότερες από τις δοκιμές πρέπει να προωθηθούν σε αυτό το στρώμα. Αυτό το χαμηλότερο επίπεδο εστιάζει μόνο στο TDD.

Στο Ευκίνητος κόσμο, δίνεται έμφαση στο να καταστεί αυτό το στρώμα της πυραμίδας πιο ισχυρό και ανθεκτικό και τονίζεται ότι οι περισσότερες δοκιμές επιτυγχάνονται σε αυτό το στρώμα.

Τα εργαλεία που χρησιμοποιούνται σε αυτό το στρώμα μιας πυραμίδας είναι όλα τα εργαλεία Xunit.

Το μεσαίο στρώμα της πυραμίδας είναι το επίπεδο υπηρεσίας, εξηγώντας τις δοκιμές επιπέδου υπηρεσίας. Αυτό το επίπεδο λειτουργεί ως γέφυρα μεταξύ της διεπαφής χρήστη της εφαρμογής και της μονάδας / στοιχείου χαμηλότερου επιπέδου. Αυτό το επίπεδο αποτελείται κυρίως από τα API που δέχονται αιτήματα από το περιβάλλον εργασίας χρήστη και αποστέλλουν την απάντηση. Η προσέγγιση BDD και TTDD είναι ενεργή σε αυτό το στρώμα της πυραμίδας.

Τα εργαλεία που χρησιμοποιούνται στο μεσαίο στρώμα της πυραμίδας είναι - Fitnesse, Cucumber και Robot Framework .

Το ανώτατο στρώμα της πυραμίδας είναι το πραγματικό περιβάλλον χρήστη, το οποίο δείχνει ότι αυτό το στρώμα θα πρέπει να περιέχει τον μικρότερο αριθμό δοκιμών ή θα έπρεπε να πω ότι η προσπάθεια δοκιμής σε αυτό το συγκεκριμένο στρώμα πρέπει να είναι ελάχιστη. Οι περισσότερες από τις δοκιμές του χαρακτηριστικού θα έπρεπε να είχαν ολοκληρωθεί όταν φτάσουμε στο ανώτερο επίπεδο της πυραμίδας.

Τα εργαλεία που χρησιμοποιούνται στο πάνω επίπεδο είναι - Σελήνιο , QTP και RFT.

Δεδομένου ότι εργαζόμαστε σε μικρές αυξήσεις στο Scrum (ονομάζεται Sprints), η χειροκίνητη εφαρμογή όλων αυτών των προσεγγίσεων δεν είναι εφικτή. Αυτές οι προσεγγίσεις απαιτούν αυτοματοποιημένη παρέμβαση. Η αυτοματοποίηση, σε αυτήν την περίπτωση, είναι πολύ κρίσιμη.

Στην πραγματικότητα, αυτές οι προσεγγίσεις εκτελούνται στην πραγματικότητα μέσω αυτοματισμού. Στο τέλος κάθε σπριντ, προστίθενται νέες δυνατότητες, οπότε καθίσταται σημαντικό το λειτουργικό χαρακτηριστικό που έχει εφαρμοστεί προηγουμένως να λειτουργεί όπως αναμένεται. ως εκ τούτου, Αυτοματοποίηση γίνεται το HERO εδώ.

συμπέρασμα

Μέχρι το τέλος του άρθρου, πρέπει να έχετε μάθει πώς εμπλέκονται οι Τεστ στις τεχνικές TDD, BDD & ATDD.

Στο τρίτο μέρος της σειράς, θα επικεντρώσω τη συζήτησή μου στον αυτοματισμό σε έναν ευέλικτο κόσμο.

Σχετικά με τον Συγγραφέα: Αυτό το άρθρο είναι του συγγραφέα STH Shilpa. Εργάζεται στον τομέα δοκιμών λογισμικού τα τελευταία 10+ χρόνια σε τομείς όπως η διαφήμιση μέσω Διαδικτύου, η Investment Banking και η Telecom.

Συνεχίστε να παρακολουθείτε αυτόν τον χώρο για πολύ περισσότερες ενημερώσεις.

Συνιστώμενη ανάγνωση

^