Δοκιμές παλινδρόμησης SAP: αναβαθμίσεις, εκδόσεις και εύρος

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

Οι αφορμές είναι τα transports, οι αναβαθμίσεις και οι εκδόσεις στο cloud. Στο SAP Cloud ERP public edition, τις ημερομηνίες αναβάθμισης τις ορίζει η SAP, οπότε η σουίτα παλινδρόμησης πρέπει να είναι έτοιμη πριν φτάσει η έκδοση.

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

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

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

Ισχύει σε όλη τη ζωή του συστήματος, όχι μόνο κατά τη διάρκεια ενός προγράμματος:

1. Transports. Κάθε αλλαγή που μεταφέρεται από την ανάπτυξη στο σύστημα ποιότητας είναι κίνδυνος παλινδρόμησης για τις διαδικασίες που αγγίζει.
2. Support packages και feature packs. Οι διορθώσεις και οι νέες λειτουργίες της SAP αλλάζουν τυποποιημένο κώδικα κάτω από την παραμετροποίησή σας.
3. Αναβαθμίσεις έκδοσης. Η μετάβαση σε νέα έκδοση, ή μια έκδοση cloud που δεν προγραμματίσατε εσείς, αλλάζει πολύ περισσότερα ταυτόχρονα.
4. Μετατροπές. Μια μετατροπή από ECC σε S/4HANA κρατά την παραμετροποίηση και τον προσαρμοσμένο κώδικά σας, οπότε ό,τι κρατήσατε πρέπει να ξαναδοκιμαστεί. Ο οδηγός μου για τη μετάπτωση από ECC σε S/4HANA εξηγεί πού μπαίνει αυτό στο σχέδιο.
5. Ενοποιήσεις και επεκτάσεις. Μια αλλαγή σε ένα συνδεδεμένο σύστημα ή σε μια side-by-side επέκταση μπορεί να χαλάσει την πλευρά του SAP χωρίς κανένα transport στο SAP.

Κρατήστε τη σουίτα παλινδρόμησης χωριστά από τις δοκιμές που γράφονται για νέες λειτουργίες. Η σουίτα είναι μια σταθερή βιβλιοθήκη των διαδικασιών που η επιχείρηση δεν αντέχει να χάσει, όπως το order to cash, το procure to pay και το κλείσιμο μήνα.

Στο on-premise, επιλέγετε εσείς πότε θα αναβαθμίσετε. Στις εκδόσεις cloud, η SAP ορίζει μεγαλύτερο μέρος του χρονοδιαγράμματος, και οι δοκιμές παλινδρόμησης γίνονται επαναλαμβανόμενη δέσμευση στο ημερολόγιο.

Public edition: δύο αναβαθμίσεις τον χρόνο

Το SAP Cloud ERP public edition, παλαιότερα S/4HANA Cloud Public Edition, δέχεται δύο μεγάλες αναβαθμίσεις τον χρόνο, τον Φεβρουάριο και τον Αύγουστο. Μικρότερες παραδόσεις λειτουργιών έρχονται ανάμεσά τους.

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

Το μάθημα Cloud ALM της SAP για τις δοκιμές μετά την αναβάθμιση και την παλινδρόμηση συνιστά να δημιουργήσετε ένα σχέδιο δοκιμών παλινδρόμησης στο Cloud ALM και να το επαναχρησιμοποιείτε σε κάθε έκδοση. Το public edition περιλαμβάνει επίσης ένα δωρεάν εργαλείο αυτοματοποίησης δοκιμών με προπαραδομένα test scripts, ώστε οι τυποποιημένες διαδικασίες να έχουν ένα σημείο εκκίνησης.

Private edition: κύκλος εκδόσεων δύο ετών

Το SAP Cloud ERP Private, το private edition που πωλείται μέσω του RISE with SAP, ακολουθεί τον κύκλο εκδόσεων του on-premise. Σύμφωνα με το SAP Learning, μια νέα βασική έκδοση κυκλοφορεί κάθε δύο χρόνια, τα feature pack stacks ακολουθούν κάθε έξι μήνες και κάθε έκδοση έχει επτά χρόνια κύριας συντήρησης.

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

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

Ο πίνακας βάζει δίπλα δίπλα τις αφορμές για παλινδρόμηση:

