לגלישה באתר בגירסה המותאמת לסלולאר
| הוספת הודעה
הגדרות תצוגה

הגדרות עץ הודעות

מאפייני צפייה

הצג טקסט בתצוגה
הצג תגובות באופן
עדכן
1128711,287 עוקבים אודות עסקים

פורום בקרת איכות תוכנה - QA

פורום זה עוסק בתחום בקרת איכות תוכנה, בדיקות תוכנה ו- QA. שאיפתי היא שהוא יהווה מקור ידע לאנשי ומנהלי QA ובדיקות שרוצים לחלוק פרוצדורות ומתודולוגיות. כמו כן יוכל לתמוך בשאלות הנוגעות בכלים וטכנולוגיות ושיטות עבודה. לבסוף יוכל לתת טיפים כיצד להתנהל מול אנשי פיתוח ומה נחוץ כדי שעבודה זו תהיה חלקה ונעימה ככל האפשר. אלו הם כמובן רק חלק מהנושאים שיכולים להופיע. פורום זה יקדם כל כיוון אחר אפשרי ויקבל בברכה כל חומר או לינק שיכולים לקדם אותו (זהירות עם זכויות יוצרים).
בכדי לעזור לכם לקבל את העדכונים המעניינים בצורה נוחה - יצרנו מס' כלים להצפת המידע:
קב' בפייסבוק: http://www.facebook.com/groups/405915096141090
דף בגוגל+
https://plus.google.com/b/101407766666630341390/101407766666630341390/posts

הנהלת הפורום:

אודות הפורום בקרת איכות תוכנה - QA

פורום זה עוסק בתחום בקרת איכות תוכנה, בדיקות תוכנה ו- QA. שאיפתי היא שהוא יהווה מקור ידע לאנשי ומנהלי QA ובדיקות שרוצים לחלוק פרוצדורות ומתודולוגיות. כמו כן יוכל לתמוך בשאלות הנוגעות בכלים וטכנולוגיות ושיטות עבודה. לבסוף יוכל לתת טיפים כיצד להתנהל מול אנשי פיתוח ומה נחוץ כדי שעבודה זו תהיה חלקה ונעימה ככל האפשר. אלו הם כמובן רק חלק מהנושאים שיכולים להופיע. פורום זה יקדם כל כיוון אחר אפשרי ויקבל בברכה כל חומר או לינק שיכולים לקדם אותו (זהירות עם זכויות יוצרים).
בכדי לעזור לכם לקבל את העדכונים המעניינים בצורה נוחה - יצרנו מס' כלים להצפת המידע:
קב' בפייסבוק: http://www.facebook.com/groups/405915096141090
דף בגוגל+
https://plus.google.com/b/101407766666630341390/101407766666630341390/posts
x
הודעה מהנהלת הפורום
כללי התנהגות בפורום
כולנו, אני מאוד מקווה , רוצים שהפורום יהיה מקצועי, תרבותי וכזה שנעים לגלוש בו. שכל מי שרוצה לשאול שאלה , ישאל מבלי להסס ומבלי לפחד מתשובה מתנשאת , מעליבה כו'.
כדי להבטיח רמה גבוהה של דיונים אני מבקש מכל הגולשים להימנע מכל סוג של הערות אישיות, הבעת דעה או ביקורת אישית על גולש אחר. הפורום הוא מקצועי וטכני. 
 
 
הודעות אשר יכילו הערה אישית כלפי גולש אחר יימחקו  ללא קשר לתוכן הנוסף שיהיה בהן.
 
המשך >>

לצפיה ב-'צ'ק ליסט לכתיבת TD'
צ'ק ליסט לכתיבת TD
<< ההודעה הנוכחית
08/04/2008 | 21:20
12
1356
לצפיה ב-'באופן כללי - לא רע.'
באופן כללי - לא רע.
08/04/2008 | 22:46
11
46
אני יוצא מנק' הנחה כי בתבנית המסמך יש הגדרה של אזורי בדיקה סטנדרטיים (כמו עומס, פונקציונליות, Maintainability , recovery, Upgrade וכד' - אם נכתב בכלי ניהול, אז רצוי שיהיה מבוסס על מבנה עץ עליון אחיד).
אישית אני מעדיף מבחינת תחביר כי במקום Are the יהיה כתוב Do the, אבל גם אני לא דובר אנגלית כשפת אם...
(+לפחות שגיאת כתיב אמיתית אחת שword מציין)

