LOGIN
התחברות או הרשמה
Avatar
להמשך הרשמה ידנית – לחץ על כפתור ההרשמה, להרשמה/כניסה מהירה בעזרת חשבון רשת חברתית – לחץ על הלוגו בכותרת

אפס סיסמה - שכחתי את שם המשתמש

שם משתמש
סיסמה
זכור אותי

he icon   en icon

david

david

שבת, 28 פברואר 2015 19:10

בודקי תוכנה – מגמות לעתיד

בודקי תוכנה – מגמות לעתיד

הקדמה

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

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

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

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

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

הכישורים שבודקי תוכנה צריכים בכדי לעבוד בתחום (תוך התחשבות במגמות עתידיות בתעשיית התוכנה).

מדוע תחום הבדיקות חווה את התעצמותו בשנים האחרונות?

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

סיבה ראשונה  - נגישות וצורך :

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

בנוסף, הפלטפורמות שתומכות באותן טכנולוגיות רק הולכות וגדלות, דוגמאות קלאסיות :

מחשבים.

טלפונים.

טאבלטים.

מכוניות.

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

סיבה שנייה - הכרה בחשיבותו של תחום הבדיקות :

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

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

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

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

סיבה שלישית – פיתוח קריירה :

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

אז האם קריירה של בודק יכולה לענות על ביקושים אלו...? כמובן שכן! הסיבות לכך הם רבות :

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

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

הביקוש לבודקים רק עולים וגדלים ככל שהזמן עובר, מה שמאפשר לבודקים איכותיים להתבלט ולהשיג עבודות איכותיות ומאתגרות יותר.

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

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

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

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

סיבה רביעית – בודקי תוכנה הם המשפיעים ביותר בתהליך ה-SDLC:

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

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

אז למה בודקי תוכנה כ"כ חשובים בתהליך ה-SDLC ?

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

בודקי תוכנה הם אלו שאחראים לכך שהלקוח מקבל מוצר בטוח ופשוט לשימוש.

בודקי תוכנה הם אלו שאחראים לבניית הביטחון של התוכנה בהקשר של איכות וצורת השימוש.

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

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

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

הכישורים הנדרשים מבודקי תוכנה

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

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

סקירת המאפיינים

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

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

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

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

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

דוגמה פשוטה שתמחיש את הנושא:

מורכבות שמגיעה מסוגי הפלטפורמות הנתמכות:

מורכבות שמגיעה מסוגי הטכנולוגיות הנתמכות:

מורכבות שמגיעה מסוגי מערכות ההפעלה הנתמכות:

Web based application.

Client-Server based Server application.

Mobile based application.

Cloud based application

Software that supports wireless technology.

Software that support different types of storages (Isilon, NTAP-CM...).

Software that support different types Networking (LAN, WAN, Bluetooth...).

Microsoft Servers (2003 /2008 / 2012...)

Unix Server (Fedora, Red-hot...).

Mobile OS (WinOS, Android...)

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

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

פירוק והרכבה – אחת מהמטרות העיקריות שלנו כבודקים היא כמובן "שבירת" התוכנה, לטעמי בודק שמבין את הדרך שבה התוכנה בנויה ,יוכל כמובן לראות את נקודות החולשה ומכאן פעולת ה-"שבירה" תהיה קלה הרבה יותר.

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

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

יכולת לבצע בדיקות לכל אורך חיי התוכנה (SDLC)

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

בנוסף, עובדה בסיסית ומוכחת שכול בודק מתחיל חייב לדעת:

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

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

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

בדיקות דינמיות – כל הבדיקות שקשורות לשימוש בתוכנה עצמה(בדיקות פונקציונליות , ממשק משתמש , ביצועים ועוד) .

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

שליטה בכל המדיומים הקשורים לתוכנה

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

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

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

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

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

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

סיכום

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

בתודה מראש,

דוד צמח

רביעי, 30 אוקטובר 2013 20:50

מאמר בנושא של בדיקות קבלה

