Ein-des-ein blog

רמות בדיקה ומחזור חיי QA

התהליך הבלתי ניתן לעצירה של צמיחת תעשיית ההייטק מוביל למספר הולך וגדל של משרות פנויות למהנדסי QA. האם אתה זוכר שכמה שנים назад כמה מומחים חזו נפילה כללית של תחום ה-IT בגלל רוויה יתרה במועמדים? האמת היא שהאינבוקסים שלנו בלינקדאין מוצפים בהודעות מגייסים על חיפוש אחר מקצועני QA החזקים ביותר. זה הפך לתופעה שכיחה יותר במציאות שלאחר הקורונה כאשר פתרונות אונליין חדשים צצים מדי יום כדי לפשט ולשפר את קיום האנשים ברחבי העולם. מקצועני בדיקות ה-QA שלנו בהחלט אינם יוצאים מן הכלל ומקבלים את ההודעות הללו לעיתים קרובות. אפילו הגברים האמיצים שהיו פעם בטוחים מספיק כדי לשחרר אפליקציות גולמיות ללא בדיקות סבירות מתמודדים עכשיו עם המציאות. היום בדיקות QA ממוקמות על פדסטל שכן הן נחשבות לאחת מהשלבים החשובים ביותר (אנחנו מדברים גם על שלבים אחרים) של מחזור חיי הפיתוח (המכונה גם SDLC). זה לא משנה אם החלטת להשקיע באפליקציית מסחר אלקטרוני, אפליקציית סטרימינג לאירועים, או משהו אחר (על פי המגמות המובילות באפליקציות ניידות בשנת 2021), הערכה כזו היא חיונית אם אתה מתכנן להציע לא רק תכונות תחרותיות אלא גם לזכות בפופולריות וכבוד מהלקוחות, כמו גם להעלות את הסטנדרטים של איכות ורמות שביעות רצון של משתמשים, כל אלה יובילו לצמיחה ברווחי החברה. המשימה שלנו היא להסביר בדיוק איך נראה מחזור חיי QA. למה נדרש בדיקה עבור ארגונים קטנים וענקיים כאחד, לא משנה מה הם ממציאים? מה הם רמות הבדיקה השונות? יותר מדי שאלות ואנחנו כאן כדי לענות עליהן! כאן ב- ein-des-ein אנחנו בטוחים שזה בהחלט יכול לחסוך לך מטעויות ולמנוע טעויות יקרות! במאמר זה, אספנו טיפים שיעזרו לך להבין את כל התהליך טוב יותר.

מהו STLC? איך זה שונה מ-SDLC?

מחזור חיי בדיקות תוכנה (STLC) הוא מספר שלבים המבוצעים בצורה שיטתית כדי להבטיח שהתוכנית פועלת כראוי. כל בעיית ייצור תתוקן ככל הנראה מהר יותר ובצורה חסכונית יותר (תודות לכישלונות של חברות אחרות שלומדים מהם). כדי להבין טוב יותר את המיקום של STLC בתהליך הפיתוח, חשוב להבין את ההבחנות בין מחזור חיי פיתוח תוכנה (SDLC) ומחזור חיי בדיקות תוכנה (STLC). מתחילים בקלות מערבבים בין קיצורים אלה, אבל (ספוילר!) הם שונים מאוד זה מזה. דרך rocky מההתחלה ועד יישום עובד בפועל מנוהלת על ידי SDLC: זו דרך נוחה יותר לעקוב אחרי עדכונים עבור לקוחות ומפתחים כאחד. יתרה מכך, מתווה של כל ההליך עוזר עם מועדים, הקצאות משימות, וחיזוי סיכונים (כולם רוצים שיהיו להם אסים בשרוול!).

שלבי מחזור חיי הפיתוח של תוכנה

ניתוח דרישות ותכנון

גם בעלי העניין וגם האנשים האחראיים צריכים שיהיה להם תמונה ברורה של היקף הפרויקט לעקוב אחריה. זה חיוני להבטיח שהאפליקציה תבלוט בין אחרות, שהדרישות יהיו יוצאות דופן ושכל תכונה תשפיע חיובית על חוויית המשתמש (זו הסיבה לכך שהגישה לפיתוח מונחה עיצוב היא הטובה ביותר, לדעתנו). אז הגיע הזמן לעבוד על תקציב, משאבים, לוחות זמנים כמו גם להעריך בעיות וחולשות אפשריות. בדרך כלל, מידע זה מתווסף למסמך SRS פורמלי. הוא מפותח בעיקר עבור מנהלי פרויקטים, אנליסטים עסקיים, מהנדסים.

עיצוב תוכנה

