מוצר תוכנה הוא כמו מטוס: עליו לעבור בדיקה טכנית לפני השיגור.
אבטחת איכות היא צעד הכרחי לקראת השקת מוצר תוכנה מצליח. זה רק חלק קטן מכל עבודות הפרויקט, אבל איש לא אמר שזה יהיה פשוט.
ישנם כל כך הרבה סוגים של בדיקות תוכנה - אוטומטיות וידניות, חקירות ופונקציונליות, תאימות, UI / UX, רגרסיה, יחידה, API ובדיקות ביצועים. בהצלחה לעטוף את הראש סביב כולם!
המשותף לכל הסוגים הללו, לעומת זאת, הוא שכל אחד מהם מחייב אותך לכתוב תיעוד בדיקות QA יסודי. האיכות של מסמכי הבדיקה מגדירה אם עבודתכם תוכיח את עצמה או תועיל לשווא.
כתבתי מאמר זה כדי להקל על חייך. אז הנה, המדריך האולטימטיבי שלך כיצד לכתוב תיעוד QA תוכנה שיעבוד.
הכינו תוכנית בדיקה ודוח התקדמות הבדיקה
תוכנית הבדיקה היא מסמך מנחה המתאר את התמונה הרחבה יותר של תהליך ה- QA, וכולל רשימת מטלות, אסטרטגיה, משאבים ולוח זמנים.
לפני שתיצור מסמך תוכנית QA, שאל את עצמך "מה המטרה של פתרון התוכנה?" ו"אילו תכונות צריך לבדוק? ". אל תמהר לבדוק כל חלק בתוכנה שלך. עליכם להחליט באילו מתודולוגיות, טכנולוגיות וכלים תשתמשו.
תוכנית הבדיקה תעזור לך להבין את הדברים הבאים:
- מהם קריטריוני הקבלה?
- אילו משאבים אתה צריך? אילו מערכות הפעלה, כמה עותקים ובאיזה רישיון? האם אתה זקוק ליועצים טכניים כלשהם?
- האם התפקידים והאחריות שלך מוגדרים היטב?
- מהן מסגרות זמן לבדיקה?
דוח התקדמות הבדיקה הוא חלק נוסף בתיעוד ה- QA, הדומה לתוכנית הבדיקה אך עם תוספת נתונים על ההתקדמות הנוכחית. מסמך זה מאפשר לך ולצוות הפיתוח שלך לעקוב אחר התקדמות הפרויקט ולזהות נושאים ארגוניים, אם בכלל.
צור מקרי מבחן
לאחר שתבהיר את מכלול הפונקציות שיש לבדוק בתכנית הבדיקה שלך, עליך ליצור מקרה בדיקה לכל חלק בתוכנה שלך.
מקרי בדיקה הם די פשוטים - תיעוד QA זה מורכב משבעה חלקים: מזהה, מקרה בדיקה, שלבי בדיקה, תוצאה צפויה, סטטוס, תוצאה בפועל ותגובות.
- מזהה הוא מספר ייחודי שהוקצה למקרה הבדיקה שלך.
- ב מקרה מבחן הסעיף, אתה להצביע על הדרישה (ים) שאתה תהיה בדיקה ולספק קישור אל במסמך המפרט.
- במקטע שלבי בדיקה , אתה מפרט את כל הפעולות הדרושות להשלמת מקרה מבחן.
- בקטע התוצאה הצפויה , אתה מסכם את התוצאות של בדיקה מסוימת אם היא מצליחה.
- בקטע סטטוס , אתה מציין אם שלב מסוים עבר או נכשל בבדיקה.
- בשנות התוצאה בפועל הסעיף, אתה יכול להסביר את התוצאות של מבחן נכשל.
- התגובות בסעיף אינו חובה, אבל אתה יכול להוסיף אותו לעזוב כמה הערות נוספות.
כתוב דוח פגמים
דוח הפגמים הוא מרכיב חשוב בתיעוד ה- QA. זה רושם כל בעיה לא רצויה בתוכנית שלך. זהו מרכיב מכריע בתיעוד הפרויקט, שמנווט אותך לקראת פתרון תוכנה ללא באגים.
נשמע פשוט, נכון? כן, אבל רק עד שתתחיל לתעד. כאן תוכל לראות דוגמה לדיווח פגמים טיפוסי:
דוח הפגמים מורכב מהסעיפים הבאים: מזהה, סיכום, תיאור, צעדים להעתקה, שחזור, חומרה, עדיפות, סביבה וקבצים מצורפים.
- לכל נושא תוכנה מסוים מוקצה מספר ייחודי - המזהה . זה מיטוב הניווט בין מסמכי QA ומאפשר תקשורת בין מפתחים, בודקים וראש ממשלה.
- בחלק הסיכום אתה נותן תשובה תמציתית לשלוש שאלות פשוטות: מה קרה, איפה ובאילו נסיבות.
- בשנות ה תיאור בסעיף , אתה מתאר את הבאג בפירוט. עליכם לספר על התוצאות בפועל ועל התוצאות הצפויות. כדאי לספק קישור לדרישות התוכנה שלך.
- לאחר מכן, אתה כותב על השלבים להעתקה (STR) . זה מראה למפתחים בדיוק כיצד לשחזר את הבעיה. אל תחמיץ שלב או שהדוח שלך עשוי לחזור אליך.
- בקטע לשחזור , אתה מבהיר אם הבאג מופיע בכל פעם שאתה עוקב אחר ה- STR. עליך להשתמש במספרים כדי להציג סיכויים משוערים, למשל 7 פעמים מתוך 10.
- בשנות ה חומרת סעיף, אתה יכול להסביר כמה נזק באג עלול להביא את הפרויקט. במילים אחרות, זה מראה את מידת ההשפעה הטכנולוגית של הפגם על המערכת כולה. אפילו נושא קטן עשוי להשפיע קשות על היישום כולו.
- עדיפות מראה עד כמה חשוב דוח פגמים מסוים. ניתן לציין עדיפות בעזרת אותיות - "A" לדחופות ביותר ו- Z עבור הפחות דחופות, מספרים - "1" לדחוף ביותר ו- "9" לדברים הפחות דחופים, או פשוט מילים כמו "high" "," בינוני "או" נמוך ".
- בשנות ה סביבה סעיף, אתה צריך להגדיר אילו מערכות הפעלה או גרסאות הדפדפן הושפעו.
- לבסוף, הקבצים המצורפים כוללים את רשימת הסרטונים, צילומי המסך או קבצי יומני המסוף שנוספו לדוח הפגמים.
זכור טיפים שימושיים אלה לכתיבת דוחות פגמים
- כתוב סיכום מספיק ומספק. לא משנה אם הוא ארוך או קצר. מה שחשוב זה שיהיה ברור.
- עיין בסיכום ובתיאור. האם הם נראים כמעט אותו דבר? בטח שכחת לתאר את התוצאות הצפויות והממשות בתיאור ולהוסיף את הקישור לדרישות.
- צלם את הבעיה בעזרת צילום מסך. זה עשוי לחסוך לך ולצוות הפיתוח הרבה זמן. לפעמים, הצצה אחת בתמונה מספיקה בדיוק בכדי להבין את המצב.
- לפני שתדווח על הבעיה, נסה לשחזר אותה לפחות שלוש פעמים כדי להיות בטוח שהיא קיימת.
- דווח על הבעיה בהקדם האפשרי והודיע על כך למנהל הפרויקט או לבעל המוצר אם הבעיה גדולה.
- בדוק אם קיימות טעויות בדקדוק בתיעוד ה- QA שלך כדי שלא תוריד על ידי משטרת הדקדוק.
- כמה שזה נשמע מצחיק, ודא שהנושא אינו מאפיין - עיין בתיעוד שוב!
- אל תחמיץ שום מידע חשוב בשלבי ההעתקה שלך.
הגש דוח פגמים
דוחות פגמים עוברים מחזור חיים - מהרגע שאתה מדווח על בעיה ועד לרגע שהנושא נסגר.
השלב הראשון הוא לגבש ולהגיש את דוח הליקויים. בשלב זה, מנהל הפרויקט או מנהל טכנולוגי מחליטים אם להקצות אותו למפתח או לדחות אותו מטעמי חוסר מספיק או חוסר התאמה.
לאחר שהמפתח שהוקצה תיקן את הבאג, אתה כ- QA צריך לבדוק שוב ולוודא שהוא תוקן. אם כן, תוכל לסגור את דוח הפגמים. הנוהג הטוב ביותר הוא לסגור אותו בעוד שבוע-שבועיים.
אם הבאג אינו מתוקן, אתה פותח מחדש את דוח הפגמים ושולח אותו חזרה למפתח שהוקצה. תהליך תיקון הבאגים יכול להיות ארוך, אך עליכם להישאר חזקים עד שכל דוחות הפגמים ייסגרו סופית.
לעטוף
אבטחת איכות היא תהליך שאתה פשוט לא יכול להימנע ממנו. כל מטוס לפני היציאה עובר בדיקה טכנית. אם יש בעיה כלשהי, המטוס מקורקע עד לפתרון הבעיה.
באופן דומה, יש לבדוק כל מוצר תוכנה לפני ההשקה. אינך יכול להרשות לעצמך לפרוס תוכנת באגי מכיוון שמשתמשים לא יתנו לאפליקציה שלך הזדמנות שנייה.
האם אתה צריך לשפר את איכות התוכנה שלך?
החברה שלי KeenEthics מספקת שירותי פיתוח ואבטחת איכות איתנים. במקרה שאתה זקוק לאומדן לפרויקט דומה, אל תהסס ליצור קשר .
אם נהנית מהמאמר, עליך להמשיך עם מהו טיפוס אב טיפוס ולמה אנו זקוקים לו ועם מוצר מינימלי בר-קיימא: בין רעיון למוצר.
נ.ב
המאמר המקורי שפורסם בבלוג KeenEthics נמצא כאן: כיצד לכתוב תיעוד QA שיעבוד?