אני לרוב מעדיף כי הבדיקות ימופו מלכתחילה למס' שלבי בדיקה - Document wide Sanity, Some minor stressing & comlicate scenario, הבדיקות הרחבות, רגרסייה (רצוי כמקרים מורכבים לחסכון בזמן).

Negative Test cases - הוזכרו בסעיפים שונים, יש אומרים כי על כל בדיקה חיובית, ניתן למצוא לפחות 5 בדיקות שליליות

לוודא שלכל בדיקה יש תיאור purpose ברור (מתאר בקצרה את כוונת המשורר כמטרת הבדיקה), שאינו זהה לשם הבדיקה.

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

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

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

האם מקרים בעלי סט צעדים זהה, מתוארים פעם אחת בלבד + הפנייה לערכים בטבלה? (מקל על קריאה, תחזוקה, review).

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

האם המסמך נכתב בצורה שתאפשר יצירה מהירה של מסמך תוצאות? (האם גם אחרי כל שינוי נוכל לחולל מסמך תוצאות מותאם בקלות?) (לא נדרש במקרה של שימוש ב-DB לניהול הבדיקות)

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

ב-26# האם התכוונת באמת למילה exciding או ל- exceeding?
רצוי לבנות גם מקרים מורכבים ע"י שימוש בטכניקות של Use Case Scenarios.
רצוי שחלק מהבדיקות יתבצע בצורה מתמשכת וללא ניקוי מלא, כי לעיתים רק אז מופיעות בעיות של שילוב והשפעות הדדיות.

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

האם טבלת ה-Doc Revision Change Control מולאה כראוי ?

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

האם יש Definitions & Abbreviations לכל המושגים היחודיים ?
(ניתן לבדוק spelling מול קובץ מילון נקי - שלא הוכנסו בו המילים אותן אותו כותב לימד את הSpeller)

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

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

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