בדיקות קבלה

בדיקות קבלה (Acceptance Testing Plan)  הם בדיקות אשר מבוצעות בסביבת הלקוח שבו הלקוח בודק האם התוכנה עונה על דרישותיו, כל תוכנה שמפותחת עוברת מספר שלבים לפני שהיא מגיעה ללקוח הסופי ,לאחר ביצוע השלב האחרון במחזור הבדיקה שבו צוות הבודקים מאשר אותה והאפליקציה עברה בדיקות Beta האפליקציה הופכת רשמית ולכזו שיכולה להימכר ללקוחות החברה.

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

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

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

אז מה צריך בשביל ATP  איכותי ?

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

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

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

דוגמה פשוטה לדרישות מינימום לשרת שישמש להרצת תוכנה של אנטי ווירוס(Server Side) :

  • השרת חייב להיות עם מערכת הפעלה מסוג Server 2012.
  • שרת עם 10 מעבדים  ו- 6  גיגה זיכרון.
  • חומת אש מבוטלת.
  • התקנה חייבת להתבצע באמצעות Power User.
  • תקשורת של השרת עם שאר המחשבים בדומיין(חיבור Clients).
  • גישה לאינטרנט(להורדת עדכונים).
  • השרת חייב לכלול .NET 4.5

בעיות ידועות(Known Issues) – לעיתים יכולות להיות לנו הגבלות מסוימות שימנעו מאיתנו להשתמש בתוכנה או שיפגמו בחווית המשתמש, הגבלות אלו ידועות מראש ולכן יש חובה לדווח עלים ללקוח שיידע האם הגבלות אלו רלוונטיות לסביבה הארגונית ומה זה אומר מבחינת חווית השימוש.

בהמשך לדוגמה הקודמת, הבעיות הידועות :

  • התוכנה לא תרוץ על שרתי UNIX.
  • התוכנה לא רלוונטית לעבודה ב – WORKGROUP .
  • יש בעיות עדכונים במידה ויש יותר מ- 1000 משתמשים.

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

סוגיות שונות במסמכי קבלה

ניגוד אינטרסים

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

החוזה עם הלקוח

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

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

זמני הבדיקות ובדיקות נוספות שאינן בתכנון

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

 

למאמרים נוספים ניתן להיכנס לבלוג האישי שלי בכתובת :

www.dtvisiontech.com

ראשון, 20 אוקטובר 2013 19:53

בדיקות אוטומציה

בדיקות אוטומציה

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

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

יש לזכור שבודק התוכנה יבצע מספר רב של סוגי בדיקות ידניות (GUI , Usability , Performance and more..) אשר יעזרו לו למצוא באגים במערכת (זאת במסגרת שלבי הבדיקה  (Sanity , Regression …)) חלק מהבדיקות יהיו רלוונטיות לאוטומציה וחלקן לא, הטבלה הבאה תראה מספר דוגמאות אשר יעזרו לכם לקבוע מתי להעזר באוטומציה ומתי עדיף להישאר בתחום הבדיקות הידניות.

מקרי בדיקה למימוש אוטומטי

מקרי בדיקה  למימוש ידני

בדיקות שחוזרות על עצמן מספר רב של פעמים בגרסא ספציפית

בדיקות שמבוצעות באופן חד פעמי ושלא יחזרו שוב כחלק ממעגל הבדיקות

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

בדיקות שתוכננו למוצר חדש ולא עברו בדיקה ידנית

מקרים שבהם לא ניתן לבצע בדיקות בצורה ידנית

מקרי בדיקה שהמרתם לאוטומציה יקחו יותר זמן מאשר ביצועם בצורה ידנית

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

כאשר מדובר בפרויקט חדש שאינו יציב

במקרה של תוכנה מבוססת ויציבה שאינה משתנה לעיתים קרובות

בדיקות חקר (Exploratory) לרעיונות שעולים תוך כדי בדיקה.

 

 

