JIRA for Test Management

[יענקלה19]

JIRA for Test Management

שלום לכולם,

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

תודה מראש לעונים

 

[halperin]

ברוך הבא

- עד היום ראיתי בעיקר ש

מחברים את Jira לכלים אחרים התומכים בממשק זה,
ביניהם כלים חינמיים כמו XStudio בגירסתו החינמית,
נצטרך להמתין לחברים שאולי התנסו בכך.

 

[doronbar1]

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

יש שני כלים שראינו שעובדים מתוך ה-JIRA:
SuiTest ו-Zephyr
החסרון הגדול הוא שקל לקשר אותם לגרסה מסויימת אבל קשה לנהל אותם עצמאית כעץ בדיקות ולנתר בהתאם.
כנראה נבחר משהו שמתממשק עם ה-JIRA.

 

[adimor79]

בעבר כתבתי פוסט בנושא

http://moresoftwaretest.blogspot.co.il/2013/10/test-managing-tool-within-budget-limit.html

בקצרה קיים לפאגין שנקרה Zephyr for Jira שאני ממש לא ממליצה עליו, בעיקר בגלל הסיבות הבאות
- אין היררכיה בטסטים
- קשה לפלטר
- קשה לבנות test suite
- קשה לנהל גרסאות
- הממשק של ההרצה לא נח

 

[יענקלה19]

תודה על התשובה, ומספר שאלות נוספות

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

האם ניסתם לקנפג את JIRA עצמאית, ללא הפלגאין?

לגבי ממשק ההרצה - האם הטסטים הורצו בצורה אוטומטית או ידנית? האם יש אפשרות להתממשק לסביבת הרצה אוטומטית ועדכון הנתונים ב-JIRA ע״י האוטמציה?

לפי הפוסט, בסוף בחרתם ב- PractiTest, האם אתם מרוצים הכלי? את ממליצה?

הדרישות שלי מהכלי הם:
- יכולת ניהול הטסטים: הוספה, עידכון מחיקה
- קינפוג ה-workflow של טסט
- קסטומיזציה של השדות של טסט, כולל שדות מחושבים
- יכולת להריץ טסטים אוטומטיים אשר מורצים בסביבה נפרדת ועידכון התוצאות בכלי
- בניה של Test Suite
- תמיכה ב- Releases ו- Iterations

האם PractiTest תומך בדרישות הללו?

תודה!

 

[adimor79]

מאד מרוצים מ Prectitest

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

יכולת ניהול הטסטים: הוספה, עידכון מחיקה - יש גם תוך כדי הרצת טסט
קינפוג ה-workflow של טסט - לא הבנתי מה זה
קסטומיזציה של השדות של טסט, כולל שדות מחושבים -יש קסטומיזציה של שדות, לא יודעת מה זה שדות מחושבים?
יכולת להריץ טסטים אוטומטיים אשר מורצים בסביבה נפרדת ועידכון התוצאות בכלי - כן (אני בדקתי נקודתית לגבי soapUI וסליניום, אבל אפשרי גם לכלים אחרים) - כולל schedules
בניה של Test Suite - כן
תמיכה ב- Releases ו- Iterations - כן

במידה ואתה רוצה פרטים נוספים פנה אלי בפרטי

 

[yaniviny]

יש ל- PractiTest אינטגרציה עם עם JIRA

הי,
יש לנו אינטגרציה עם JIRA, וכך אתה יכול להרוויח מ-2 העולמות:
עץ בדיקות של פרקטיטסט עם כל ה-views הרלוונטיים
ובאגים ב-JIRA (למי שאוהב את JIRA..)
כאשר אתה בתוך בדיקה, ומדווח באג, PractiTest מזריקה את מה שעשית לתוך באג חדש ב-JIRA, וכאשר יש שינוי בסטטוס של הבאג ב-JIRA, ב-PractiTest רואים את זה.

אפשר לראות עוד על האינטגרציה כאן:
http://www.youtube.com/watch?v=HARCoMQ-0yY


גילוי נאות: אני עובד בפרקטיטסט

 

[יענקלה19]

הבהרה

אני לא מחפש כלי שיתממשק עם JIRA אלא רק Test managment Tool.

האם הדרישות שלי מהכלי (כמו שכתבתי בתשובה ל- adimor79) נתמכות ע״י הכלי?

 

[בודקת תוכנה]

יש מספר כלי ניהול שמתממשקים לג'ירה

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

 

[גיל בלום]

אם יניב כותב אז גם אנחנו

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

בהצלחה בכל מה שתבחר.
גיל

www.testuff.com

 

[יענקלה19]

דרישות מהכלי

הדרישות שלי מהכלי הם:
- יכולת ניהול הטסטים: הוספה, עידכון מחיקה
- קינפוג ה-workflow של טסט
- קסטומיזציה של השדות של טסט, כולל שדות מחושבים
- יכולת להריץ טסטים אוטומטיים אשר מורצים בסביבה נפרדת ועידכון התוצאות בכלי
- בניה של Test Suite
- תמיכה ב- Releases ו- Iterations

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

 

[גיל בלום]

תכונות הכלי

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

 

[יענקלה19]

SaaS

פיתרון SaaS כנראה לא יעבור אישור אצלנו

 

[גיל בלום]

SaaS כפתרון

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

 

[עמית ו]

עד כמה מחיר הוא שיקול? (בקיצור, עוד אופציה)

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

טסטים אוטומטיים:
יש לו כלי משלו בשם testRunner (נדמה לי) שהוא הגרסה שלהם לQTP.
הוא יודע להתממשק גם עם QTP
הוא מספק REST API שמאפשר לעשות לא מעט דברים.

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

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

לגבי מחיר - הכלי הזה זול יותר מQC, אבל יקר יותר מרוב הכלים האחרים שראיתי (לפחות, יקר יותר אם משלמים את מחיר maintenance) זה יוצא 1149$ פר משתמש לרכישה חד פעמית, ואז, אם רוצים, עוד 20% לכל שנה של תחזוקה.

 

[halperin]

אין בעיה לציין כלים שלכם - בהקשר רלוונטי

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

 

[ayelethd]

נצלש - למה test management?

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

תודה

 

[halperin]

כלי ניהול בדיקות - רצוי *** מהיום הראשון ***

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

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

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

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

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

 

[עמית ו]

נדמה לי שכבר אמרתי את זה מתישהו,

אבל בכל זאת, אחזור על עצמי - עדיף מוקדם, ועדיף כחלק מניהול המוצר ולא ככלי "של הבודקים".

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

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

2) impact analysis. אם יש לי קישור בין דרישות שונות, קל לי יותר להבין איך תוספת של דרישה מסויימת משפיעה על המוצר ואילו דרישות צריך לעדכן.

3) traceability - הרעיון הוא לאפשר לי לדעת בקלות יחסית אילו בדיקות צריך לעדכן בעקבות שינוי בדרישה.

4) coverage - ככה אני יכול לדעת ברמת ודאות גבוהה יותר שכיסיתי כל דרישה במקרה בדיקה אחד לפחות (ובניגוד לשלושת הסעיפים הקודמים, לא דורש ממני לשנות דברים לאחור).

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