כל העניין הוא להפוך את המפרטים שהוזכרו קודם לתוכנית (המכונה מפרט עיצוב). בעלי העניין גוללים אותו ומספקים את המשוב שלהם. כל הפרטים הנדרשים לגבי ממשק משתמש, רשתות, מסדי נתונים וכו' צריכים להיות מוזכרים כאן. בשלב זה, SRS מבולגן הופך למדריך יותר לוגי ומסודר.

פיתוח תוכנה

פיתוח תוכנה מתחיל מיד. ברגע שמסמכי העיצוב מוכנים, בסופו של דבר, מתחילים לקודד את המודולים. מכיוון שכל הרכיבים כבר מיושמים, הצוות מקבל תוכנה פועלת מוכנה להערכות הראשונות שלה. ואל תשכחו לכתוב מסמך קוד מקור.

בדיקה

נבדקת הבדיקה כדי להבטיח שהקוד שנוצר אינו מכיל בעיות, עונה לחלוטין על הציפיות של הלקוח, משתלב כראוי עם תוכניות אחרות יחד עם החומרה הנבחרת (ראה את המידע המפורט על אבני הדרך של בדיקות QA למטה).

פריסה ותחזוקה

שלב זה הוא סיום התהליך הכולל כאשר המוצר כמעט מוכן לבדיקת קבלת המשתמש. צוות הפיתוח יחד עם הלקוח עוקבים מקרוב אחרי הביצועים. לאחר ההשקה, עדיף להמשיך עם תחזוקה ותמיכה. כך אם יופיעו קשיים מאוחר יותר, המפתחים יוכלו לתקן אותם במהירות וביעילות. אז, מה זה QA במעגל חיי הפיתוח ומה הקשר? כשאנחנו מתייחסים לבדיקה של QA, קשה להאמין שבשנים האחרונות לא היה תהליך SDLC קיים, ותוכניות קרסו כל 0.01 שניות היה דבר נפוץ. יתרה מכך, לפני עשור לא צפינו בתחרות שיש לנו עכשיו — משתמשים יכולים לבחור אפליקציה חדשה בשניות ולמחוק בקלות את הקודמת. אז גם ענקיות הטכנולוגיה צריכות לעקוב אחרי מגמות, ליצור תכונות יוצאות דופן וכמובן, להשיג הבטחת איכות טובה יותר. בדיקות תוכנה הפכו לרכיב עצמאי במעגל חיי הפיתוח והיו מורכבות מספיק כדי שיהיה להן מחזור חיים משלהן — STLC!

ההבדלים בין מודלים של SDLC ל-STLC

אם נדבר על ההבדלים המרכזיים בין המושגים הללו, נציין את הדברים הבאים:

אין צורך לומר, ש-STLC הוא משמעותי מאוד מסיבות רבות. קודם כל, מוצר סופי באיכות גבוהה דורש עלויות נמוכות בטווח הארוך, כך שזהו בחירה חכמה להשקיע בייצורו הנכון. יתרה מכך, יציבות התוכנה היא קריטית כך שמשתמשים קיימים תמיד יחזרו לאפליקציה שלך וימליצו עליה למשתמשים אחרים. כתוצאה מכך, ביקורות מצוינות ודיבור מפה לאוזן יכולים למשוך יותר משתמשים, מה שמוביל לצמיחה בהכנסות. כספק, אתה מקבל מוניטין טוב כך שהלקוחות הקיימים (כמו גם הפוטנציאליים) יכולים לסמוך עליך בביטחון (שוב, עכשיו אנחנו רואים את משחק התחרות החזק ביותר מתרחש!). בעוד שכל פרויקט קובע את ה-STLC שלו, לכולם תהיה אותה מבנה בדיוק.

שלבי מחזור חיי הבדיקות

ניתוח דרישות

צוות בדיקות ה-QA צריך לקבוע דרישות פונקציונליות ולא פונקציונליות למשימות מתמשכות. כאן מחלקת ה-QA צריכה להיות לה דרישות לבדיקות אוטומטיות ומנואליות גם כן. הגרסה “האידיאלית” צריכה להיות מתוארת כך שכל המומחים ייקחו אותה בחשבון במהלך כל הערכה ולא תהיה צורך להצטער על כך שפספסת משהו משמעותי. המשך אם יש לך טבלת RTM מאושרת ודוח על אפשרות האוטומציה.

תכנון בדיקות

כאן אנו מתמודדים עם כמה ניירת משעממת אך חובה, אז התכוננו. יהיו את כל הצעדים הבאים כגון:

• הכנת מסמכי תוכנית בדיקה (שכוללים את כל הנתונים המפורטים על היבטים שניתן לבדוק);
• קביעת מועדים;
• סיום בחירת כלים/פלטפורמות;
• הקצאת משימות;
• (ואל תשכחו לכלול) ניתוח סיכונים-עלויות-תועלות.

