זה לא פשוט לגשת לבדיקות המוצר בפעם הראשונה. גם אם ביצעתם זאת בעבר, עדיין לפעמים קיים היסוס קל מהיכן להתחיל, באיזו אסטרטגיה לתקוף, האם להתחיל לקרוא את המסמכים קודם או להתנסות ישר במוצר ?
כעת, לאחר שדיברנו על מושגים בתחום הבדיקות ומסביב לו, ננסה להלבין סוגיה זו.
ברוב המקרים כשתגשו לבדוק מוצר, סביר שמישהו לפניכם כתב כבר טסטים ברמה כלשהי, גם אם לא בצורה מספקת אבל תוכלו להשתמש בכך בתור התחלה או כ- Reference לטסטים שתרצו להוסיף.
אם לא קיימים טסטים, סביר שקיים מסמך How to כלשהו שמישהו כתב לפניכם בארגון, תוכלו להתחיל בזה כנקודת התחלה להשתמש ולסרוק את המוצר.
אם לא קיים שום מסמך, שום חומר, תמיד אפשר לחפש בגוגל משהו ואם מדובר במוצר פנימי וגם את זה אין, פה כבר אנחנו נכנסים לבעיה.
מי שעבד איתי יודע שאני לא חסיד גדול של מתודולוגיות, מצד שני אני גם לא אוהב בדיקות אינטואיטיביות ולא מבוססות TC, בטח שלא כפתרון קבוע. אני משתמש במתודולוגיות בתור כלי עבודה כדי לקבל כיוון וליצור סדר, אבל הקו המנחה שלי הוא קודם כל ההיגיון הפנימי שלי.
אני הייתי מציע בשלב הראשון להתנסות במוצר ולעבור על כל הפיצ'רים שלו, לשחק איתו קצת ולאתגר אותו קצת בבלתי צפוי. לאחר שהייתי ממצה את העניין, הייתי מתחיל לעבור על ה- Specs או על ה- API שלו ולסמן לי נקודות חשובות.
בנקודה הזו אני ממליץ לערב עוד מישהו, לקבל עוד חוות דעת לגבי היכולות של המוצר, לאסוף פרטים לגבי מה המגבלות של ה- R&D במימוש הקוד, לבדוק מה מעניין יותר את הלקוח, מה הפוקוס של הפרוייקט, האם כל מה שנדרש לטובת סיקור המוצר קיים או שחלק עדיין לא זמין או לא מעודכן.
בחברות מסודרות נהוג לזמן ישיבת Kick-off בה עוברים על כל הדרוש ל"התנעת" הפרוייקט. לא תמיד זה מבוצע, לעיתים לא מדובר במוצר שנועד עבור פרוייקט מתוכנן או לקוח, לעיתים הישיבות לא נותנות את המידע הדרוש עבור ה- QA והדיון נסחף אל תוך קשיי המימוש של הקוד שהם לרוב תופסים את הבמה ומלחיצים את אלה האחראים על העמידה בזמנים שנקבעו לפרוייקט.
לאחר שנאספה כל האינפורמציה הדרושה עבור הבדיקות, זה הזמן לדעתי להתחיל לכתוב אותם לפי קבוצות: Functionality, Negative, Load וכו' בהתאם למוצר, לדרישות וכו'
בנקודה הזו לא הייתי כותב את כל הטסטים הדרושים, למרות שזה מפתה לפעמים ולא הייתי מפרט את הטסטים לרמת ה- steps אלא רושם בנקודת כלליות מה לדעתי נדרש ברמה המינימלית לבצע תוך כדי שאני מתמקד בעיקר בחלק הפונקציונאלי של המוצר ושולח את זה לקבוצה מצומצמת של האנשים המעורבים בפרוייקט כדי לקבל משוב.
תוכלו מאוחר יותר להשתמש בטסטים האלה כעוגן עבור מסמך ATP.
התגובות שתקבלו יכולות להיות מכל מיני סוגים - שינוי בפוקוס הבדיקות, הוספת עוד נושאים לבדיקה, או שלילה של חלק מהתרחישים שהצעתם מכל מיני סיבות, אולי כי ה- setup הנדרש לכך לא זמין, לא קיים, יקר מדי או שפשוט אין זמן ומקום להקים אותו.
הפוקוס הכללי הוא תמיד יהיה cost - effective, כלומר עלות ההשקעה עבור הבדיקות לעומת התוצאות והמידע שהן יתנו עבור החברה. השיקולים לעולם לא יהיו אובייקטיביים וטהורים מבחינת ה- QA ואתם עלולים להתקל ביד מלמעלה שתבחש בקדירה שלא לרוחכם, אם זה יקרה זה לא נורא, בסופו של דבר כמעט תמיד קיימים אילוצים כאלה או אחרים ושום מוצר לא ניתן לבדיקה בצורה מושלמת, אפילו לא קרוב למושלם.
בודק שמתכנן את סט הבדיקות, גם אם הוא מסתמך על Template כלשהו קיים, עדיין צריך לבצע בחירה מושכלת של טסטים. בשום מצב לא מדובר בשילוב כל הקומבינציות האפשריות - גם כי אלה גוזלות זמן וגם כי לרוב עד שה- cycle יסתיים, ייתכן שחלק מהבדיקות לא יהיו רלוונטיות או יעכבו מחלקות אחרות בארגון שמחכות לקבל את ה- TR.
במידה וקיבלתם אור ירוק להמשיך ומערך בדיקות הפונקציונאליות שלכם כבר מוצה, הייתי מתחיל כעת לעבות את חלקי הטסטים העוסקים בבדיקות Negative, Stability, Load וכו' אלה שמתבססות כבר על מוצר שעובד ויציב פחות או יותר.
בסופו של דבר אתם אמורים להגיע לכיסוי די מספק של מספר הטסטים הדרושים לכם - זה יהיה ה- Full Cycle. סביר שתצטרכו לבחור לפחות עוד כיסוי מינימלי מתוך הרשימה הכוללת - כזה שכשאין זמן לסיים את כל הבדיקות (מצב די שכיח בשלבי הפיתוח הראשונים) או שאין טעם כי המוצר "מתפרק" בבדיקות עם תרחישי משתמש בסיסיים. סביר להניח שכיסוי זה יהיה ה- Sanity Cycle.
בנקודה הזו, אפשר לשכלל ולהוסיף עוד כיסויי ביניים של חלק מהקבוצות, אבל לרוב, הנקודה הזו היא פחות או יותר העיקרית שמנסים להגיע אליה בכתיבת מסמך פשוט למוצר.
אם אספתם את המשוב שלכם וסיימתם את מקצה השיפורים שלכם, הגיע הזמן להתחיל לפרט את ה- steps הדרושים לביצוע הטסטים, את דרישות הקדם (pre-requisite) לכל TC או לכל Test Suite. זהו שלב סיזיפי מעט שלרוב מחכים שהוא ייגמר, אבל יש בכך גם משהו מעניין וחשוב - לתכנן כיצד יתבצעו הטסטים, מה יהיה קודם למה, מה דרוש להקמת ה- setup וכדו'. כמו כל מסמך שתכתבו בנושא אחרי חקר מעמיק, יהפוך אתכם למומחים לנושא ואתם תהיו מופתעים מכמות האנשים מכל הדרגים שעשויים לבוא אליכם בשאלות לגבי המוצר ו / או הבדיקות שלו.
בהצלחה.
כעת, לאחר שדיברנו על מושגים בתחום הבדיקות ומסביב לו, ננסה להלבין סוגיה זו.
ברוב המקרים כשתגשו לבדוק מוצר, סביר שמישהו לפניכם כתב כבר טסטים ברמה כלשהי, גם אם לא בצורה מספקת אבל תוכלו להשתמש בכך בתור התחלה או כ- Reference לטסטים שתרצו להוסיף.
אם לא קיימים טסטים, סביר שקיים מסמך How to כלשהו שמישהו כתב לפניכם בארגון, תוכלו להתחיל בזה כנקודת התחלה להשתמש ולסרוק את המוצר.
אם לא קיים שום מסמך, שום חומר, תמיד אפשר לחפש בגוגל משהו ואם מדובר במוצר פנימי וגם את זה אין, פה כבר אנחנו נכנסים לבעיה.
מי שעבד איתי יודע שאני לא חסיד גדול של מתודולוגיות, מצד שני אני גם לא אוהב בדיקות אינטואיטיביות ולא מבוססות TC, בטח שלא כפתרון קבוע. אני משתמש במתודולוגיות בתור כלי עבודה כדי לקבל כיוון וליצור סדר, אבל הקו המנחה שלי הוא קודם כל ההיגיון הפנימי שלי.
אני הייתי מציע בשלב הראשון להתנסות במוצר ולעבור על כל הפיצ'רים שלו, לשחק איתו קצת ולאתגר אותו קצת בבלתי צפוי. לאחר שהייתי ממצה את העניין, הייתי מתחיל לעבור על ה- Specs או על ה- API שלו ולסמן לי נקודות חשובות.
בנקודה הזו אני ממליץ לערב עוד מישהו, לקבל עוד חוות דעת לגבי היכולות של המוצר, לאסוף פרטים לגבי מה המגבלות של ה- R&D במימוש הקוד, לבדוק מה מעניין יותר את הלקוח, מה הפוקוס של הפרוייקט, האם כל מה שנדרש לטובת סיקור המוצר קיים או שחלק עדיין לא זמין או לא מעודכן.
בחברות מסודרות נהוג לזמן ישיבת Kick-off בה עוברים על כל הדרוש ל"התנעת" הפרוייקט. לא תמיד זה מבוצע, לעיתים לא מדובר במוצר שנועד עבור פרוייקט מתוכנן או לקוח, לעיתים הישיבות לא נותנות את המידע הדרוש עבור ה- QA והדיון נסחף אל תוך קשיי המימוש של הקוד שהם לרוב תופסים את הבמה ומלחיצים את אלה האחראים על העמידה בזמנים שנקבעו לפרוייקט.
לאחר שנאספה כל האינפורמציה הדרושה עבור הבדיקות, זה הזמן לדעתי להתחיל לכתוב אותם לפי קבוצות: Functionality, Negative, Load וכו' בהתאם למוצר, לדרישות וכו'
בנקודה הזו לא הייתי כותב את כל הטסטים הדרושים, למרות שזה מפתה לפעמים ולא הייתי מפרט את הטסטים לרמת ה- steps אלא רושם בנקודת כלליות מה לדעתי נדרש ברמה המינימלית לבצע תוך כדי שאני מתמקד בעיקר בחלק הפונקציונאלי של המוצר ושולח את זה לקבוצה מצומצמת של האנשים המעורבים בפרוייקט כדי לקבל משוב.
תוכלו מאוחר יותר להשתמש בטסטים האלה כעוגן עבור מסמך ATP.
התגובות שתקבלו יכולות להיות מכל מיני סוגים - שינוי בפוקוס הבדיקות, הוספת עוד נושאים לבדיקה, או שלילה של חלק מהתרחישים שהצעתם מכל מיני סיבות, אולי כי ה- setup הנדרש לכך לא זמין, לא קיים, יקר מדי או שפשוט אין זמן ומקום להקים אותו.
הפוקוס הכללי הוא תמיד יהיה cost - effective, כלומר עלות ההשקעה עבור הבדיקות לעומת התוצאות והמידע שהן יתנו עבור החברה. השיקולים לעולם לא יהיו אובייקטיביים וטהורים מבחינת ה- QA ואתם עלולים להתקל ביד מלמעלה שתבחש בקדירה שלא לרוחכם, אם זה יקרה זה לא נורא, בסופו של דבר כמעט תמיד קיימים אילוצים כאלה או אחרים ושום מוצר לא ניתן לבדיקה בצורה מושלמת, אפילו לא קרוב למושלם.
בודק שמתכנן את סט הבדיקות, גם אם הוא מסתמך על Template כלשהו קיים, עדיין צריך לבצע בחירה מושכלת של טסטים. בשום מצב לא מדובר בשילוב כל הקומבינציות האפשריות - גם כי אלה גוזלות זמן וגם כי לרוב עד שה- cycle יסתיים, ייתכן שחלק מהבדיקות לא יהיו רלוונטיות או יעכבו מחלקות אחרות בארגון שמחכות לקבל את ה- TR.
במידה וקיבלתם אור ירוק להמשיך ומערך בדיקות הפונקציונאליות שלכם כבר מוצה, הייתי מתחיל כעת לעבות את חלקי הטסטים העוסקים בבדיקות Negative, Stability, Load וכו' אלה שמתבססות כבר על מוצר שעובד ויציב פחות או יותר.
בסופו של דבר אתם אמורים להגיע לכיסוי די מספק של מספר הטסטים הדרושים לכם - זה יהיה ה- Full Cycle. סביר שתצטרכו לבחור לפחות עוד כיסוי מינימלי מתוך הרשימה הכוללת - כזה שכשאין זמן לסיים את כל הבדיקות (מצב די שכיח בשלבי הפיתוח הראשונים) או שאין טעם כי המוצר "מתפרק" בבדיקות עם תרחישי משתמש בסיסיים. סביר להניח שכיסוי זה יהיה ה- Sanity Cycle.
בנקודה הזו, אפשר לשכלל ולהוסיף עוד כיסויי ביניים של חלק מהקבוצות, אבל לרוב, הנקודה הזו היא פחות או יותר העיקרית שמנסים להגיע אליה בכתיבת מסמך פשוט למוצר.
אם אספתם את המשוב שלכם וסיימתם את מקצה השיפורים שלכם, הגיע הזמן להתחיל לפרט את ה- steps הדרושים לביצוע הטסטים, את דרישות הקדם (pre-requisite) לכל TC או לכל Test Suite. זהו שלב סיזיפי מעט שלרוב מחכים שהוא ייגמר, אבל יש בכך גם משהו מעניין וחשוב - לתכנן כיצד יתבצעו הטסטים, מה יהיה קודם למה, מה דרוש להקמת ה- setup וכדו'. כמו כל מסמך שתכתבו בנושא אחרי חקר מעמיק, יהפוך אתכם למומחים לנושא ואתם תהיו מופתעים מכמות האנשים מכל הדרגים שעשויים לבוא אליכם בשאלות לגבי המוצר ו / או הבדיקות שלו.
בהצלחה.
אין תגובות:
הוסף רשומת תגובה