הקפצץ שרשור לחיות את חייה

[אבי ע]

לחיות את חייה(של איכות התוכנה)../images/Emo39.gif

בחיי כל תוכנה חייבים להיות מספר שלבים כדי שתצליח. מערכת אבטחת איכות התוכנה (SQA) אמורה ללוות אותם כל הדרך למטה מהדרישות (שבשמיים...) ועד לכתיבת הקוד של כל מודול או Unit, ובחזרה למעלה דרך העמדת המערכת השלימה ועד קבלתה על ידי הלקוח שהציב את הדרישות. זהו מודל V Shape הידוע, שהשלבים הראשונים בו עשויים להפתיע את מי שלא מכיר... 1. תחילת בדיקת התוכנה היא בבדיקה של הדרישות (Requirement) עצמן, ובעיקר בדיקת המיפרט הפונקציונלי (FS – Functional Specification) ביחס אליהן. בנוסף לבדיקה טכנית של קיום התאמה פורמלית מלאה (Traceability Matrix) בין הסעיפים, עלינו לבדוק שאכן כל סעיף במיפרט עונה על הדרישה המתאימה, וכמובן שכל הדרישות מכוסות. 2. השלב הבא במורד ה-V הוא בדיקת התאמת העיצוב המערכת (High Level Design = System Design) למיפרט הנ"ל, באותו אופן. שני השלבים האלו, שתכופות מדלגים עליהם, הם השלבים בהם בקרת איכות התוכנה היא היעילה ביותר! עלות תיקונו של באג המתגלה בשלבים אלו היא לעתים כעלות מחיקת שורה מודפסת והדפסת שורה אחרת במקומה... ובמקרים קשים יותר, תכנון מחדש של חלק מהמערכת. אותו באג עצמו, אם יתגלה לאחר כתיבת הקוד והאינטגרציה, תיקונו עשוי לעלות הון ועדיין לא לספק לגמרי את הדרישה המקורית בגלל אילוצי זמן וסיבוכיות. מיותר לציין שלביצוע שלבים אלו אין שום כלי טכני שיסייע לבודק האיכות, אלא רק יכולתו להבין את המערכת כמכלול ואת פרטיה, ולשאול את השאלות הנכונות. 3. השלב הבא הוא בדרך כלל באחריות המתכנתים, וזו בדיקת כל מודול או יחידת קוד עצמאית (Unit Test) מול העיצוב המפורט (Detailed Design) שנגזר מעיצוב המערכת. בקטע זה המתכנת חייב לרוב להיות גם איש איכות ולבצע את הבדיקה. תפקיד ה-QA הוא לוודא את ביצוע הבדיקה, למשל על ידי הטמעת נהלים של ביצוע ודיווח Unit Test. כאן הושלם השלב הפרטני, ה"נמוך" ביותר (טכנית) של כתיבת הקוד ובדיקתו לאור הדרישות.

 

[אבי ע]

לחיות את חייה ב' ../images/Emo39.gif../images/Emo39.gif