עיצוב מקרה בדיקה

אנחנו מתקרבים לחלק מחקר מעניין! אבל לפני זה, אנחנו צריכים לומר שכל מקרה מבחן מגדיר היבטים ניתנים לבדיקה, הליכים, תנאים, ומסמכים צפויים, כמו בספר בלש טוב שבו פרטי זירת הפשע נבדקים לעומק בתחילה. מקרים מבחן צריכים להיות רחבים מספיק כך שיוכלו לכסות מצבים כלליים ולוודא אילו מהם יש להם את ההשפעה הגדולה ביותר. סקריפטים אוטומטיים למקרים מבחן צריכים להיות מוכנים גם בשלב זה.

הגדרת סביבה לבדיקה

אורות, מצלמה… כמעט פעולה! במהלך שלב זה, כל הקריטריונים נחשבים כאשר גם חומרה רכה וגם חומרת בדיקה מוגדרות. הבודקים נותנים עדיפות ומקימים סביבה לבדיקה ומבצעים בדיקות עשן כדי לזהות טעויות ובאגים בסיסיים (למשל, התקנה שלא פועלת). אגב, בדיקות העשן נקראו למעשה על שם עשן תנור אמיתי! בשלב זה, כלים כמו TestComplete, Selenium, Appium וכו' שימושיים.

ביצוע בדיקות (אין באג שיכול לשרוד!)

לבסוף, לאחר כל הפעולות הקודמות, תכונות האפליקציה מוכנות להערכה. מהנדס QA משווה את התוצאות הצפויות עם התוצאות בפועל. ואם מתגלות אזורים חסרים במהלך הבדיקות, הם מתוקנים כך שניתן יהיה לבצע את בדיקות הרגרסיה (כדי לבדוק אם השינויים האחרונים לא השפיעו על תהליכים כלשהם).

סגירת מבחן

This is the QA testing stage for making sure obligatory checkups are done, preparing the documentation, and summing up processes. The final report should contain details about the whole checkup process and also show differences between planned and actual deliverables. List time constraints, costs, assessment coverage, etc. here.

רמות בדיקה בהנדסת תוכנה

עכשיו, המטרות הוגדרו, הניירת הושלמה, אז הגיע הזמן סוף סוף להגיש את המנה העיקרית— סוגים שונים של בדיקות QA! אם אנו מתכוונים לרמות בדיקה ממשיות, יש הרבה אינטראקציות קטנות, אך כולן יכולות להיות מחולקות לארבע עיקריות, הנקראות גם רמות הבדיקה בהנדסת תוכנה. לכל אחת מהן יש מטרה ייחודית משלה, ולכן אין לחסל אף רמה.

בדיקות יחידה: הבסיס הראשון במאבק נגד באגים

בדיקות יחידה (UT) הן רכיב ראשוני של בדיקה. במהלך שלב זה, כל חלק מהתוכנה מחולק לרכיבים נפרדים המוערכים בנפרד כדי להבטיח שהיחידות פועלות כראוי כרכיבים נפרדים. נבדקות מוכנות עבור כל פונקציה או שיטה שאינה טריוויאלית: זה מאפשר לך לבדוק במהירות אם שינוי קטן בקוד הוביל בסופו של דבר לרגרסיה (בעיות בחלקים שכבר נבדקים) וגם מסייע בזיהוי/הסרה של שגיאות.

בדיקות אינטגרציה: חיבור מודולים

בדיקות אינטגרציה (IT) מתבצעות כאשר השלב הראשון הושלם: מודולים משולבים/נבדקים כקבוצה — זו הסיבה שיש לו שם כזה. בדרך כלל, למוצר יש מספר מודולי תוכנה (שיכולים גם להיכתב על ידי אנשים שונים) ולכן IT חיוני כדי למצוא פגמים בממשק בין פונקציות. זה מתמקד בעיקר בממשקים ובזרימת נתונים (בין מודולים). כאן, עדיפות האימות מוקצית לשילוב קישורים – לא לחסום פונקציות שכבר אומתו. לדוגמה, יש שלושה מודולים: “דף התחברות”, “תיבת דואר” ו“מחיקת דוא"ל” (משולבים לוגית). אין צורך לבדוק את הדף הראשון כי הוא כבר בוצע בבדיקת יחידה. אבל עכשיו אנחנו יכולים להבהיר איך זה משולב עם מודול תיבת הדואר. באופן דומה, אנו מנתחים את השילוב של תיבת הדואר עם מודול “מחיקת דוא"ל”.

בדיקות מערכת: פגישה עם כל הדרישות האפשריות

לאחר חלוקת יחידות ולאחר מכן שילובן מחדש, תוכנה שלמה ומאוחדת זקוקה להערכה של התאמת המערכת לדרישות. בדרך כלל, (בעיקר עבור פרויקטים קטנים) מהנדס ה-QA בוחר בבדיקות ידניות: 

