Global Side Menu Width
Placeholder

שיטות סטטיות ב-QA

Static testing VS Dynamic testing

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

  • דרישות
  • מסמכי הבדיקות
  • Syntax of the code
  • דוקומנטציה אחרת…
  • …

Testing Review – סקירה

INTRO STAGE 0

מתאם (moderator) מקבל מ-Technical Lead בקשה לבדיקת מסמך לצורך בדיקת קריטריוני כניסה לבדיקות (entry check ) ללא entry check – קריטריוני כניסה לבדיקות, ביקורת המסמכים יכולה להיות כבזבוז זמן.

Planning stage 1

נניח שמתאם (moderator)  בזמן סקירה מצא שגיאות כתיב בחלק מהכותרות של האפליקציה  במסמך האפיון.
לכן MODERATOR יבקש Technical Lead לתקן את השגיות ולאחר התיקון אם הכל בסדר אז MODERATOR קובע שעות לפגישה עם כל צוות לצורך סקירה, כאשר בהזמנה למפגש הוא רושם נושא של הסקירה, מקום המפגש, מגדיר את קריטריוני יציאה (Exit criteria) – מהו המקסימום בעיות שיכול להיות בעמוד של מסמך אשר מיעוד לבדיקה וגם מבקש בקשה מ TECHNICAL LEAD לצרף מסמך אפיון לפגישה.

מתאם ביקורת – MODERATOR – מתוכנן גם באיזה אופן לבדוק מסמכים כגון 10-20 עמודים ביחידת זמן.

- Planning
The review process begins with a request for review by the author to the moderator/inspection leader. 
A moderator has to take care of the scheduling, entry check( to ensure that the reviewer’s time is not wasted) & exit criteria.

Kick-off meeting 2

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

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

- Kick-off
Short introduction on the objectives by author.

3  Preparation

סוקרים (reviewers) מבצעים ביקורת באופן אינדיבידואלי ובודקים מסמכים ורושמים כל פגמים שיש במסמכים ושאלות שלהם ב-LOG. כאשר בדרך כלל מספר עמודים בשעה לביקורת (checking rate) הוא 5.

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

- Preparation
Reviewers review the document individually, all issues are recorded using a logging form - checking rate is ¬5 pages per hour.

4 Review meeting

יש כאן מספר תת שלבים:

  • Logging phase

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

Minor – יש סיכוי קטן שפגם יגרום לנפילה

Major – יש סיכוי גדול שפגם יגרום לנפילה

Critical –  פגם יגרום לנפילה בהחלט!

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

מתאם (moderator) גם יכול להיות סוקר – reviewer

  • Discussion phase

דיון בין כתבן (Scribe) וסוקרים (reviewers) על בעיות שנרשמו ב-Logging phase כך שמתאם (moderator) שומר על יחסי אנוש בין הצדדים. בנוסף במידה ומספר בעיות שנמצאו על-ידי כתבנים(Scribes) יותר ממספר שהוגדר בקריטריוני יציאה (Exit criteria) (לדוגמה נמצאו יותר מ-3 בעיות קריטיות במסמך, בעמוד אחד) אז מסמך נשלח לתיקון (Rework).

- Review meeting-Logging phase: 
The issues and the defects that have been identified during the preparation step are logged by the author or by a scribe. During the logging phase the moderator keeps a logging rate (number of defects logged per minute ~2 bugs per minute);

- Discussion phase: 
The moderator takes care for discussion of the logging issues. If the number of defects found per page is more than a exit criteria on page (for example if found more than 3 defects on page) then the document must be reviewed again-reworked.

5 –  Rework

מחבר מסמך  (author) יעשה שינוי/תיקונים במסמך לפי LOGGING PHASE – לפי מסמך שרשם  SCRIBE.

Rework:
Author judges whether the defect has to be fixed.

6 – Follow-up

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

Follow-up:
Moderator check if the author has taken action on all defects.

ניתוח סטטי בעזרת הכלים

מהדר (Compiler) מתרגם שפה מסדר גבוה לשפת מכונה אז מהדר בודק Syntax של שפת תכנות לתקינות.

  • Static analysis

ניתוח סטטי כגון: מסמך דרישות ודוקומנטציה אחרת, בדיקת קוד ללא הרצת תוכנה כגון Syntax, לוגיקה של הקוד…