עתה אנו חוזרים ומטפסים במעלה ה-V של חיי התוכנה, וכאן מתחילות בדיקות האיכות ה"רגילות": 4. בדיקות אינטגרציה ומערכת (שהמהדרין מפרידים ביניהן). התוכנה נבדקת תחילה על כך שהיא עושה את מה שהיא אמורה לעשות (לפי המיפרט). זאת, על סמך מסמכי בדיקות שתוכננו (STP) בשלב 1 לעיל, ונכתבו במפורט (STD) בשלב 2. במקביל ובהמשך, נבדקת התוכנה על כך שהיא לא עושה את מה שאינה אמורה לעשות (לקרוס,למשל, לאחר ביצוע פעולות מסויימות...). חלק זה הוא לרוב יצירתי יותר, וכולל מגוון טכניקות כיד היצירתיות הטובה על הבודק, ולאור נסיונו עם נקודות תורפה בתוכנה בכלל, בסוג התוכנה הספציפי, ואצל המתכנתים הספציפיים אותם הוא בודק. בדיקות אלה נעשות במספר מחזורים של הוצאת גרסאות מתוקנות ובדיקתן מחדש, עד לאישור של גרסא סופית – רצוי לאור אמות מידה ברורות (אפס באגים קריטיים וחמורים, רמה נסבלת - ומוגדרת - של באגים חמורים פחות). בכך מסתיימת בקרת האיכות הפנימית של המוצר. 5. כאשר המוצר, או חבילת מוצרים מותאמת במיוחד (Customized), מסופקים ללקוח, נדרש שלב נוסף של מבדקי קבלה לצורך אישורו. הללו מקבילים למבדקים הפנימיים, כאשר תוכנית הבדיקות (ATP) ותיאורן המפורט (ATD) הוכנו ואושרו מראש. בכך נסגר המעגל כאשר מראים ללקוח לשביעות רצונו כי כל הדרישות הראשוניות (מסעיף 1 לעיל) נבדקו ונמצא שעמדנו בהן (לקוח מקצועי יבצע בעצמו את הבדיקות, ויוסיף עליהן בדיקות חופשיות לאיתור נקודות התורפה). הבנה נכונה של כלל מחזור חיי התוכנה והבדיקות, ובפרט של חשיבות השלבים הראשונים שתיארתי כבסיס לכל השאר, היא המפתח למערכת יעילה של אבטחת איכות תוכנה. לצערנו, הבנה זו אינה נחלת הכלל אפילו בקהילת ה-SQA, ועוד פחות מכך במחלקות האחרות בחברות התוכנה. אבל אנו יכולים לנסות לטפח אותה, כשהרווח על כך עשוי להיות ממשי מאד.

 

[erandd]

מוסיף למאמרים

 

[אבי ע]

יכול לשלוח לך את קבצי וורד המקוריים

יודע מה, אני אוסיף אותם היום מחר באיזה מסר.

 

[Scott]

אולי יהיה אפשר להמיר אותם ל-PDF

או PS? בבקשה?

 

[erandd]

לדעתי לא ניתן

מברר עם תפוז כלי האדמין מאפשרים רק HTML

 

[אבי ע]

מילה על זכויות... ../images/Emo39.gif

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

תודה

 

[erandd]

בסדר גמור

מוסיף למסמכים

 

[Scott]

עם HTML אין בעיה ../images/Emo13.gif תודה

 

[ScrollLock]

רגע - חסרים לי כמה דברים

- מה עם התייחסות למודל של -Waterfall ? - ישנו ה-Boehm’s Spiral Model (אמנם משנת 1987 אבל עדיין תקף...) שהוא קצת פחות בעייתי מה Waterfall ולדעתי הוא מחייב התייחסות רצינית. - מה עם התייחסות ל-Incremental model? - מה עם Sawtooth Model של Rowen מ-1990 שהופך להיות נפוץ בלא מעט פרוייקטים? - ישנו גם -Shark Tooth Model (דומה במקצת ל-Sawtooth) - יש את Synchronize and stabilize model שנמצא בשימוש במיקרוסופט - וישנו גם ה-Issue-Based Life Cycle Model שהוא (לצערנו) כנראה הנפוץ מכולם... ואם כבר במודלים עסקינן, מה עם איזה "איזכורון" של ה- (1995)ISO 12207 שהוא הסטנדרט של ISO ל-Software Life Cycles או של IEEE 1074:1997 (המקביל של IEEE)? ישנם כמובן עוד כמה מודלים (לא הכרחיים) שלא הזכרתי אבל אני מניח שזה כבר נושא לדיונים אחרים. ישנו הדף הזה: http://cs.wwc.edu/~aabyan/435/Process.html שנותן לדעתי תיאור טבלאי קצרצר ולא רע בכלל של כל מה שקשור לתהליכי פיתוח תוכנה, וישנו גם: http://www.cs.ualberta.ca/~kenw/courses/2003/cmput401/lectures/04.pdf שנותן פרזנטציה קצרה על התהליכים השונים. שווה קפיצה. והגישה שלי לגבי מודל ספציפי- מודל הוא עניין אינדיבידואלי למדי - לדעתי אין שום מודל שהוא "מחוייב" כשזה מגיע ל-SDLC. כל ארגון צריך לעבוד על פי מה שמתאים לו ורק אם בשלב מאוחר יותר ישנו צורך להצהיר על מודל פורמלי. רק אם יש צורך ממשי לתקינה ספציפית, אפשר לחפש למה אפשר להסתנכרן במינימום השקעה.

 

