QAtest - אקדמיה אינטרנטית לבדיקות תוכנה QA


" לא נוכל לפתור בעיות באמצעות אותה צורת חשיבה שהשתמשנו כשיצרנו אותם " אלברט אינשטיין

רשימת תפוצה1


QAtest - אקדמיה אינטרנטית לבדיקות תוכנה

מאמרים


כיצד לתעד נכון את הבדיקות שלכם !

כיצד לתעד נכון את הבדיקות שלכם !

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

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

מבנה צוות בדיקות תוכנה

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

קרא עוד
כיצד פותחים באג בצורה נכונה ?

כיצד פותחים באג בצורה נכונה ?

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

קרא עוד
רמות בדיקה / סוגי בדיקה

רמות בדיקה / סוגי בדיקה

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

קרא עוד
תכנון מקרי בדיקה - בדיקות תוכנה

תכנון מקרי בדיקה - בדיקות תוכנה

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

קרא עוד
10 הכללים לתכנון בדיקות תוכנה

10 הכללים לתכנון בדיקות תוכנה

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

קרא עוד
ניתוח ודיווח תוצאות בדיקות תוכנה ON-LINE  (סטאטוס בדיקות/דוח תקלות/Report)

ניתוח ודיווח תוצאות בדיקות תוכנה ON-LINE (סטאטוס בדיקות/דוח תקלות/Report)

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

קרא עוד
Root Cause Analysis – Dealing with problems not just symptoms1 By Alon Linetzki, Managing Director & Principal Consultant,Best- Testing

Root Cause Analysis – Dealing with problems not just symptoms1 By Alon Linetzki, Managing Director & Principal Consultant,Best- Testing

Root Cause Analysis - התמודדות עם בעיות לא רק סימפטומים. מאמר הוצג בארה"ב בכנס STAR באורלנדו (2008), ובכנסים באירופה (2008, 2009).וזכה במשוב מעולה.

קרא עוד
איך יודעים מתי לסיים לבדוק ? מדדים ומטריקות ומה שבינהם

איך יודעים מתי לסיים לבדוק ? מדדים ומטריקות ומה שבינהם

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

קרא עוד
תוכנות ועזרים לבודק

תוכנות ועזרים לבודק

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

קרא עוד

שירותים


הספר שלך לבדיקות תוכנה !

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

קרא עוד

טפסים לבדיקות תוכנה

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

קרא עוד

קורסים לבדיקות תוכנה

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

קרא עוד

אודות



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


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


בהצלחה, שתפו והכי חשוב ביחד נעצור את כל הבאגים !!!!






WE BRING QUALITY TO THE WORLD

שאלות ותשובות


מהו תפקידו של בודק תוכנה ?

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

QA - Quality Assurance

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

STR

Software Test Report / Software Test Results  -  דו"ח ביצוע בדיקות תוכנה מסמך המכיל את תיעוד מהלך ביצוע הבדיקות ועוד נתונים חשובים כמו: 1. סיכום תקלות וחומרתן 2.נתונים סטטיסטיים על מהלך הבדיקות.

STP

Software Test Plan
מסמך המהווה מסגרת לפרוייקט בדיקות תוכנה:
*סקירת המערכת הנבדקת - מה מתוכנן לבדוק מבחינת QC .
* שיטת ותכולת הבדיקות.
* משאבים נדרשים לבדיקות - הכשרת צוות בודקים, כלי בדיקות.
* ניהול הבדיקות וניהול הממשק עם צוותים אחרים. * נקודת בקרה ודיווח.        
* בקרת סיכונים.

STD

Software Test Description - מסמך מפרט הבדיקות. * מסמך המפרט את מקרי הבדיקה המתוכננים מתוך התייחסות לנתוני הקלט והפלט הצפוי. * הגדרת דרישות מוקדמות מבסיס הנתונים ותאור מפורט של רכיבי סביבת הבדיקות.