האם יש התייחסות לבדיקת( Documentation – (Help windows, User Manual & Installation Manual)

האם הורץ Speller ?   >>>>    להעביר לתחילת הדף  

נשמח לראות רשימה סופית בבלוגך - תודה

קובי
בקרת איכות תוכנה - QA >>
לצפיה ב-'אוווופס -מצטער על המגילה -אפילו לא מספרתי'
אוווופס -מצטער על המגילה -אפילו לא מספרתי
08/04/2008 | 23:01
23
לצפיה ב-'מרפרוף ראשוני'
מרפרוף ראשוני
09/04/2008 | 10:05
3
19
נראה שרוב רובם של הדברים שהוספת אכן צריכים להתווסף. ישנם דברים כמו צב"דים שמקומם לדעתי מתאים יותר ל-STP.
בכל מקרה אני אעיין יותר לעומק מייד כשאוכל.

נב. לגבי האנגלית, אני יושב ליד חדר מלא באנגלו-סקסיות (אתה רואה באילו תנאים אני עובד?) אז הן יעברו על המסמך. בכל מקרה השגיאות ש-Word מוצא אינן שגיאות אמיתיות, אלו פשוט מונחים מהתחום שהוא לא מזהה.
בקרת איכות תוכנה - QA >>
לצפיה ב-'עכשיו אני מבין למה אתה שר '
עכשיו אני מבין למה אתה שר
09/04/2008 | 12:36
2
10
צב"ד הינו חלק בלתי נפרד מהקונפיגורציה, ומהנחיות הביצוע המפורטות, ולכן בהחלט חלק ממסמך הבדיקות המפורט
בקרת איכות תוכנה - QA >>
לצפיה ב-'גם לגבי צב"ד אפשר להפעיל שיקול דעת'
גם לגבי צב"ד אפשר להפעיל שיקול דעת
09/04/2008 | 13:08
1
8
כתבתי מסמך שאיפשר את השימוש בארבעה מריצי תנועה (IP) שונים והיו עוד בתהליכי רכישה, השארתי לבודק ולזמינות לקבוע במה להשתמש ורק נתתי פירוט של הפרמטרים הרלבנטיים.
בקרת איכות תוכנה - QA >>
לצפיה ב-'אכן - פתרון מעולה - בעבר הכנסנו דבר דומה לאוט'
אכן - פתרון מעולה - בעבר הכנסנו דבר דומה לאוט
09/04/2008 | 19:47
11
אני חושב שרשמתי זאת כבר בפורום, לגבי המלצה להשתמש באבסטרקציה ופרמטרים של קונפיגורציה - כך ניתן לאחר מכן לקבוע את הצב"ד הספציפי או את נתוני ה-UUT וכד' בזמן ריצה, ולשנות בין ריצות או עמדות שבודקות במקביל.

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

מסיבה דומה רשמתי גם לתאר הקונפיגורציה המינימלית, ולהוסיף הרחבות אופציונליות - מחד חוסך בציוד ומאידך מראה שניתן גם להרחיב במידה ויש ציוד פנוי או עמדה נרחבת יותר.
בקרת איכות תוכנה - QA >>
לצפיה ב-'קראתי בפירוט'
קראתי בפירוט
09/04/2008 | 19:43
5
20
אז ככה:
א. תשובותי במסמך מצורף.
ב. בעקבות הערותיך ברור לי מה אני צריך להוסיף - אעשה זאת בימים הקרובים.
ג. באתר שלי קצת סידרתי והדגשתי מילות מפתח, בכדי להקל על המשתמשים.
ד. נראה לי שזה לא מעניין את רוב האנשים כאן
בקרת איכות תוכנה - QA >>
לצפיה ב-'הבלוג שלך בהחלט נחמד, במקרה נכנסתי השבוע'
הבלוג שלך בהחלט נחמד, במקרה נכנסתי השבוע
09/04/2008 | 19:54
2
12
והשארתי הערה או שתיים על דברים שנראו יותר חשובים.

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

כמו כן, כפי שאתה רואה בודקים אינם עם עירני מדיי (אוי ואבוי אפילו הפכו זכר לנקבה...) - ולכן אולי תדגיש ותצבע חתימה... - או תפרט מה ניתן למצוא בבלוג.
בקרת איכות תוכנה - QA >>
לצפיה ב-'תודה עבור המחמאה'
תודה עבור המחמאה
10/04/2008 | 03:44
5
איחוד אתרים דורש זמן וישיבות והחלטות משותפות... לבן אדם עובד זה קשה בתור תחביב. חוצמזה אני אוהב את השליטה (מודה). בכל מקרה אני מעדכן ככל הניתן.
לגבי התנועה באתר, מצד אחד זה נכון שאני נהנה כשאנשים נכנסים ומגיבים (נב ראיתי את הערותיך והגבתי להן), אבל מצד שני אני לא רוצה ל"התמסחר" ולהתחיל להכניס שיקולי רייטינג לתוכן או לענות להודעות בפורום למשל רק בכדי לפרסם את האתר. זה אתר שנועד בעיקר לעצמי, ואם אנשים יכנסו - מעולה!
בכל מקרה אם יש לך חומר שתרצה לפרסם באתר אשמח (כמובן עם כל הקרדיט).

נ.ב. אם בודקים אינים עם ערני מידי - אז מי כן?
בקרת איכות תוכנה - QA >>
לצפיה ב-'אם testingreflections היה תומך עברית'
אם testingreflections היה תומך עברית
10/04/2008 | 09:09
5
testingreflections מרכז בלוגים למקום אחד.
בקרת איכות תוכנה - QA >>
לצפיה ב-'תגובות לתגובותיך.... - סליחה אבל מתעצל בword'
תגובות לתגובותיך.... - סליחה אבל מתעצל בword
09/04/2008 | 20:24
1
11
אני לרוב מעדיף כי הבדיקות ימופו מלכתחילה למס' שלבי בדיקה - Document wide Sanity, Some minor stressing & complicate scenario, הבדיקות הרחבות, רגרסייה (רצוי כמקרים מורכבים לחסכון בזמן).
>>כאן מדובר בצ'ק ליסט של כתיבת TD לכן תמיד פרוגרסייה. כל הדברים לדעתי הם חלקים לא מתוך מסמך הבדיקות אלא מה-STP.
>>>> לדעתי TD אמור לכלול את כל שלבי הבדיקה שמתוכננים ב-STP, ולרוב מיותר לחלק למס' TD שונים לכל שלב (בעיקר כי הרבה פעמים נעזרים בבדיקות של שלב אחד לשלבים אחרים)
שים לב כי לרוב אנשים פשוט קוראים מסמך, או מבצעים אותו בצורה סידרתית - מדף 1, 2 ...273.
לעומת זאת בשביל תפוקה יעילה, משוב פורה למפתחים וכן הלאה - רצוי לדלג תחילה בין נושאים, להציף בעיות ראשוניות, ולחזור לבדיקה מקיפה רק לאחר שתיקנו מרבית הבעיות. (בינתיים בודקים עוד 2 נושאים ורק אז חוזרים)

לוודא שלכל בדיקה יש תיאור purpose ברור
>>21. Are the test objectives described clearly for each test group? נראה לי מכסה
>>>> לא ברור לי למה רק לכל  test group? ולא לכל בדיקה בודדת.

האם המסמך נכתב בצורה שתאפשר יצירה מהירה של מסמך תוצאות? (האם גם אחרי כל שינוי נוכל לחולל מסמך תוצאות מותאם בקלות?) (לא נדרש במקרה של שימוש ב-DB לניהול הבדיקות)
>>לא ברור לי.. יש PASS / FAIK, לא?
>>>> אני בהחלט מעדיף שלא לציין תוצאות על מסמך הTD, אלא במסמך קצר בהרבה של Test Report - מי שרוצה לקרוא תוצאות לא רוצה לקרוא את המסמך המלא אלא רק כותרות, נוסיף לכך שחלקים שונים מבוצעים על תת גירסאות שונות וכד' - הרבה יותר קל לרשום בנפרד.
איך עושים? נדמה לי שכתבתי לא מזמן בפורום, אבל אוכל לכתוב שוב.

Use Case Scenarios
>>לא מכיר, אשמח לשמוע
>>>> על רגל אחת: כותבים מעין סיפור על אופן השימוש באפליקצייה (לדוגמא לסלולרי: יוסי קם בבוקר, מדליק הסלולרי, מגיעות לו 7 הודעות מהלילה, לא קורא אותן, יוצא לרכב, שם בדיבורית, קורא 2 הודעות, מגיע למשרד, נכנס למעלית וכמעט מאבד קליטה, נכנס למפגש חברה עם עוד 200איש שכמובן לא כיבו הסלולרי....    או נוחת בשדה התעופה ומדליק הסלולרי עם עוד 400 ישראלים תוך כדי נסיעה על המסלול, מתוכם 20% בפלאפון CDMA, ו60% בפרטנר שעלול להתנגש עם 20% בסלקום כי שניהם GSM), ועכשיו כותבים בדיקה שמסמלצת הסיפור.
מגיעים לשילובים שבצורה רגילה לא היינו חושבים לבדוק, ומצד שני ניתן לקבוע אילו תסריטים יותר רלוונטיים ואילו פחות חשובים לביצוע.

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

האם הורץ Speller ?   >>>>    להעביר לתחילת הדף  
>> צודק ב-100%! ועדכון של ה-TOC
>>>> הדרך הטובה ביותר שמצאתי בכדי לוודא שגם שדות בכותרות המסמך יעודכנו (דבר שהבאגים של ביל לא עושים), היא להדפיס כאשר אופציית עדכון השדות בהדפסה מופעלת (כמובן מספיק להדפיס לקובץ)
כך מגיעים לשילוב פעילויות של תכונות שונות במערכת, במקרים אמיתיים.
בקרת איכות תוכנה - QA >>
לצפיה ב-'אז סליחה גם כן'
אז סליחה גם כן
10/04/2008 | 03:36
6
אבל אפנה אותך כבר לבלוג שלי, כי הפורמט שם יהיה יותר ברור
בקרת איכות תוכנה - QA >>
כתובות אינטרנט מצורפות:

הודעות אחרונות

חם בפורומים של תפוז

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

מקרא סימנים

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