מישהו בצוות כתב מסמך בדיקות ואתם רוצים לסקור אותו? הנה שיטה שבשלושים שניות תעשו כן. טוב, לא בדיוק סקירה מלאה, אבל מעיין sanity, בדיקה ראשונית בכדי לראות שאנחנו בכיוון. זה גם חוסך זמן וממילא בדיקה חשובה כשלעצמה. והינה השיטה, הפשוטה, בשלשה צעדים ובחינם:
1. פותחים שלשה מסמכים:
מסמך דרישות של מנהל המוצר.
מסמך הדיזיין של הפיתוח.
מסמך הבדיקות לו עורכים סקירה.
2. מוצאים את מילות המפתח בכל אחד משני המסמכים הראשונים, למה הכוונה?
כל אחד מסעיפי הדרישה סובב סביב מונח. למשל דרישה לעורך מסמכים:
Save: the save function is design to preserve the document state as is, so the user will be able to restore it later.
כמובן שכאן מילת המפתח היא Save. ובכל דרישה או סעיף בדיזיין ניתן למצוא את מילת המפתח.
3. מחפשים במסמך הבדיקות את המילים הללו.
כשמישהו כותב על תת-פיצ'ר מסויים הוא יזכיר את שמו (אלא אם הבודק גרוע באופן יוצא מהכלל) באופן טבעי (במקרה שלנו איך אפשר לכתוב על Save בלי להזכיר את המילה Save?). ואם אין איזכור - משהו פגום במסמך.
כמה נקודות:
1. זו שיטה די מדוייקת, אבל ייתכנו פספוסים, למשל מישהו טעה טעות כתיב, או חיסר רווח וכד'.
2. אם הבדיקה הזו עברה - עוברים לבדיקה מעמיקה של קריאת כל המסמך. זה שהדברים מוזכרים לא אומר שהם מוזכרים נכון.
1. פותחים שלשה מסמכים:
מסמך דרישות של מנהל המוצר.
מסמך הדיזיין של הפיתוח.
מסמך הבדיקות לו עורכים סקירה.
2. מוצאים את מילות המפתח בכל אחד משני המסמכים הראשונים, למה הכוונה?
כל אחד מסעיפי הדרישה סובב סביב מונח. למשל דרישה לעורך מסמכים:
Save: the save function is design to preserve the document state as is, so the user will be able to restore it later.
כמובן שכאן מילת המפתח היא Save. ובכל דרישה או סעיף בדיזיין ניתן למצוא את מילת המפתח.
3. מחפשים במסמך הבדיקות את המילים הללו.
כשמישהו כותב על תת-פיצ'ר מסויים הוא יזכיר את שמו (אלא אם הבודק גרוע באופן יוצא מהכלל) באופן טבעי (במקרה שלנו איך אפשר לכתוב על Save בלי להזכיר את המילה Save?). ואם אין איזכור - משהו פגום במסמך.
כמה נקודות:
1. זו שיטה די מדוייקת, אבל ייתכנו פספוסים, למשל מישהו טעה טעות כתיב, או חיסר רווח וכד'.
2. אם הבדיקה הזו עברה - עוברים לבדיקה מעמיקה של קריאת כל המסמך. זה שהדברים מוזכרים לא אומר שהם מוזכרים נכון.
אין תגובות:
הוסף רשומת תגובה