Quality Assurance should not only depend on technical skills, tools, and methodologies. Integrating Domain Knowledge in the process can help the team deliver products of high quality by building a better understanding of the business.
3. 3
What is Domain Knowledge?
A broad-based understanding of a particular industry
and facts about the environment in which the system
(under test) operates
It may include user workflows, data pipelines, business
policies, configurations and constraints and is crucial in
the development of a software application
4. 4
What is Domain Knowledge?
For an EU FinTech company:
• Bancontact is the most popular electronic payment service in Belgium
• Carte Bancaire is the payment standard in France
For an airline:
• Data about the flight routes covered by an airline is domain knowledge
• Search algorithms used to locate the cheapest entry is not
6. - Low adoption rates compared to other Asian nations
- Problem with “Last Name” field during signup
- “Why wouldn’t you enter a last name?”
- About 40% of the population don’t have a last name
- Most of the users stop at this point
- Fixing that bug unlocked a market of 262m users
Case Study: The Indonesian Last Name
6
In fast-growing organizations, simple things often get overlooked
A tester’s knowledge of local constraints and user workflow saved the day
[7]
7. 7
Testing Skills Technical Expertise
The Hidden Power behind Quality Assurance
Domain Knowledge
images from www.pokemon.com
3D testing career mentioned by Danny R. Fought
based on Rex Black’s book Critical Testing Processes
The factor that can unlock full potential
A point of reference in the organization
9. 9
How to build Domain Knowledge
- Study documentation (specs, standards, guidelines etc)
- Learn about variations in business rules and regulations
- Analyze previous projects
- Observe the competition
- Think like the customer
- Work closer with the BAs and Subject Matter Experts
- Use and share your own experience
- Attend Industry Events
- Search for courses and certifications
- Build, update and share a Knowledge Base
10. - Better understanding of company’s vision
- Everyone speaks the same language
- It puts your team in the user's shoes
- It boosts the productivity of your team
- It tells the team where to look for defects
- It helps teams prioritize bugs
10
Advantages for your QA Team
And one disadvantage
- Relatively useless outside the domain
11. 11
Every QA Engineer should cultivate this Hidden Power
Organizations should promote Domain Knowledge sharing between teams
Domain Expertise will increase the confidence in the product quality
A QA Engineer without domain knowledge gets the job done
A QA Engineer with domain knowledge gets the job done faster and better
QA Engineer with Domain Knowledge
Conclusion
QA Engineer without Domain Knowledge
12. 12
Thank You!
You can find me at
linkedin.com/in/kostaskaramichalis
kostas.karamichalis@gmail.com
Σήμερα θα σας παρουσιάσω πόσο σημαντικό θεωρώ το Domain Knowledge στη διαδικασία του Quality Assurance και πως ένας μηχανικός που κατέχει αυτή την «Κρυμμένη Δύναμη» μπορεί να εξελιχθεί σε ένα πολύ σημαντικό μέλος μιας ομάδας και να αποτελέσει σημείο αναφοράς σε ολόκληρο τον οργανισμό. Στην παρουσίαση μου έχω χρησιμοποιήσει αναφορές από διάφορα βιβλία και άρθρα, μαζί φυσικά με κάποια παραδείγματα από την προσωπική μου εμπειρία αλλά και τη δική μου οπτική πάνω στο θέμα.
Ας ξεκινήσουμε με κάτι που λίγο πολύ οι περισσότεροι μέσα σε αυτή την αίθουσα γνωρίζουμε. Ένα από τα 7 Testing Principles αναφέρει ότι : Το Testing είναι Context Dependent, τι σημαίνει όμως αυτό πρακτικά; Σημαίνει ότι τα ειδικά χαρακτηριστικά και οι ιδιότητες του Business domain του software under test καθορίζουν κατά πολύ το γενικότερο QA strategy. Με άλλα λόγια μας λέει ότι το testing απαιτεί μεταξύ άλλων και Domain Expertise, άρα και Domain Knowledge.
Τι είναι όμως Domain Knowledge?
Κατ’ αρχήν, δεν υπάρχει ξεκάθαρος ορισμός, μιας και πρόκειται για κάτι σχετικά broad και abstract.
DK λοιπόν είναι η ευρεία κατανόηση ενός συγκεκριμένου industry και κάποια δεδομένα σχετικά με το περιβάλλον στο οποίο λειτουργεί το σύστημα (under test στην περίπτώσή μας)
Μπορεί να περιλαμβάνει user workflows, data pipelines, business policies, configurations και constraints και είναι ΑΠΑΡΑΙΤΗΤΗ για το development του Software Application.
Για παράδειγμα, δεδομένα σχετικά με τα δρομολόγια μιας αεροπορικής εταιρίας είναι Domain Knowledge ενώ ο search algorithm για την εύρεση της φθήνότερης πτήσης είναι καθαρά technical knowledge.
Η για μια fintech εταιρία που δραστηριοποιείται στην Ευρωπαική Ένωση, το να γνωρίζει ότι
Πριν προχωρήσουμε με περισσότερη θεωρία σχετικά με το domain knowledge, ας δούμε μερικά παραδείγματα σχετικά ΜΕ ΤΟ ΠΟΣΟ ΣΗΜΑΝΤΙΚΟ ΕΊΝΑΙ ΤΟ DOMAIN KNOWLEDGE ΣΤΟ QA
Στο πρώτο παράδειγμα, θα εξετάσουμε ένα issue που βρήκαμε στο Spotify, τη δημοφιλέστερη πλατφόρμα Music Streaming στον κόσμο.
ΕΔΏ ΔΕΝ ΠΡΟΣΠΑΘΟΥΜΕ ΝΑ ΒΡΟΥΜΕ ΤΟ RC ΑΛΛΑ ΝΑ ΚΑΝΟΥΜΕ POINT TO ISSUE ΩΣ QA ENGINEERS ME DOMAIN KNOWLEDGE
Στην περίπτωση των the Prodigy λοιπόν, με περισσότερα από 2,5 εκ ακροατές το μήνα, παρατηρείται το εξής
Υπάρχει ένα feature που λέγεται “Appears On’, όπου κάποιος μπορεί να δει συμμετοχές του καλλιτέχνη σε δίσκους άλλων καλλιτεχνών ή συλλογές.
Βλέποντας λοιπόν το συγκεκριμένο feature στο προφιλ των Prodigy, κάποιος που ενδεχομένως να γνωρίζει κάποια πράγματα για αυτόυς, ότι μερικά από αυτά τα εξώφυλλα δεν φαίνονται για Prodigy
Πράγματι, σε όλα αυτά τα άλμπουμ δε συμμετέχουν ΟΙ Prodigy αλλά Ο rapper Prodigy, μέλος του hip-hop συγκροτήματος Mobb Deep.
Το Root Cause μπορεί να μην οφείλεται στο ίδιο το Spotify, αλλά στους distributors, σε αυτούς δηλαδή που αναλαμβάνουν να ανεβάσουν τη μουσική στην πλατφόρμα εκ μέρους του καλλιτέχνη
Πάμε τώρα σε ένα άλλο case που εδώ ένας QA Engineer έδωσε τη λύση σε ένα πολύ σημαντικό πρόβλημα.
Το case αυτό το βρήκα στο βιβλίο Leading Quality, των Cummings και Peer το οποίο σας προτείνω να διαβάσετε.
Εδώ λοιπόν, κατά τη διάρκεια του λανσαρίσματος ενός νέου application το οποίο έγινε ταυτόχρονα σε όλο τον κόσμο, παρατηρήθηκε ότι η Ινδονησία είχε πολύ χαμηλό adoption rate σε σχέση με τις υπόλοιπες ασιατικές χώρες.
Μετά από μια πρώτη ανάλυση, προέκυψε ότι το πρόβλημα ήταν ότι η πλειοψηφία των χρηστών δεν έβαζαν το επώνυμό τους το οποίο ήταν υποχρεωτικό κατά το registration.
Η εταιρία προσέλαβε ένα QA consulting agency το οποίο διέθετε resources και στην Ινδονησία για να βοηθήσει με το συγκεκριμένο issue.
Ένας Ινδονήσιος QA Engineer βρήκε πολύ εύκολα το root cause.
H βασική ερώτηση ήταν λοιπόν, «γιατί δεν βάζει κάποιος το επώνυμό του;»
Η απάντηση; Περίπου 40% των Ινδονησίων δεν έχουν επώνυμο!
Μερικοί χρήστες έβαζαν κάτι, ένα χαρακτήρα, μια παύλα, αλλά οι περισσότεροι σταματούσαν σε αυτό το σημείο.
Όταν διορθώθηκε αυτό το bug, άνοιξε μια αγορά 262εκ χρηστών.
Χρειάστηκε λοιπόν ένας local tester για να αναδείξει κάτι, το οποίο σε έναν Ινδονήσιο είναι προφανές.
Θα ρωτήσει κάποιος, πως ξέφυγε κάτι τέτοιο κατά την ανάλυση των requirements; Η απάντηση είναι ότι στο σύγχρονο software industry, τα απλά πράγματα πολλές φορές τα θεωρούμε δεδομένα και τα παραλείπουμε.
Και φυσικά, ένας QA Engineer που γνώριζε local constraints, και το user worlflow, που όπως είδαμε στην αρχή είναι domain knowledge, έδωσε τη λύση.
Τα προηγούμενα παραδείγματα μας έδειξαν πόσο σημαντικό είναι το Domain Knowledge σε όλο το Quality Assurance Process .
Πάμε λοιπόν να δούμε πως αυτή η κρυφή δύναμη μπορεί να αποτελέσει πολύ σημαντικό παράγοντα για την καριέρα ενός QA Engineer
Σύμφωνα με το μοντέλο 3D Testing Career του Danny Fought, το οποίο βασίζεται στο βιβλίο του Rex Black Critical Testing Processes, ένας καλός tester πρέπει να έχει:
- Πολύ καλά Testing Skills. Αυτό είναι το θεμέλιο μιας επιτυχημένης καριέρας στο SW Testing and Quality Assurance. Πρέπει να γνωρίζει τα processes, τους διαφορετικούς τύπους testing και πρέπει να μπορεί να κάνει drive όλα τα testing activities.
Πρέπει να έχει technical expertise. Να μπορεί να παρακολουθεί τις τρέχουσες τεχνολογίες, να μαθαίνει καινούρια πράγματα και να συνεισφέρει σε test automation activities.
Τι είναι όμως αυτό που κάνει έναν καλό QA engineer, exceptional? Σωστά μαντέψατε. Ένας exceptional QAE πρέπει να κατέχει την Κρυφή Δύναμη του domain knowledge, να είναι ένα point of reference όταν μιλάμε για domain specific πληροφορία και να αποπνέει σιγουριά ότι το product quality είναι domain –proof.
και πως αυτή η Κρυφή Δύναμη, ένας όρος που δανείστηκα από τα Pokemon btw, μπορεί όταν χρησιμοποιηθεί σωστά να ξεκλειδώσει το full potential ενός QA Engineer και να τον κάνει σημείο αναφοράς στον οργανισμό, βοηθώντας φυσικά πέρα από τον ίδιο τον οργανισμό και την καριέρα του.
Kι ενώ το QA Function γίνεται όλο και πιο σημαντικό στο software industry σήμερα, η ανάγκη για Domain Expert Software Testers αυξάνεται. Αυτή την ανάγκη έρχεται να καλύψει το ISTQB, το μεγαλύτερο ίσως testing certification provider στον κόσμο, ο οποίος ήδη έχει δημιουργήσει certifications όπως
- Gambling Industry Tester
Automotive Software Tester
Mobile Application Tester
Όπως γνωρίζετε και όπως φαίνεται και από αυτά που έχουμε πει έως τώρα, η Domain Knowledge δεν είναι κάτι που μαθαίνεται, αλλά είναι κάτι που χτίζεται σιγά σιγά. Πως μπορεί όμως ένας οργανισμός, μια ομάδα ή ένας individual να χτίσει domain knowledge?
Aς δούμε γιατί ένας οργανισμός πρέπει να ενισχύσει το Domain Knowledge των Quality Assurance teams του
Ας δούμε μερικά πλεονεκτήματα:
Όλοι μιλάνε την ίδια γλώσσα οπότε ο QA Engineer είναι σε θέση να αξιολογήσει καλύτερα το impact ενός defect στο προϊόν.
Όπως είπαμε και προηγουμένως, είναι πολύ σημαντικό να μπορέσει ο QA E να δει το προϊόν με τα μάτια του χρήστη.
Πέρα από το προφανές, δηλαδή να βρει ένα bug, ένας QA E με καλό domain knowledge, μπορεί ακόμα να εντοπίσει που ακριβώς χρειάζεται αλλαγή έτσι ώστε να βοηθήσει τους developers να κερδίσουν χρόνο.
Είναι πολύ πιο εύκολο για έναν QAE με Domain Expertise να γνωρίζει τις περιοχές στις οποίες είναι πιο πιθανό να βρεθούν bugs.
Και φυσικά αυτή η γνώση μπορεί να βοηθήσει τον QAE να καταλάβει αμέσως το severity του bug και να το κάνει prioritize
Φυσικά υπάρχουν και κάποια μειονεκτήματα
Αν και μπορεί να υπάρχουν κοινά σημεία μεταξύ domains, η domain specific knowledge είναι σχετικά αχρείαστη έξω από το domain
Έτσι, κάποιος QAE που αλλάζει συχνά domains, θα χρειαστεί να μάθει πολλά domain specific πράγματα σε όλη την καριέρα του, χάνοντας χρόνο που θα μπορούσε να επενδύσει κάπου αλλού
Καταλήγοντας, με βάση αυτά που συζητήσαμε έως τώρα:
Ο κάθε QΑΕ είναι υπεύθυνος να καλλιεργήσει αυτή την κρυφή δύναμη
Οι ομάδες θα πρέπει να χρησιμοποιούν την individual γνώση για να δημιουργήσουν Domain Knowledge Bases
Ο κάθε οργανισμός θα πρέπει με κάποιο τρόπο να κάνει αυτή τη γνώση διαθέσιμη μεταξύ των ομάδων, έτσι ώστε όλοι να επωφελούνται.
Και τελικά το QA Domain Expertise να ενισχύσει την ποιότητα του τελικού προϊόντος
Και κλείνοντας, ας δούμε έναν QA Engineer χωρίς Domain Knowledge
Και ένας με Domain Knowledge