Αλλαγή	Πόσο συχνά	Ποιος ορίζει την ημερομηνία	Τι πρέπει να καλύψει η εκτέλεση παλινδρόμησης
Transport στο σύστημα ποιότητας	Καθημερινά ή εβδομαδιαία	Η ομάδα σας	Τις διαδικασίες που αγγίζουν τα αλλαγμένα αντικείμενα
Αναβάθμιση public edition	Δύο φορές τον χρόνο, Φεβρουάριο και Αύγουστο	Η SAP	Κάθε διαδικασία εντός εύρους, πρώτα η προσαρμοσμένη λογική, στο παράθυρο πριν από την παραγωγή
Feature pack stack στο private edition	Κάθε έξι μήνες, αν το εγκαταστήσετε	Εσείς, μέσα στο χρονοδιάγραμμα της SAP	Τις αλλαγμένες τυποποιημένες λειτουργίες που χρησιμοποιείτε, μαζί με τον προσαρμοσμένο κώδικα
Αναβάθμιση έκδοσης στο private edition	Τουλάχιστον κάθε επτά χρόνια, έως μία τον χρόνο κατόπιν αιτήματος στο RISE	Εσείς, μαζί με τη SAP	Πλήρη σουίτα, προσαρμοσμένο κώδικα και ενοποιήσεις
Μετατροπή από ECC σε S/4HANA	Μία φορά	Εσείς	Ό,τι κρατήσατε

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

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

Αυτά είναι τα εργαλεία που θα συναντήσετε:

1. SAP Solution Manager. Ο Business Process Change Analyzer, μέρος του Test Suite, δείχνει ποιες επιχειρηματικές διαδικασίες επηρεάζει μια αλλαγή. Ο Scope and Effort Analyzer εκτιμά την επίπτωση ενός support package ή enhancement package πριν το εγκαταστήσετε, και η SAP τον χαρακτηρίζει εργαλείο σχεδιασμού.
2. SAP Cloud ALM. Το Cloud ALM διαχειρίζεται σχέδια δοκιμών παλινδρόμησης, εκτέλεση και σφάλματα, και συνδέεται με εργαλεία αυτοματοποίησης. Για τις αναβαθμίσεις του public edition, το εργαλείο Release Assessment and Scope Dependency της SAP δείχνει ποιες αλλαγές μιας έκδοσης επηρεάζουν το εύρος σας.
3. Tricentis LiveCompare. Σύμφωνα με την τεκμηρίωση του LiveCompare, εντοπίζει ένα ελάχιστο σύνολο αντικειμένων με τον μεγαλύτερο κίνδυνο προς δοκιμή και έπειτα αναφέρει test hits και test gaps σε σχέση με το αποθετήριο δοκιμών σας. Η SAP το μεταπωλεί ως SAP Change Impact Analysis by Tricentis, και ενοποιείται με το Tricentis Tosca.
4. Panaya. Το προϊόν της Panaya για αναβαθμίσεις SAP συνδυάζει ανάλυση επιπτώσεων αλλαγών, διόρθωση κώδικα, διαχείριση δοκιμών και αυτοματοποίηση, και καλύπτει εκδόσεις S/4HANA, feature pack stacks και support package stacks.

Ελέγξτε πού βρίσκεται το Solution Manager σας πριν χτίσετε πάνω του. Η SAP Support αναφέρει ότι η κύρια συντήρηση του Solution Manager 7.2 λήγει στο τέλος του 2027. Οι πελάτες που επιλέγουν εκτεταμένη συντήρηση για το Business Suite 7 τη διατηρούν έως το τέλος του 2030, και η SAP συνιστά μετάβαση στο Cloud ALM πριν από το τέλος του 2027.

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

Η σύγκρισή μου για τα εργαλεία δοκιμών και επικύρωσης SAP εξηγεί πώς ταιριάζουν μεταξύ τους αυτά τα προϊόντα και τι περιλαμβάνει ήδη το συμβόλαιο υποστήριξης SAP σας.

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

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

Ένας πελάτης public edition που εκτελεί ολόκληρη τη σουίτα δύο φορές τον χρόνο, συν τα transports στο ενδιάμεσο, φτάνει γρήγορα αυτό το όριο. Ένα μικρό σύστημα private edition που αλλάζει λίγες φορές τον χρόνο μπορεί να μην το φτάνει.

Κάντε αυτές τις ερωτήσεις πριν αγοράσετε:

1. Πόσες περιπτώσεις δοκιμών παλινδρόμησης έχετε, και πόσες από αυτές εκτελούνται σε κάθε κύκλο;
2. Πόσο συχνά τις εκτελείτε, μετρώντας transports, feature packs και αναβαθμίσεις, όχι μόνο αναβαθμίσεις έκδοσης;
3. Πόσο διαρκεί μια χειροκίνητη εκτέλεση, και χωράει μέσα στο παράθυρο παλινδρόμησης;
4. Ποιος θα συντηρεί τα scripts όταν αλλάζουν οθόνες και διαδικασίες;

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

Σε προγράμματα που έχω οδηγήσει, οι ομάδες μου έχουν χρησιμοποιήσει Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager και UiPath. Επιλέξτε με βάση το πόσο ταιριάζει το εργαλείο με τα συστήματα και την ομάδα σας, όχι με βάση το demo. Ο οδηγός μου για την αυτοματοποίηση δοκιμών SAP εξηγεί από πού να ξεκινήσετε και πώς να κρίνετε την απόσβεση.