1. בודק QA פותח תוכנית 
2. לוחץ על כל הכפתורים ובודק את כל המאפיינים 
3. מאמת שהאלמנטים פועלים בהתאם. 

בדיקות מערכת יכולות גם להיות אוטומטיות! כל סוג של בדיקות מערכת מגלה:

• שימוש לא נכון במשאבי מערכת,
• קומבינציות לא צפויות של נתוני משתמש,
• חוסר תאימות עם הסביבה,
• UCs לא צפויים, וכו'.

בדיקות קבלה: הוספת נגיעות אחרונות

בדיקות קבלה (AT) הן השלב האחרון והן מתבצעות בשלב המסירה לקביעת איכות. זה בדרך כלל ברור על ידי משחק תרחישים ומקרים המבוססים על דרישות. AT מביאה להגשת הפרויקט לתיקון ולקבלתו על ידי הלקוחות. זהו היעד הסופי שבו האפליקציה נבדקת לפני שחרורה. הבדיקה מתבצעת או על ידי הלקוח עצמו או על ידי ספק שירותי IT. זו שאלה של העדפה.

STLC vs Agile, Waterfall, V-Model, and other methodologies

אם אינך חדש בקרב טכנולוגי מתקדם, סביר להניח שאתה מכיר את המתודולוגיות SD הנפוצות. אחרת, עיין בחומרים הללו לפני שתצלול להבנת איך STLC עובד בפועל בכמה שיטות פופולריות.

מודל מפל של STLC

האם אי פעם היית במפלי הניאגרה? כמו ספינת תיירים שמקבלת אותך על הסיפון רק לאחר שהספינה הקודמת עזבה, במקרה שלנו, כל שלב הבא מתחיל רק אם השלב הקודם הושלם. ישנו רק רציף אחד עבור "ספינותינו": שני שלבים לא מתבצעים במקביל! לקוראים שיכולים לתהות מדוע כל כך הרבה חברות גדולות עדיין מעדיפות את השיטה הזו, המעריצים שלה גאים לטעון שהיא מייצרת קוד, תיעוד ובדיקות איכות הרבה יותר טובות לפני שהיא נכנסת לייצור.

STLC במודל V

מודל ה-V הישן והטוב עדיין ידוע היטב בתעשייה. בארצות הברית הוא עדיין נחשב לסטנדרט הרשמי עבור פרויקטי תוכנה על ידי סוכנויות פדרליות (בין אם במסחר, צבא או במגזר הציבורי) אשר בהחלט נהנות מיישומו לסוג העסק שלהן: הסיכוי שמשהו חשוב יוחמץ הולך ומצטמצם. במקום לרדת בצורה ליניארית כמו מפל מים, המדרגות עולות לאחר שלב ההקלטה כדי ליצור צורת V ניתנת לזיהוי. המודל מציג חיבור בין כל אבן דרך של DLC ובדיקת המצב שלה. הם בלתי נפרדים ופועלים בו זמנית, אין שלב ספציפי לכך (ראה את הסכימה למטה).

STLC in Agile

רבים מהחברות (כמו גם אנחנו) מעדיפים את המתודולוגיה אג'יל בשל הגמישות שלה בכל הנוגע לשיפור מתמיד של המוצר. יתרה מכך, מתודולוגיה זו היא הפופולרית ביותר כיום: 7 מתוך 10 חברות מיישמות את הגישות שלה בשגרה היומית שלהן. QA, PM, DevOps, וכל המעורבים פועלים כמנגנון אחד, מתקשרים כל הזמן על היבטים שונים במהלך זרימת העבודה, חוזרים על המוטו “עובדים יחד כדי להשיג את המטרה העיקרית מהר יותר” כל הזמן (לא חדש לאלה שחיים עם אג'ייל כל שבוע). כולם מרוויחים מזה כי יש מקום לשינויים מיידיים. הנה דיאגרמת מחזור חיי בדיקות אג'ייל:

מחשבות סופיות 

לסכם, אפשר לומר כי לעקוב בצורה כאוטית אחרי שלבי בדיקות התוכנה עשוי לתת לך את התוצאות, אבל האמת היא שככל שהפרויקט גדול יותר, כך נדרש מערכת בדיקות QA מחמירה יותר. בסופו של דבר, למה לא לפשט את זרימת העבודה ולהפוך אותה ליעילה יותר, זולה יותר ונעימה לכולם? נסה ליישם את מערכת הבדיקות הזו בעסק שלך אם עדיין לא עשית זאת, כי זה שווה ניסיון!  

ודא לבדוק עוד מאמרים על פיתוח ועיצוב אפליקציות ניידות בבלוג שלנו!