‏הצגת רשומות עם תוויות STD. הצג את כל הרשומות
‏הצגת רשומות עם תוויות STD. הצג את כל הרשומות

יום שישי, 29 באוקטובר 2021

XRAY for Jira: חיווי איכות הטסט קייס (סידור מותאם על ידינו)

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

השתמשנו בתוסף של ג'ירה ScriptRunner כדי לעזור עם זה.

אלו האינדיקציות:

  • מספר הסטפים (חייב להיות בין 4 ל-12 סטפים).
    צבע: אם אין סטפים - אדום, אם יש פחות מ-4 או יותר מ-12 - כתום.
  • קבצים מצורפים (לא חובה, המלצה חמה).
    צבע שחור.
    תיאור (description) של הטסט.
    צבע כתום.
  • סטטוס של הטסט (לא סטטוס הריצה, אם עברה או לא, אלא הסטטוס של ה-issue type) - צריך להיות מאושר (כלומר עבר ביקורות פנימיות וחיצוניות).
    צבע אדום.

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

חיווי איכות הבדיקות


יום ראשון, 15 באוגוסט 2021

XRAY for Jira: מהרפוזיטורי לאקסקיושן

 ה-XRAY, בהיותו בנוי בתוך הג'ירה ויורש של תכונות רבות שלה, הוא גמיש ומאפשר לעשות את אותו הדבר בדרכים שונות.

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

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

מטסט ריפוזיטורי להעביר טסטים לטסט פלן ומשם ליצור טסט אקסקיושן.



יום שישי, 6 באוגוסט 2021

XRAY for Jira: Parameterized Tests הסבר על הפיצ'ר החדש (וידאו)

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

חלק ראשון - פרמטרים רגילים:


חלק שני - פרמטרים קומבינטוריאלים:



יום שני, 11 במאי 2020

Test Management Tools battle in Jira: SynapseRT VS Xray - קרב מנהלי הבדיקות בג'ירה

סיפרתי על ההעברת הבאגים מה-Quality Center לג'ירה בעבר. אבל מה עם הטסטים?

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

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

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

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





יום שישי, 27 בספטמבר 2019

מיגרציה מ-Quality Center ל-Jira חלק ראשון: אסטרטגיה