SPR

Software Problem Report -
מסמך פרוט תקלות הפיתוח.
* מסמך המפרט את רשימת התקלות שהתגלו במהלך הבדיקות. * הדוח מפרט תקלות סגורות ופתוחות בחתכים שונים: פרויקט / צוות פיתוח / חומרה /פתוחת/סגורות.                                                                                                                             

Unit

בדיקות יחידה - מתוך ויקיפדיה, האנציקלופדיה החופשית

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

Integration

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

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

System

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

Acceptance tests

בדיקות קבלה - מתוך ויקיפדיה, האנציקלופדיה החופשית

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

Functional

בדיקות פונקציונליות - מתוך ויקיפדיה, האנציקלופדיה החופשית - לאימות פעילות המערכת.
בדיקות אלו מבוססות על מסמך הדרישות ומסך האפיון ומטרתן לבדוק כי המערכת עושה את מה שהיא צריכה ולא עושה את מה שאינה צריכה לעשות (valid and invalid testing)

Usability

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

GUI

בדיקות ממשק לקוח - מתוך ויקיפדיה, האנציקלופדיה החופשית

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

Load

בדיקות עומס - מתוך ויקיפדיה, האנציקלופדיה החופשית

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

Performance

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

Regression

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

Compatibility

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

Alpha/Betha Testing

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

Sanity

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

Smoke

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

BlackBox

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

White Box

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

חנות


All

ספר פיזי - הדרך המהירה לבודק תוכנה אפקטיבי

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

115

ספר דיגיטלי - הדרך המהירה לבודק תוכנה אפקטיבי

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

85

ספר אודיו לשמיע (בדרכים/MP3) - הדרך המהירה לבודק תוכנה אפקטיבי

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

148

The Fast Way to Becoming an Effective QA!

הספר בתרגום לאנגלית - The Fast Way to Becoming an Effective QA! Your entrance ticket to the world of High-Tec Become a professional QA

115

צוות


Jennifer Smith

C.E.O

Lorem ipsum dolor sit amet, te decore causae disputationi ius. Ex per viris malorum. Vix et simul signiferumque.

נתי הורנשטיין

עורך ומקים אתר QAtest - אקדמיה אינטרנטית לבדיקות תוכנה, אתר מהנדסי הבדיקות של ישראל

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

קרא עוד

Lucy Lennon

Partner

Lorem ipsum dolor sit amet, te decore causae disputationi ius. Ex per viris malorum. Vix et simul signiferumque.

John Newman

Office manager

Lorem ipsum dolor sit amet, te decore causae disputationi ius. Ex per viris malorum. Vix et simul signiferumque.

צור קשר


גן הדרום, ישראל


טיפ 1 - בדיקות תוכנה בגובהה העיניים

חשיבות הבנת צרכי הלקוח

המטרה שלנו - אפס באגים

טיפ 2 - בדיקות תוכנה בגובהה העיניים

חשיבות תכנון הבדיקות מראש

המטרה שלנו - אפס באגים

טיפ 3 - 10 הכללים לתכנון בדיקות תוכנה


 
10 הכללים לתכנון בדיקות תוכנה

משולחנו של נתי הורנשטיין
 עורך אתר QAtest


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