כמו שאני רואה את הדבר , אוטומציה נוצרת בכדי ל-'שרת' את הבודק ולעזור לו בהורדת הסיכון של קיומם של באגים בתוכנה הנבדקת ובנוסף תומנת בתוכה יתרונות רבים אשר ביניהם ניתן למנות :

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

חיסכון משמעותי בזמן הרצת הבדיקות וכיסוי בדיקות נרחב יותר - אוטומציה תרוץ על סביבות שונות מאלו שהבודק משתמש בהם ובכך הוא יכול לבצע בסביבה A את הבדיקות הידניות ובסביבה B תרוץ האוטומציה במקביל ובכך נקבל חסכון בזמן הרצת הבדיקות ובנוסף נוכל להריץ סבבי בדיקה רחבים יותר. דוגמה מצוינת לחסכון בזמנים היא שאוטומציה יכולה לעזור לנו בכל שכבות הבדיקה ולא רק בהרצת הבדיקות עצמן ,לדוגמה הכנת סביבת העבודה - כמו שאתם מכירים הרצת טסטים חייבת להתבצע על סביבה מתאימה, הסביבות מקבלות עדיפות בכל מיני סוגים של בדיקות החל מבדיקות compatibility  ועד בדיקות .System הכנת סביבות אלו היא אחת מהמשימות המתישות, המעצבנות וכמובן גוזלות הזמן שיש בכל סבב בדיקות, באמצעות אוטומציה אנחנו יכולים ליצור את הסביבות באופן אוטומטי וללא הצורך בהתעסקות ידנית, היתרון העיקרי הוא כמובן החיסכון האדיר בזמן וביעילות העבודה.

יכולת לדווח בצורה יעילה וברורה על קיומן של תקלות - הדיווח יכול להיות בזמן אמת (מייל) או לאחר סיום הריצה (Mail , Log..).

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

הורדת העומס מהבודק - אוטומציה יעילה תוריד את העומס מהבודק זאת מכיוון שהיא מבצעת פעולות שהיו צריכות להיות ידניות ובכך לבודק יש יותר זמן לעסוק בלמידה ושיפור יכולותיו.

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

תוצאות מדויקות יותר - אוטומציה רצה תמיד עם ציפייה מדויקת לתוצאה הרצויה, הורדת הגורם האנושי מבטיחה לנו שהתוצאות יהיו מדויקות יותר.

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

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

אוטומציה - מחזור החיים

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

שלב 1 :הבנת הצורך ובחירת האוטומציה הרלוונטית :

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

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

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

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

שלב 2 :יצירת מסמכי איפיון :

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

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

שלב 3 : בחירת כלי האוטומציה :

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

שלב 4 : העברת תוכנית הבדיקות לצוות האוטומציה

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

צוות האוטומציה יעסוק ב-2 נקודות עיקריות :

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

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

שלב 5 : סגירת קצוות לפני תחילת הפיתוח

בשלב זה לאחר שניתנו זמני הפיתוח יושבים 2 הצוותים (QA & R&D) וסוגרים את כל הנושאים שנשארו פתוחים, דוגמאות לנושאים אלו :

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

שלב 6 : תחילת פיתוח או רכישת מוצר

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

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

יכולת זו מתקבלת ע"י שילוב בודקים ידניים בעלי היכרות עם תוכנה, ו/או שימוש בכלים המאפשרים כתיבת אוטומציה בצורה קרובה ככול הניתן לשפת אדם – לדוגמא שיטות  KDT – Keyword Driven Testing  למיניהן.

שלב 7 : פגישות שבועיות לליווי תהליך הפיתוח

שלב זה יכול לכלול מגוון נושאים :

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

הערה!

אוטומציה תקינה תהיה כזו שאושרה על ידי צוות הבודקים, כל מקטע קוד יהיה חייב לעבור אישור של  צוות ה- QA ורק לאחר מכן יהיה מאושר לשימוש.

שלב 8 : הרצה מלאה של אוטומציות

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