[אבי ע]

תשובה ראשונית... ../images/Emo39.gif

ראשית, תודה להתייחסות המפורטת

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

 

[אבי ע]

המשך... ואליך, נועל הגלילה... ../images/Emo13.gif

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

אקדים ואומר שלא הבנתי בדיוק למה הזכרת את ISO 12207, התקן האירופי שאומץ דומתני בידי האמריקאים ב-1995 ושמקבילתו האמריקאית היא IEEE 1074 משנת 1997 (למי שאינם יודעי ח"ן, מדובר בשני ארגוני תקינה מרכזיים בעולם). התקנים הללו קובעים שהארגון הרוצה לעמוד בהם צריך לפעול לפי מודל של מחזור חיים לפיתוח תוכנה (Software Development Life Cycle - SDLC), אך למיטב הבנתי אינם כופים מודל מסויים על הארגון מבקש התקן. כך שלא מדובר פה במודל חלופי, אלא רק בכך שעצם ההתנהלות לפי מודל כזה מחוייבת בתקנים. אם הבנתך שונה, אנא האר את עיני. מודל ה-V שהצגתי הוא בעיני המודל הבסיסי (תאורטית) שכל האחרים הם הרחבות שלו. לאחר שהוא הובן והופנם, אפשר לעדן אותו דרך אחת הוריאציות שהזכרת, או אחת מאלה שלא הזכרת...

מודל המפל הוא פשוט הצגה חזותית שגויה (לדעתי) של מודל V. את אותם השלבים מציגים אחרת באופן גראפי, לאורך קו יורד כאילו אין התייחסות אחורה (או רק לשלב הקודם, יש הצגות שונות של המודל הזה). אבל הטקסט של השלבים כולל בעצם התייחסות (לא מספיק סיסטמתית) לשלבים הקודמים. המודלים ה"ספירליים" של בֵּהְם, הן המקורי משלהי שנות השמונים (למה דוקא 87, אגב? הפרסום ה"רשמי" הוא במאמר מ-88 וספר מ-89) והן פיתוחו באמצע שנות התשעים, מתאימים בעיקר לפיתוח פנימי של מוצר (לא מול לקוח) ובקנה מידה גדול. בכל אחד משלבי ההכנה מבצעים אימות וניתוח סיכונים מחודש (כך שבכל שלב אפשר גם לבטל את הפיתוח). הדגש שאני שמתי על שלבי ההכנה הוא כאפס וכאין לעומת מה שבמודל זה (ולא ריאלי במרבית המקרים שאני מכיר, אלא אולי באמת בארגוני ענק). החצי השני של התהליך, היינו עצם כתיבת הקוד ובדיקתו, זוכים להתייחסות מועטה למדי. אמנם אפשר להניח שתכנון מדוקדק יקטין סיכונים בשלב זה, אבל עדיין. המודלים ה"משוננים" שמים דגש על היבט שלא נגעתי בו, בניגוד לבהם דווקא בדגש על עבודה מול לקוח חיצוני. חשוב להדגיש שהם בדיוק מודל V קלאסי כמו שהצגתי, עם פחות דגש על שלבי האימות בין "זרועות" ה-V ועם אלמנט חשוב של כמה הצגות אבטיפוס (Prototype) ללקוח החיצוני בכל אחד מהשלבים שהזכרתי (במודל ה"משור"), ובנוסף לכך גם שלבי בקרה של ההנהלה הפנימית (ב"שיני הכריש"). מה שנוטים להתעלם ממנו בנושא הצגות האבטיפוס (שתאורטית הינו חיובי, כמובן) הוא שבחיים האמיתיים לא תרשה לעצמך גם באבטיפוס להכשל מול לקוח חיצוני, כך שכל יציאת אבטיפוס מחייבת מחזור V שלם ומלא בפני עצמו, זהה לחלוטין למחזור שתיארתי למעט העובדה שהדרישות מצומצמות יותר. קביעה זו נכונה גם לגבי המודל האינקרמנטלי (יש מילה עברית מתאימה?), שעיקרו מוכנות מהירה להוציא משהו (חלקי אבל עובד) בכל פרק זמן חלקי מתוך כלל זמן הפיתוח. בשנים האחרונות גדלה, לפחות מצד הלקוחות שאני מכיר, הדרישה להדגמות (Demo) ואף לפיילוטים, שכמוהם כהצגת אבטיפוס. אבל מבחינתי התוצאה בכל מקרה היא פשוט מודל V אחד או יותר לפיילוט (או לשלבי משנה), ועוד אחד למערכת המבצעית הסופית. על "סנכרן וייצב" של מיקרוסופט ועל מודלים אחרים אפסח כרגע, אם תרצה תוכל להרחיב אתה. ולבסוף, לטענה הנכונה והשגורה למדי ששום מודל אינו "מחייב". נכון, אבל גם טענה מסוכנת כי התוצאה המעשית היא תכופות, ובודאי בארצנו עם אופיה הלאומי המיוחד (לטוב ולרע), שאין שום עבודה שיטתית. הברדק חוגג, והאילתור שאנחנו מעולים בו מנוצל כדי לחפות על זה, במקום לנצל אותו להתמודדות עם ההפתעות שהחיים האמיתיים מזמנים גם כשאתה עובד מסודר. או כאמרה הישנה של המודד הותיק לשוליה: "אתה תעבוד ישר. עקום זה ייצא גם בלי עזרתך...". לכן, מודל ה-V שהצגתי בצורתו הבסיסית ביותר ראוי לדעתי להיות דגם ראשוני בכל תהליך של פיתוח ובדיקת תוכנה. אם הארגון צלח מעבר לו, לאחת הוריאציות או אחד הפיתוחים שהזכרנו, מה טוב. אם לא, לפחות יהיה בסיס מינימלי לפיתוח מסודר ולבדיקות מסודרות ואפקטיביות. Dixi אבי

(יצא כפול באורך ממה שתכננתי, אבל מילא)

 

[ScrollLock]

OK, הגישה שלי (חלק א')

ראשית, ברשותך, התייחסות נקודתית לכמה נושאים שהעלית: 1. הסיבה שהזכרתי את ISO 12207 ואת IEEE1074 (שהם אגב פחות או יותר זהים), היא שלדעתי הם ראויים לאיזכור אם ב-Lifeclycle עסקינן. הסטנדרטים הללו, בדומה לכל ה-ISOים, אינם מגדירים מודל ספציפי אלא רק צורה רעיונית של מודל. ד"א – למקרה שעדיין לא ציינתי – הסטנדרטים הללו הם ככל הנראה חופשיים מכיוון שהתפוצה שלהם על האינטרנט היא נרחבת למדי. 2. מודל המפל הוא אינו הצגה שגוייה יותר מכל מודל אחר. שוב, כפי שציננו כבר בעבר – כל פרוייקט והמודל שלו (התייחסות בהמשך). 3. המודל של בהם יצא לאור לראשונה בשנת 87 אולם רק ב-88 יצא המאמר הרשמי ובו כל התיזה. לגבי מודלים של פיתוח: קצת רקע: כיום אני עובד בבית תוכנה שעושה OUTSOURCING של תוכנה עבור חברות שלא רוצות או לא יכולות לפתח תוכנה בעצמן, ומעצם טבע הדברים אני עובד מול מספר פרוייקטים (שונים לחלוטין אחד מהשני) במקביל. בעבר, הרצתי פרוייקטים ב- "בית התוכנה הגדול בעולם" (לא מה שמקובל לחשוב – זהו דווקא יצרן חומרה...) וגם שם עבדתי מול מספר פרוייקטים במקביל רק ששם סדרי הגודל היו שונים "במקצת". לגבי המודליזציה של הפיתוח: אני ממש לא מייחס חשיבות מעשית למודל הפיתוח. מבחינתי, כל עוד יש סדר בבלגאן – הכל יכול להמשיך לרוץ. לא מעניין אותי אם זה יהיה מפל מים בצורת V, שיני כריש או דג זהב בניאגרה. כל עוד הצוות מודע למה שהוא עושה – Keep on doing your great job. בארגון הגדול שעבדתי בו, בימים שטרום ימי התפוצצות הבועה, המודל היה פשוט מאוד – המהנדסים והגורואים (הטכנולוגיים) היו יושבים ומגבשים רעיון, לאחר מכן מתארים וכותבים (!) אותו לפרטי פרטיו והתוצאה היתה כמה אלפי דפים מודפסים עם תיאור מאוד פרטני ומדוקדק של הפרוייקט. כל הדפים בצירוף משימות היו הופכים לחוברות עבות שהיו מחולקות בין כל המתכנתים וההנדסאים שהיו מבצעים את האימפלמנטציה עצמה. משם הכל היה יורד לוריפיקציה ובסוף התהליך, כשהכל היה מושלם – אז היו עושים את הולידציה (וכמובן אחריה redesign ופיתוח מחדש של המוצר). ככה זה כשיש כסף – אפשר לשרוף אותו על שטויות... כיום, המגמה קצת השתנתה ויש נטייה מסוימת לבצע ולידציות באמצע התהליך אבל עדיין – יש הרבה מקום לשיפורים. מ-א-י-ד-ך בארגון שבו אני עובד כיום, הצוותים הם קטנים מאוד והנטיה היא לעבוד מה שיותר מהר ויעיל. המתכננים הם המהנדסים והם לרוב גם המבצעים, לכן הם חושבים פעמיים לפני יישום של כל שלב. מבחינת מודל – כל פרוייקט והמודל שלו. אני מודה שלעיתים זה יוצא משליטה אבל אין מה לעשות – זו המציאות. הלקוח רוצה שהמוצר יהיה מוכן אתמול והמציאות מכתיבה את האילוצים. מתודולוגיה? קשורה בחוץ אוכלת עשב...

 

[ScrollLock]

הגישה שלי (חלק ב')

איך זה עובד אצלנו (לרוב): ברגע שללקוח חדש יש רעיון, הוא פונה אלינו ובפגישה הראשונה אנחנו רק מקשיבים ומגבשים דיעה ראשונית (לטוב ולרע). לאחר מכן, הלקוח יושב להכין את ה-Marketing Requirements שלו שרלוונטיים מבחינתי (Software Marketing Requirements) שזה בעצם הבסיס ל-SRS שאותו אני מכין, לעיתים בשיתוף עם אחד המפתחים. ישנם גם Marketing Requirements שלא נוגעים אלי אבל הם מופיעים ב-Template שאני נותן ללקוח ולרוב אני ממליץ להתיחס גם אליהם, בעיקר כדי ליעל את תהליך ה-Risk Analysis. לרוב מדובר בצדדים שקשורים יותר ל-Resources כגון הקצאת אנשים, חומרה מיוחדת (אם יש צורך) ושיקולי מימון. בשלב הזה ולמעשה גם בשלבים הבאים, ה-QA הוא מעין מתורגמן בין שפת "בני אנוש" לבין שפת המתכנתים. זו אחת הסיבות שלדעתי מבהירה את החשיבות שלאנשי QA (לא QC) יהיה כמפתחים. ברגע שיש SRS מוכן, אנחנו מציגים אותו ללקוח, עם הסברים "בשפת בני אנוש" ומיד לאחר האישור – ניגשים לתכנון ראשוני ולהתחלת פיתוח. לרוב אנחנו מדלגים על תכנון יסודי כדי לחסוך זמן, במיוחד בפרוייקטים קצרים. רק אם יש צורך מיוחד (כגון פרוייקטים של תכנות רפואי) מבצעים Design יסודי, אבל מנסיון – תכנון לחוד וביצוע לחוד. אנחנו משתדלים להימנע מבניית Demoים או אבטיפוסים גם בדי לחסוך זמן וגם כדי לא לגרום ללקוח ולנו להיתפס לקונספציות שעשויות להתגלות כשגויות. ולידציה אנחנו עושים תוך כדי עבודה, בעיקר כדי לוודא שאין חריגות קיצוניות מדרישות הלקוח והתהליך מבוצע בסיומו של כל Feature. בפרוייקטים שמיועדים לעמוד בתקני ISO או FDA, ישנו גם Risk Analysis שמבוצע מתחילת התהליך ועד סופו. הלאה – בשלב ה-coding לרוב אין ל-QA מה להתערב יותר מדי. המתכנתים שומרים אחד על השני מבחינת Coding Conventions ומעבר לזה אני לא רואה סיבה להציק להם. וריפיקציות... פה בעצם ישנם שני תהליכים מקבילים – המתכנתים כותבים את ה- Automated Test Scripts ואת ה-Unit Tests (אם יש צורך) וה-QC מבצעים את הבדיקות לתהליכי הקצה לרוב אלו כבר Black Box Testing. הבדיקות האלו נועדו למעשה למצוא את המצבים שהתוכנה לא תוכננה לעמוד בהם או למצוא בעיות שעלולות לצוץ במצבים מאוד ספציפיים שעלולים לצוץ (אם כי לעיתים נדירות). זהו פחות או יותר. מרגע שכל הבדיקות שלנו הושלמו, המוצר יורד עם Test Results ללקוח שלנו לסבב בדיקות אצלו. לרוב ישנם פידבקים ואנחנו חוזרים אח"כ לסבבי תיקונים ושיחרורים (פינג-פונג) אחד או שנים (או עשרה) ובסופו של דבר הלקוח מרוצה ממה שיש לו ביד והוא יכול לרוץ עם זה לשוק. צריך לזכור שחלק מהתהליכים אצלנו הם לעיתים קצרצרים - ישנם פרוייקטים שלמים שמרגע יצירת הקשר הראשון עם הלקוח ועד לשחרור המוצר הסופי עובר לא יותר משבוע עבודה. ישנם גם פרוייקטים שרצים כבר 6-7 שנים (אבולוציה של גרסאות) אבל הם מועטים. ולסיכום: שתי מילים לגבי עמידה בסטנדרטים – בפרוייקטים מסויימים אנחנו מחוייבים לעמוד בסטנדרטים המחמירים ביותר, ללא פשרות. השאלה הפתוחה היא – עד כמה אפשר לכופף את הסטנדרטים הללו לצרכינו. מנסיון – סטנדרטים זה דבר גמיש. מאוד!

 

[אבי ע]

תודה על התשובה המפורטת ../images/Emo39.gif

והפעם בשמך המקצועי

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

 

[ScrollLock]

המממ...

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

 

[erandd]

אקרונימים לאבי

מנסה ליצור משהו, כשיהיה גמור נפרסם פה

 

[erandd]

הקפצץ שרשור לחיות את חייה

לפי בקשת אבי