Το δυσκολότερο πρόβλημα παλινδρόμησης σε ένα πρόγραμμα SAP δεν είναι τα εργαλεία. Είναι δύο ροές αλλαγών που περνούν ταυτόχρονα από τα ίδια συστήματα.

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

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

Περιβάλλον έργουΠεριβάλλον BAU

Τι περνά από αυτόΠεριβάλλον έργουΝέες λειτουργίες, παραμετροποίηση και προσαρμοσμένος κώδικας για το πρόγραμμαΠεριβάλλον BAUΔιορθώσεις και μικρές αλλαγές στο παραγωγικό σύστημα

Εστίαση παλινδρόμησηςΠεριβάλλον έργουΟι διαδικασίες που αλλάζει το πρόγραμμα, μαζί με τη βασική σουίταΠεριβάλλον BAUΟι διαδικασίες που αγγίζει κάθε διόρθωση, μαζί με τη βασική σουίτα

Περνά στην παραγωγήΠεριβάλλον έργουΣτο go-live ή σε ένα κύμα εκδόσεωνΠεριβάλλον BAUΩς εκδόσεις υποστήριξης, με το συνηθισμένο πρόγραμμα

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

Σχεδιάστε το από την αρχή:

1. Περάστε αναδρομικά (retrofit) κάθε αλλαγή της BAU στο περιβάλλον του έργου με σταθερό ρυθμό, και παρακολουθήστε την καθεμία.
2. Επαναλάβετε τις επηρεαζόμενες δοκιμές του έργου μετά από κάθε retrofit, όχι μόνο στο τέλος.
3. Παγώστε τις αλλαγές της BAU καθώς πλησιάζει η μετάβαση, εκτός από επείγουσες διορθώσεις που περνούν και από τα δύο περιβάλλοντα.
4. Εκτελέστε ολόκληρη τη σουίτα παλινδρόμησης στο περιβάλλον του έργου πριν από το go-live, με δεδομένα σε επίπεδο παραγωγής και με απόκρυψη.

Το δεύτερο περιβάλλον κοστίζει χρήματα, αλλά το ίδιο κοστίζει και ένα go-live όπου κανείς δεν μπορεί να πει ποια αλλαγή χάλασε την τιμολόγηση. Η στρατηγική δοκιμών S/4HANA που περιγράφω δείχνει πού μπαίνουν οι κύκλοι παλινδρόμησης δίπλα στις δοκιμές ολοκλήρωσης και αποδοχής χρηστών.

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

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

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

Τι είναι οι δοκιμές παλινδρόμησης SAP;

Επαναλαμβάνουν δοκιμές σε επιχειρηματικές διαδικασίες SAP που δεν προοριζόταν να αλλάξουν, για να αποδείξουν ότι ένα transport, ένα support package, μια αναβάθμιση ή μια νέα έκδοση δεν τις χάλασε. Καλύπτουν ολοκληρωμένες ροές όπως το order to cash και το κλείσιμο μήνα, όχι μόνο τα αντικείμενα που άλλαξαν.

Πόσο συχνά χρειάζεται δοκιμές παλινδρόμησης το SAP Cloud ERP public edition;

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

Ποιος κάνει τις δοκιμές παλινδρόμησης σε μια αναβάθμιση RISE with SAP private edition;

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

Ποια εργαλεία βοηθούν να οριστεί το εύρος των δοκιμών παλινδρόμησης SAP;

Τα εργαλεία ανάλυσης επιπτώσεων συγκρίνουν τι άλλαξε με ό,τι χρησιμοποιείτε. Συνήθεις επιλογές είναι ο Business Process Change Analyzer και ο Scope and Effort Analyzer στο SAP Solution Manager, και το εργαλείο Release Assessment and Scope Dependency για το public edition. Το Tricentis LiveCompare και η Panaya κάνουν την ίδια δουλειά, ενώ το SAP Cloud ALM διαχειρίζεται τα σχέδια δοκιμών παλινδρόμησης και την εκτέλεση.

Πρέπει οι δοκιμές παλινδρόμησης SAP να αυτοματοποιούνται;

Αυτοματοποιήστε όταν υπάρχει μεγάλος αριθμός περιπτώσεων δοκιμών που χρειάζονται εκτενείς, επαναλαμβανόμενες δοκιμές. Κάτω από αυτό, οι χειροκίνητες δοκιμές αρκούν. Μετρήστε τις περιπτώσεις δοκιμών σας και πόσο συχνά εκτελούνται πριν αγοράσετε ένα εργαλείο, και προϋπολογίστε τη συντήρηση των scripts.

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

Λειτουργήστε δύο χωριστά περιβάλλοντα, ένα για το έργο και ένα για την τρέχουσα λειτουργία. Έτσι οι αλλαγές της υποστήριξης και οι αλλαγές του έργου δοκιμάζονται χωριστά. Περάστε αναδρομικά κάθε διόρθωση της BAU στο περιβάλλον του έργου και επαναλάβετε τις επηρεαζόμενες δοκιμές.