בעבודתי עם אנשים, אני נתקל לא פעם באנשים האומרים – "אין זמן לתכנן בדיקות התחלנו לבדוק...",
"כשיהיה לי מסמך ייזום/אפיון מושלם... אז אוכל ..", "אני צריך... יותר זמן ...", "מה שחסר לי כדי להיות באמת יעיל, זה..." וכו'.
מה שאני מיד מזכיר להם, הוא שאנו חיים בעולם עסקי מהיר. חשיבות הכניסה לשוק היא מאוד קריטית לארגון TIME TO MARKET)) ולמרות שזה אולי קצת לא נעים לשמוע, תקופת המוצרים (תוכנות) היא מוגבלת.
כאשר אנו מבינים שהמוצרים כאן לתקופה מוגבלת, זה מחייב את העוסקים בתחום הבדיקות להיות יעילים ומהירים ככל שניתן.
אני מניח שישנם אנשים שיאמרו כי אינם מסכימים עם אמירה זו, וכי לפעמים ישנם גישות ומתודלוגיות אחרות, אירועים וכדומה שמרגיזים, מעצבנים ומשפיעים על תהליך הבדיקות ומונעים מהם להיות איכותיים ומהירים.
ולכן ריכזתי כאן, את "10 הכללים לתכנון בדיקות תוכנה" שלי – שאני בטוח שאם תיישמו אותם, יהיה לכם קל יותר בחיי היום יום כעוסקים בתחום הבדיקות.
הבנה של צרכי הלקוח (הדרישה העסקית)
האם חשבתם פעם, כמה זמן אתם מבזבזים על הבנה מה בדיוק הלקוח רוצה ?
בקריאת מסמכי ייזום (דרישה) ? הבנת האפיון – מה אתם קוראים? האם אלו מסמכים ברורים, מעודכנים,
הלוואי... רוב מה שאתם קוראים אינו עונה ב 100% לצרכי הלקוח.
אין זה אומר כי עליכם לחיות במנותק למה שקורה מסביבכם, אבל כשאתם מודעים לחשיבות שיש לתוכן
מסמכי הייזום ואפיון, ככל שתמונת הצורך העסקי תהיה ברורה כך תוכלו להיות יותר ממוקדים.
כאשר מתכננים בדיקות עם מסמכי ייזום ואפיון לא מושלמים או עדכניים זה משפיע על תכנון הבדיקות
שלכם ועל תוצאות הבדיקות שלכם בין אם אתם מודעים לכך או לא.
לסיכום, יש לוודא הבנה מהיבט הלקוח.
תכנון בדיקות
השלב החשוב ביותר ואין להתחיל בבדיקות או בכתיבת תסריטי בדיקות ללא ביצוע מיפוי
כללי של כלל מצבי הבדיקה.
ללא תכנון בדיקות מסודר אין להתחיל בתהליך הבדיקות.
תכנון בדיקות ניתן לבצע ע"י תרשימי זרימה / טבלת החלטה או כל דרך אחרת.
תכנון הבדיקות: הבנת צרכי הלקוח, מיפוי מצבי הבדיקה ורק לאחר מכן כתיבת תסריטי הבדיקות.
זמן השקעה בתכנון הבדיקות
שאלת המיליון, כמה זמן להשקעה בתכנון הבדיקות ?
ממוצע הזמן הדרוש הוא בין 30%-40% מכלל הזמן שהוקצב לטובת הבדיקות.
לדוגמא: אם מדובר בפרויקט בדיקות שמתוכנן לו 100 ימי בדיקה, זה אומר ש 30-40 ימים צרכים להיות לטובת תכנון הבדיקות.
תוצאה צפויה של כל צעד
כתיבת תסריטי הבדיקות חייבת להתבצע בצורה מובנת ומסודרת – חלק זה נכון וברור לכל העוסקים בתחום הבדיקות. עד כאן הכול בסדר ..
וזו הנקודה החשובה - לכל צעד וצעד (STEP) שנבדק חייבת להיות מראש תוצאה צפויה.
עוד בשלב תכנון הבדיקות אנו חייבים להבין מהי התוצאה הצפויה בכל שילוב אפשרי של הפרמטרים.
בדיקות ללא תוצאה צפויה תביא אותנו למצב שבו כל תוצאה שמתקבלת יכולה להיות תקינה או להתחיל דיון האם התוצאה תקינה או לא ??
כיסוי מלא של תסריטי הבדיקות
כיצד להפיק כמות גדולה של מקרי בדיקות ממסמכי הבדיקות ? הרעיון מבוסס על שיטה פשוטה בניתוח
מערכות: קח שני מרקרים (למשל, ורוד וצהוב), עבור על מסמך הדרישות / אפיון, צבע בצבע אחד את
כל שמות העצם, צבע בצבע אחר את כל הפעלים. כל שם עצם יהפוך לאובייקט (טבלהב-DB, קלאס),
כל פועל יהפוך לפונקציה.
דגשים לבדיקות
עברנו דרך ארוכה של הבנת צרכי הלקוח, תכנון הבדיקות, בדיקה לכיסוי מלא של התסריטים ועכשיו חשוב מאוד !
נא ליזום פגישה עם נציג מטעם הלקוח להציג בפניו את תכנון הבדיקות ולקבל ממנו דגשים נוספים לבדיקה.
טמפלט לסוגי בדיקות
חשוב לוודא שקיימת התייחסות לרמות וסוגי בדיקות.
לכן מומלץ ליצור טמפלט המחולק בצורה כזו, לדוגמא:
- בדיקות פונקציונאליות
- בדיקות GUI
- בדיקות רגרסיה
- בדיקות שליליות – צריכות להוות לפחות 30% מכלל התסריטים – רוב התקלות נפתחות
באזור זה.
ניתן להוסיף עוד תלוי בסוג בפרויקט ו….
צמצום בכמות התסריטים
מתקדמים ....ועכשיו חשוב לבדוק מול ראש צוות הפיתוח או המתכנת, האם הרכיבים הנבדקים הם גנריים במערכת המידע הנבדקת ועקב כך ניתן לצמצם בכמות התסריטים.
תכנות גנרי הוא הדרך לכתיבת תוכניות שאינן תלויות בטיפוסי המשתנים. בד"כ קיימת התלות של שיטות ותוכניות בטיפוס הנתונים הניתן להם, אך כאשר קיימת תוכנה גנרית ניתן לחסוך תסריטים, כמובן שרק לאחר חשיבה מסודרת.
עדיפות לתסריט
קרובים לסיום .....
חשוב לזכור ! לא כל התסריטים נמצאים באותה רמת עדיפות ולכן חשוב להתחיל לבדוק את המערכת מהתסריטים
בעלי עדיפות גבוהה.
לדוגמא:
תסריט 1 - בדיקת חישוב חשבון חודשי של לקוח סלולארי – עדיפות גבוהה.
תסריט 2 – בדיקה שסכום החיוב נרשם בפונט Arial כמו כל חשבון הלקוח – עדיפות נמוכה.
אם וכאשר לוחות הזמנים משתנים והמוצר חייב לעלות ליצור, חובה לסיים את כל התסריטים בעלי העדיפות הגבוהה.
10. ניהול תקלות הפיתוח - עדיפות וחומרה לכל תקלה
בודקים...אז יש תקלות .....
גם כאן, לא חייבים לטפל בכל תקלה שנפתחה, רצוי ואף חובה לתת עדיפות וחומרה
לכל תקלה ולטפל בתקלות בחומרה גבוהה לפני שמטפלים בתקלות בעדיפות נמוכה.
בסוף הפרויקט אם יש זמן ניתן לתקן את כל בתקלות.

מס' תקלות לפרויקט / חומרה
שם פרויקטגבוהה -1בינונית - 2נמוכה - 3
קליטת עסק חדש


מוצר חדש


קליטת תשלום


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

טיפ 3 - 10 הכללים לתכנון בדיקות תוכנה

טיפ 4 - הדרך המהירה לבודק תוכנה אפקטיבי

חשוב כל הזמן ללימוד וללמוד כדי להוביל בתחום

המטרה שלנו - אפס באגים

רשימת תפוצה


רשימת תפוצה


הרשמה לרשימת תפוצה  QAtest - אקדמיה אינטרנטית לבדיקות תוכנה

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