הגיע היום גם אצלנו לעבור מה-Quality Center, להלן QC, שהיה בעבר של מרקיורי, אח"כ של HP וכיום של מיקרופוקוס, לג'ירה.
הסיבה המרכזית למעבר היא שהג'ירה כשלעצמה, ובוודאי בסיוע של שאר הכלים של חברת Atlassian כמו ה-Confluence וה-Bitbucket, הולכת ותופסת מקום מרכזי בניהול פיתוחי תוכנה בארץ ובעולם. הג'ירה היא בעצם מקום אחד שבו ניתן לנהל, בעיקר עם חיבור לשאר הכלים שציינתי, את כל מחזור חיי הפיתוח.
בנוסף, ה-QC מיושן גם בראיית העולם שלו (הארגיון שלי עבר לאג'ייל לא מזמן) וגם בניראות שלו. ולבסוף, ממילא צריך לקנות רישיונות לכולם בג'ירה, אז למה לבזבז רישיונות גם ל-QC?
מצד שני, אין ספק שה-QC כמערכת בעל יותר יכולות מאשר לג'ירה, ותמיד קשה לעבור בין כלים.

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


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


חלק ראשון: אסטרטגיה

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

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

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

ריכזתי ב-Confluence את כל סוגי ה-defects שיש לנו, את כל הפרוצדורות וה-workflows שאנו משתמשים בהם.

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

בחלק הבא נעסוק בחלק היותר טכני של המעבר.

יום רביעי, 1 ביולי 2015

צ'ק ליסט לכתיבת מסמך בדיקות - STD Checklist

The final list includes many items added by Kobi Halperin as appeared here.

Preparations and format:
01. Were all the requirements identified and listed while preparing the TD?
02. Does the traceability matrix exist as a part of the document or referenced from the TD?
03. Is every requirement covered by at least one test group in the TD?
04. Was the TD written in accordance with the template?
05. Was the TD written in accordance with the guidelines in the Test Approach document?
06. Are all the test groups and test cases uniquely identified?
07. Is the naming convention used consistent throughout the document?
08. Was the Doc Revision Change Control filled properly?
09. Are the Testing Gear properly identified?
a. Tool specifications.
b. Scripts and debug tools.
c. Information that should be found in logs.
10. Are some of the tests defined as being done not in a clean environmet to identify integration and other parts influances?
11. Are all related documents mentioned and linked?
12. Are there Definitions & Abbreviations to all the terminology in the document?
13. Are all the topics that will be tested and will not be tested defined in the document?
14. Is there any reference to documentation tests (Help windows, User Manual & Installation Manual)?
15. Are there any TBD issues?
16. Was the Speller run? Were all needed updated values updated (e.g. TOC)?
17. Does the document include diversity (users, ports, slots etc)?
 ×¦'×§ ליסט למסמך בדיקות STD

Test groups:
18. Were all the test groups and test cases defined in accordance with system impacts (Installability, Integrity, Security, Performance, Maintainabilility, Serviceability, Update/Migration, Documentation, Usability, Standards, Reliability, Requirements, Capability?)
19. Were all the test groups and test cases defined in accordance with triggers (Functional, Startup/Restart, Recovery/Exception, Redundancy Failover, Hardware configuration, Software configuration?)
20. Does every test group contain at least one test case?
21. Does each test group test one specific requirement?
22. Is every test group verified under different conditions/inputs/scenarios?
23. Is the testing method described clearly for each test group (to the level that will enable the reviewer to understand how the test cases will be executed and how the results will be evaluated?)
24. Does the test method for each test group include criteria for evaluating tests results?

Test Cases:
25. Are the test cases classified according to applicable test types (Positive Test Case, Negative Test Case - about 30%, Boundaries Test Case, End Cases)?
26. Are there tast cases designed to detect problems between the tested feature and other features / sub-systems of the system?
27. Does each test case include the purpose of the test?
28. Are the test cases for the same test group testing the same requirement under different conditions?
29. Are the test groups and test cases designed in bug revealing orientation (we are testing in order to find bugs and not to show that it works?)
30. Do the tests cases have priority based on the product (e.g. complexity) and version (e.g. feature X as milestome for a customer)?
31. Do the test groups include separate test cases for positive, negative, boundary checks?
32. Do the test groups include separate test cases for end cases?

a. Were test cases with special input values (empty file, empty message, etc) defined?

b. Were test cases defined for testing functionality under abnormal conditions (no communication between two components, temporarily no connection to data base, etc)?

c. Were test cases with illegal input values defined?
33. Were complicated and not only trivial scenarios defined for test case execution (for example, several users performing actions or contradictory actions, like one user deposing a message, while the subscriber is deleted, or depositing a message while another message is deposit and causes exceeding the message quota)?
34. Are the test objectives described clearly for each test group?
35. Was test results evaluation defined (at least considered) by more than one method (for example, visual observation of user’s handset, activity log record and relevant log file record?)
36. Does every test case have preparations and setup (either stated implicitly or referenced to the test group or whole TD preparations and setup?)
37. Are issues of error handling addressed?
38. Were test cases with default input values defined?
39. Was test cases dependency eliminated (can each test case run independently and not dependent of execution of other test cases)?
40. For test cases that have specific preparations and setup, was a return to initial conditions defined upon end of execution (to eliminate dependency)?
41. Were test cases defined in order to check data integrity (data loss in case of errors, failures?)
42. Were test cases defined in order to check data consistency (in case of flow errors, for example?)
43. Were test cases defined to check rollback in case of flow error?
44. Were test groups and test cases that are relevant only for specific version identified and marked as such (the idea is to have one TD for a sub-system/service/feature for all versions and test cases that are not relevant for this version can be easily identified and not executed?)
45. Are the expected test results for each test case specific and unambiguous (you understand exactly what to expect from the test results and if everything works correct, you will always expect the same results?)
46. Where we use the same set of steps (e.g. checking text fields): is it written only once with reference?
47. Where we use the same set of parameters (e.g. checking configuration files): is it written only once with reference?
48. Do all test cases include running time estimation (before the first run it is a ragh estimation, will be updated if needed after the first run)?

Test Steps:
49. Are the actions (steps) in the test procedure specific and unambiguous?
50. Do the steps include only relevant actions for test execution and are not mixed with test preparations and setup?
51. Are the test procedures brief (5-10 steps. If not, you are probably testing several things at once?)
52. Wherever a range of values (including in the test gear) can be used - is it included in the tests?

Jul 1, 2015

יום שלישי, 10 בינואר 2012

בדיקות גנריות של שדה טקסט

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

לחצ/י כאן

יום שישי, 11 בנובמבר 2011

בניית עץ בדיקות

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


כמו בכל מערכת לניהול תסריטי בדיקה, גם במערכת שלהם יש שתי רמות: רמת המחסן שבו יש כל תסריטי הבדיקה ורמת הביצוע, בה ממש מריצים את התסריטים. זה כמובן הגיוני כי בגרסה אחת מריצים כמה פעמים את אותם התסריטים ואת אותו תסריט במה גרסאות. מה שנותר לעשות בגרסה חדשה הוא להקצות את התסריטים המתאימים לגרסה המתקרבת.
לרמות האלה קוראים ב-AVG רמת התבניות (Template View) ורמת המשימות (Task View).
לגבי רמת התבניות, ברגיל אין בעיה: בונים את זה לפי מוצר וא"כ לפי גרסה. אבל איך בונים את המחסן?
אני חשבתי (ועדיין חושב) שלפי מוצר ואח"כ לפי פיצ'רים. היתרון הוא בכך שלא חובה להריץ את כל הרגרסיות בגרסה. למשל, מצד אחד, בקומברס בכח האדם שהיה לנו, והיה לנו, חישבנו פעם שיקח שנה להריץ את כל הרגרסיות. מצד שני יכולה להיות גרסה נקודתית מאוד של שינוי UI למשל ואין צורך להריץ רגרסיות מלאות.
הדעה השניה היתה שגם את רמת התבניות יש לבנות לפי גרסאות וליצא את כל הטמפליייטים מגרסה לגרסה, ומה שלא מיועד לבדיקה ייסומן בהתאם. נכון שיהיו הרבה תסריטים לבחור מהם אבל זה נכון גם לשיטה הראשונה.

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

יום ראשון, 4 במאי 2008

צ'ק ליסט לכתיבת מסמך בדיקות התקנה (STD Checklist)


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

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

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

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

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

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

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

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

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

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

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

וכעת לעיצות מעשיות יותר:

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

דבר שני, וכשכבר אנו חושבים שההתקנה טובה, יש לזכור את קהל היעד. לכן מומלץ מידי פעם להביא לבדיקות אלה בודק (או מישהו אחר) בעל רקע מתאים שלא התקין את המערכת הזו מעולם ולתת לו לעשות זאת בעצמו (ובהשגחה שקטה – מעיין מבחן יוזביליות).
בנוסף, וזה עניין שצריך להתחיל בדרישות ואם אין התייחסות אזי עלינו לדרוש את זה בתהליך ההתקנה: עלינו לוודא שניתנה הדעת  לשני הנושאים הבאים:
Fallback –
 כלומר אם לא הצלחנו בדרך א' יש לנסות דרך ב'.
Rollback -
 במידה וההתקנה פשוט לא מצליחה - אפשר לחזור בבטחה למצב טרום ההתקנה.
ברור שאנו לא רוצים להגיע לאף אחד מהמצבים הללו, אך עלינו להיערך להם.
מבחינת הבדיקות זה "סיוט" לבדוק התקנה טובה (דווקא!), כלומר בנוייה היטב, של מערכת גדולה, כי כמות ה-fallbacks וה-rollbacks היא אדירה. כל שרת בתת-מערכת לחוד, ואולי גם ביחד של כל אחד מהמצבים האלה. יש לבצע כמובן אופטימיזציה וניהול סיכונים.

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



מצ"ב צ'ק ליסט לעקרונות בדיקת התקנות:
דיוק:
כמו בבכל TD - ההתקנה עובדת בהתאם לדרישות.
בהירות:
1.                  המונחים וראשי התיבות שמשתמשים בהם בתהליך ההתקנה מוסברים.
2.                  שפה ברורה ותמציתית.
3.                  הפעולות והתוצאות ברורות וחד משמעיות.
4.                  ישנן תמונות להמחשה כולל סימנים בתמונות שיבהורו בדיוק מה יש לעשות.
5.                  אם ישנן כמה אפשרויות – להסביר כל אפשרות ובמה היא שונה מהאחרות.
שלמות:
1.                  שום צעד אינו חסר.
2.                  הצעדים הם לפי הסדר (חשוב מאוד!)
3.                  דרישות הקדם מצויינות.
4.                  שגיאות אפשריות ופרוצדורות של recovery מצויינות במסמך.
5.                  ציון של כמה זמן אמור לקחת כל תהליך.
6.                  הסבר של שיטות ההתקנה (ידניות, הרצות של exe וכד')
קונסיסטנטיות
1.                  פנה את קהל היעד שלך כיאות (אם אלו אינם אנשים טכניים אל תצפה שיבינו מונחים כמו batch file לדוגמא).
2.                  הפעולות והתוצאות כתובות בצורה עקבית עם הפירוט המתאים, ובאותו פורמט.
3.                  התהליך והמעבר בין הנושאים הם לוגיים, אין קפיצות מנושא לנושא.
תצורה גראפית:
1.                  Toolbars , תפריטים, פקודות ואפשרויות פועלים בדיוק כמו במסמך.
2.                  ברירות המחדל במסמך וב-GUI זהות.
3.                  דוגמאות מתועדות נכון.
ארגון:
1.                  יש אזכור של מסמכים קשורים.
2.                  מטרות כל תהליך מוסברות.
3.                  יש overview של ההתקנה.
4.                  לא יותר מ-10 עד 15 צעדים בכל פרוצדורה.
5.                  הצעדים ממוספרים.
6.                  מינימום של פעולות ידניות.
7.                  יש מקום להערות וחתימה של הבודק.
8.                  להכניס הסברים מפורטים על כל צעד זה מבורך, אבל לא במסמך עצמו - יש מי שמעוניין פשוט להתקין! לכן אפשר להשאיר קישור לנספח ולרשום שם את הפירוט - מי שרוצה שילך לשם.
9.                  המשך של #8: אפשר ורצוי גם לתת טיפים. את זה אפשר להשאיר ליד המקום הרלוונטי, אבל בקצרה ובפורמט וצבע שונים עם תיוג ברור.
סטייל:
1.                  נראה מקצועי.
2.                  משתמש במונחים מקצועיים.

יום רביעי, 9 באפריל 2008

צ'ק ליסט לכתיבת מסמך בדיקות (STD Checklist)

הרשימה הסופית כוללת תוספות רבות של קובי הלפרין כפי שהופיעו כאן.
Preparations and format:
01. Were all the requirements identified and listed while preparing the TD?
02. Does the traceability matrix exist as a part of the document or referenced from the TD?
03. Is every requirement covered by at least one test group in the TD?
04. Was the TD written in accordance with the template?
05. Was the TD written in accordance with the guidelines in the Test Approach document?
06. Are all the test groups and test cases uniquely identified?
07. Is the naming convention used consistent throughout the document?
08. Was the Doc Revision Change Control filled properly?
09. Are the Testing Gear properly identified?
a. Tool specifications.
b. Scripts and debug tools.
c. Information that should be found in logs.
10. Are some of the tests defined as being done not in a clean environmet to identify integration and other parts influances?
11. Are all related documents mentioned and linked?
12. Are there Definitions & Abbreviations to all the terminology in the document?
13. Are all the topics that will be tested and will not be tested defined in the document?
14. Is there any reference to documantation tests (Help windows, User Manual & Installation Manual)?
15. Are there any TBD issues?
16. Was the Speller run? Were all needed updated values updated (e.g. TOC)?
17. Does the document include diversity (users, ports, slots etc)?

Test groups:
18. Were all the test groups and test cases defined in accordance with system impacts (Installability, Integrity, Security, Performance, Maintainabilility, Serviceability, Update/Migration, Documentation, Usability, Standards, Reliability, Requirements, Capability?)
19. Were all the test groups and test cases defined in accordance with triggers (Functional, Startup/Restart, Recovery/Exception, Redundancy Failover, Hardware configuration, Software configuration?)
20. Does every test group contain at least one test case?
21. Does each test group test one specific requirement?
22. Is every test group verified under different conditions/inputs/scenarios?
23. Is the testing method described clearly for each test group (to the level that will enable the reviewer to understand how the test cases will be executed and how the results will be evaluated?)

24. Does the test method for each test group include criteria for
evaluating tests results?
Test Cases:
25. Are the test cases classified according to applicable test types (Positive Test Case, Negative Test Case - about 30%, Boundaries Test Case, End Cases)?
26. Are there tast cases designed to detect problems between the tested feature and other features / sub-systems of the system?
27. Does each test case include the purpose of the test?
28. Are the test cases for the same test group testing the same requirement under different conditions?
29. Are the test groups and test cases designed in bug revealing orientation (we are testing in order to find bugs and not to show that it works?)
30. Do the tests cases have priority based on the product (e.g. complexity) and version (e.g. feature X as milestome for a customer)?
31. Do the test groups include separate test cases for positive, negative, boundary checks?
32. Do the test groups include separate test cases for end cases?
a. Were test cases with
special input values (empty file, empty message, etc) defined?
b. Were test cases defined for testing functionality under
abnormal conditions (no communication between two components, temporarily no connection to data base, etc)?
c. Were test cases with
illegal input values defined?
33. Were complicated and not only trivial scenarios defined for test case execution (for example, several users performing actions or contradictory actions, like one user deposing a message, while the subscriber is deleted, or depositing a message while another message is deposit and causes exceeding the message quota)?
34. Are the test objectives described clearly for each test group?
35. Was test results evaluation defined (at least considered) by more than one method (for example, visual observation of user’s handset, activity log record and relevant log file record?)
36. Does every test case have preparations and setup (either stated implicitly or referenced to the test group or whole TD preparations and setup?)
37. Are issues of error handling addressed?
38. Were test cases with default input values defined?
39. Was test cases dependency eliminated (can each test case run independently and not dependent of execution of other test cases)?
40. For test cases that have specific preparations and setup, was a return to initial conditions defined upon end of execution (to eliminate dependency)?
41. Were test cases defined in order to check data integrity (data loss in case of errors, failures?)
42. Were test cases defined in order to check data consistency (in case of flow errors, for example?)
43. Were test cases defined to check rollback in case of flow error?
44. Were test groups and test cases that are relevant only for specific version identified and marked as such (the idea is to have one TD for a sub-system/service/feature for all versions and test cases that are not relevant for this version can be easily identified and not executed?)
45. Are the expected test results for each test case specific and unambiguous (you understand exactly what to expect from the test results and if everything works correct, you will always expect the same results?)
46. Where we use the same set of steps (e.g. checking text fields): is it written only once with reference?
47. Where we use the same set of parameters (e.g. checking configuration files): is it written only once with reference?
48. Do all test cases include running time estimation (before the first run it is a ragh estimation, will be updated if needed after the first run)?

Test Steps:
49. Are the actions (steps) in the test procedure specific and unambiguous?
50. Do the steps include only relevant actions for test execution and are not mixed with test preparations and setup?
51. Are the test procedures brief (5-10 steps. If not, you are probably testing several things at once?)
52. Wherever a range of values (including in the test gear) can be used - is it included in the tests?

רשומות פופולריות