נהלי פיתוח בחברה שאתם עובדים בה – מבחינת QA?

פורומים אפיון ופיתוח פריוריטי נהלי פיתוח בחברה שאתם עובדים בה – מבחינת QA?

  • Post
    snoof123
    משתתף
    שלום,
    אני מעוניין להתייעץ בנוגע להיקף הQA שאתם משקיעים בפיתוחים שלכם.

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

    אשמח לקרוא ולהעריך בעקבות התגובות מה מקובל בשוק הפריוריטי..

    תודה לעוזרים 🙂

מוצגות 7 תגובות – 1 עד 7 (מתוך 7 סה״כ)
  • Replies
    אלמוני
    אורח
    הנושא הזה מאד מעניין אותי מאחר והנושא החדש לדוקטורט שלי (הראשון נכשל עקב מיעוט משתתפים) מתעסק בתהליך לביצוע שיפורים, אם כי יותר בצד הניהולי של הנושא ופחות בתהליך הפיתוח עצמו.
    אלמוני
    אורח
    היי,
    אני יכול להעיד כמובן רק על עצמי ורק על 12 שנותיי בפריוריטי שאני מעדיף לבדוק את הפיתוחים שנעשו לאפיונים שלי בעצמי.
    רק אחרי שאני שבע רצון אני מעביר למשתמשים וגם רק לאלו שהם יותר טובים ושיכולים לתת לי פידבק רציני.
    snoof123
    משתתף
    אני מניח שרוב מפתחי הפריוריטי מבצעים QA בעצמם, אבל באילו עוד פלטפורמות פיתוח המתכנת עושה QA לעצמו ומעלה גירסה לפרודקשן?
    PriorityDev
    משתתף
    IL
    בוודאי שהמציאות היא שרובם ככולם בודקים בעצמם, גם בחברות יישום יחסית גדולות.

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

    האם מישהו פיתח מתודולוגיה לבדיקות בפריוריטי?
    קשה להאמין.

    snoof123
    משתתף
    מה לגבי בדיקות קבלה?
    איך אתם מבצעים בדיקות קבלה מול יוזרים?
    האם אתם מציעים אחריות לפיתוחים לתקופה מסוימת?
    גם במסגרת האפיון, או מקרים שלא הועלו באפיון ועלו לאחר הגשת הפיתוח למשתמשים?
    PriorityDev
    משתתף
    IL
    בס"ד

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

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

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

    yitzchok
    משתתף
    IL
    אני חושב שהמושג של אחריות באה כי המתכנת מטבע הדברים עובר במשך הזמן לדברים אחרים.
    קביעת תקופת אחריות מטרתה היא לזרז את הלקוח לבדוק את הפיתוח בתוך הזמן בו המתכנת המקורי עוד יזכור על מה מדובר ויוכל לתקן את הבאגים יחסית בקלות.
    לאחר התקופה הזאת כל טיפול הוא בתשלום: 1. זה עושה את הויכוח אם באג אם שינוי באפיון מיותר – יודעים שבכל מצב משלמים ו-2. גם אם זה באג זה פיצוי למתכנת על ההשקעה הנוספת שנדרשת לחזור לפיתוח הישן לאחר תקופה של ניתוק ממנו.

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

    עד כמה שאני זוכר בתקופה שעבדנו ככה זה היה די מוצלח
    בדיקות של משתמש סופי היו קשות להשיג ובגלל שהיינו in-house היה יותר קל גם לבדוק בעצמנו
    מקווה שזה לעניין!

      [ בבקשה לא לשלוח הודעות פרטיות במערכת - אני לא קורא אותן ]
מוצגות 7 תגובות – 1 עד 7 (מתוך 7 סה״כ)
  • יש להתחבר למערכת על מנת להגיב.