בקרוב מאמר: מה ללמוד כדי להיות QA
- פותח הנושא erandd
- פורסם בתאריך
מדעי המחשב?!
האמת? נראה לי מאוד כללי, ואפילו מאוד יומרני. כלומר, מדעי המחשב תמיד יכול להיות בסיס טוב, אבל למי שלא רוצה ללמוד תואר ראשון ורוצה לעסוק בבדיקות ישנן המון דרכים ואפשרויות. כמו בתכנות, תחום הבדיקות הוא תחום רחב, אני אפילו אעז ואגרור אותו מכוון אחד אל תחום של Technical Writing ותחום של System Engineering ומהצד השני של הסקאלה ניתן למצוא את הבדיקות האוטומטיות למיניהן, שמגיעות עד לרמת תכנות. בכל אחד ממגוון אפשרויות אלה, ישנם עשרות תחומים שונים, תקשורת, Billing, White Box QA, בדיקות GUI, ועוד ועוד. לכן (IMHO) לבוא ולומר "צריך ללמוד X, או צריך ללמוד Y" זה פשוט יומרני.
האמת? נראה לי מאוד כללי, ואפילו מאוד יומרני. כלומר, מדעי המחשב תמיד יכול להיות בסיס טוב, אבל למי שלא רוצה ללמוד תואר ראשון ורוצה לעסוק בבדיקות ישנן המון דרכים ואפשרויות. כמו בתכנות, תחום הבדיקות הוא תחום רחב, אני אפילו אעז ואגרור אותו מכוון אחד אל תחום של Technical Writing ותחום של System Engineering ומהצד השני של הסקאלה ניתן למצוא את הבדיקות האוטומטיות למיניהן, שמגיעות עד לרמת תכנות. בכל אחד ממגוון אפשרויות אלה, ישנם עשרות תחומים שונים, תקשורת, Billing, White Box QA, בדיקות GUI, ועוד ועוד. לכן (IMHO) לבוא ולומר "צריך ללמוד X, או צריך ללמוד Y" זה פשוט יומרני.
שלא לדבר על בדיקות usability
שבהן ההתמחות היא בעיקר בפסיכולוגיה קוגנטיבית ועוד ועוד. לדעתי, כדאי ללמוד כמה דברים כללים שקשורים לבדיקות תוכנה, אבל להתמקד בעיקר בלימוד בתחום הספציפי אליו מתמחים. אני לדוגמא עוסקת בעיקר בבדיקות לוקליזציה וגלובליזציה, אז מן הסתם אני צריכה לדעת הרבה על קידודים, יוניקוד, ופונטים, ושפות שונות במחשבים וכו' בעוד שאצטרך לדעת יחסית מעט על איך לבדוק עומסים ו- race conditions (כי את זה בדרך כלל בודק צוות אחר).
שבהן ההתמחות היא בעיקר בפסיכולוגיה קוגנטיבית ועוד ועוד. לדעתי, כדאי ללמוד כמה דברים כללים שקשורים לבדיקות תוכנה, אבל להתמקד בעיקר בלימוד בתחום הספציפי אליו מתמחים. אני לדוגמא עוסקת בעיקר בבדיקות לוקליזציה וגלובליזציה, אז מן הסתם אני צריכה לדעת הרבה על קידודים, יוניקוד, ופונטים, ושפות שונות במחשבים וכו' בעוד שאצטרך לדעת יחסית מעט על איך לבדוק עומסים ו- race conditions (כי את זה בדרך כלל בודק צוות אחר).
וזה כמובן מתקשר לדברים הבאים:
1. התקנות מחשב בשפות שונות 2. GHOST והחלפת מערכות הפעלה במהירות כדי שתוכלי לבדוק במהירות שפות שונות בקונסטלציות שונות 3. בסיסי נתונים ואחזקת תוכן בצורה שלא יזדהה כתו זר 4. XML בשפות שונות (כמובן אם יש, דורש בדיקות לוקליזציה. גרמנית עם תוויה המוזרים גורמת לXML לא להתפרסס) ויש עוד המון, אשמח לשמוע מה.
1. התקנות מחשב בשפות שונות 2. GHOST והחלפת מערכות הפעלה במהירות כדי שתוכלי לבדוק במהירות שפות שונות בקונסטלציות שונות 3. בסיסי נתונים ואחזקת תוכן בצורה שלא יזדהה כתו זר 4. XML בשפות שונות (כמובן אם יש, דורש בדיקות לוקליזציה. גרמנית עם תוויה המוזרים גורמת לXML לא להתפרסס) ויש עוד המון, אשמח לשמוע מה.
אה, אבל אני לא עובדת רק עם חלונות
אז זה אומר גם לדעת איך מערכות הפעלה שונות מתייחסות לשפות שונות, מה הוא סופרסט של מה כך שאפשר להמיר בקלות, ומה הוא מקבילה של מה. זה אומר לדעת איך להגדיר הגדרות לוקל במערכות הפעלה שונות, ולדעת את ההבדל וההשפעה של ההגדרות השונות. זה אומר לדעת איך לעבוד עם פריסות מקלדת שונות, והרבה פעמים מה הבעיות הנפוצות בפריסות מקלדת מסויימות (דברים שמתכנתים שלא דוברים את השפה נוטים לפספס, כמו alt+gr בשפות מזרח אירופה מסויימות). כמובן זה אומר להכיר אזורים בעייתיים נוספים בשפות שונות: ליגטורות בערבית, כל ה- bidi algoritem, העובדה ששפות כמו גרמנית לוקחות יותר תווים מאשר אנגלית כך שיש סיכוי רב שיהיו חלקים חתוכים בטקסט וכו' וכו'. זה אומר לדעת לעבוד עם המקלדת, כי יצא לך לעבוד במערכת הפעלה עם ממשק שאתה לא יודע לקרוא (מישהו רוצה מקינטוש בתורכית, או חלונות בצ'כית? יש לי עותקים
) זה אומר לדעת עברית ברמה גבוהה- כדי שיהיה אפשר לזהות שגיאות תרגום בדברים המתורגמים לעברית. בהזדמנות זו הייתי רוצה להמליץ על כמה קישורים: האתר של ריצ'רד אישידה, המתעסק בבינאום ב- w3c, המכיל מאמרים מענינים בנושאים שונים הקשורים לבינאום: http://www.w3.org/People/Ishida/writing.html i18n gurus: אינדקס אתרים העוסקים בבינאום ולוקליזציה http://www.i18ngurus.com/ בחנו את עצמכם: האם אתם יכולים לאתר את כל הבאגים שיש בגירסה הגרמנית של תיבת הדו שיח (הנמצאת ליד הגירסה האנגלית המקורית)? http://www.theverybestofstuff.de/localization/loctest1.html
אז זה אומר גם לדעת איך מערכות הפעלה שונות מתייחסות לשפות שונות, מה הוא סופרסט של מה כך שאפשר להמיר בקלות, ומה הוא מקבילה של מה. זה אומר לדעת איך להגדיר הגדרות לוקל במערכות הפעלה שונות, ולדעת את ההבדל וההשפעה של ההגדרות השונות. זה אומר לדעת איך לעבוד עם פריסות מקלדת שונות, והרבה פעמים מה הבעיות הנפוצות בפריסות מקלדת מסויימות (דברים שמתכנתים שלא דוברים את השפה נוטים לפספס, כמו alt+gr בשפות מזרח אירופה מסויימות). כמובן זה אומר להכיר אזורים בעייתיים נוספים בשפות שונות: ליגטורות בערבית, כל ה- bidi algoritem, העובדה ששפות כמו גרמנית לוקחות יותר תווים מאשר אנגלית כך שיש סיכוי רב שיהיו חלקים חתוכים בטקסט וכו' וכו'. זה אומר לדעת לעבוד עם המקלדת, כי יצא לך לעבוד במערכת הפעלה עם ממשק שאתה לא יודע לקרוא (מישהו רוצה מקינטוש בתורכית, או חלונות בצ'כית? יש לי עותקים
אולי...
אבל יש יותר מקומות עבודה שדורשים את התואר במדעי המחשב. הסיבה הפשוטה, היא הוכחת יכולת למידה, רקע מתאים, וידע תיאורתי (אם לא מעשי). נכון שלאחר מספר שנות נסיון הייתרון הזה מצטמצם, אבל באופן שיטתי, מקומות עבודה יעדיפו מישהו שלמד על אחר שלא. נכון שזהו לא הקריטריון היחיד, לאופי של הבנאדם, יכולת ההשתלבות שלו בחברה (גם חברתית וגם מקצועית) ואיזור מגוריו יש השפעה, אבל בד"כ לאותו אחד (או אחת) שמחפש עבודה יהיה קל יותר עם תואר במדעי המחשב. מעבר לכך, לדעתי, דווקא הכיוון של למידת כמה שיותר כלים הוא זה שפחות יעיל. אם "למדת" לעבוד עם באגזילה ודווקא לאיפה שאתה הולך עובדים עם תוכנות של Rational? בייחוד אם אתה חסר נסיון, צריך להכיר מס' מצומצם של תוכנות, אשר יכסו מגוון של נושאים (תיעוד, דיווח, הסטוריה, כלי אוטומטי כזה או אחר), כיוון שברגע שהקונספט של העבודה ברור, הכלי נעשה זניח. הכרת המתודולוגיות, חשובה הרבה יותר מאשר הכלי בה ישתמשו כדי לממש אותן.
אבל יש יותר מקומות עבודה שדורשים את התואר במדעי המחשב. הסיבה הפשוטה, היא הוכחת יכולת למידה, רקע מתאים, וידע תיאורתי (אם לא מעשי). נכון שלאחר מספר שנות נסיון הייתרון הזה מצטמצם, אבל באופן שיטתי, מקומות עבודה יעדיפו מישהו שלמד על אחר שלא. נכון שזהו לא הקריטריון היחיד, לאופי של הבנאדם, יכולת ההשתלבות שלו בחברה (גם חברתית וגם מקצועית) ואיזור מגוריו יש השפעה, אבל בד"כ לאותו אחד (או אחת) שמחפש עבודה יהיה קל יותר עם תואר במדעי המחשב. מעבר לכך, לדעתי, דווקא הכיוון של למידת כמה שיותר כלים הוא זה שפחות יעיל. אם "למדת" לעבוד עם באגזילה ודווקא לאיפה שאתה הולך עובדים עם תוכנות של Rational? בייחוד אם אתה חסר נסיון, צריך להכיר מס' מצומצם של תוכנות, אשר יכסו מגוון של נושאים (תיעוד, דיווח, הסטוריה, כלי אוטומטי כזה או אחר), כיוון שברגע שהקונספט של העבודה ברור, הכלי נעשה זניח. הכרת המתודולוגיות, חשובה הרבה יותר מאשר הכלי בה ישתמשו כדי לממש אותן.
כלים לטעמי הוא דבר שפחות חשוב ללמוד
יצא לי לעבוד עם באגזילה, עם מערכת הבאגים הפנימית של מיקרוסופט, ועם מערכת הבאגים של אדובי. שלוש מערכות שונות לגמרי, על פלטפורמות שונות. אבל, ברגע שאתה מבין את העקרון ויודע איך לעבוד עם אחת, קל מאוד לעבור לעבוד עם מערכת אחרת. כנ"ל עם כלים אחרים. דיסקליימר: אין לי תואר כלשהו, כך שמן הסתם דעתי מושפעת מעובדה זו. בנוסף, הנסיון שלי הוא בעיקר בדיקת יישומי דסקטופ צרכניים, כך שגם כאן, יש מן הסתם השפעה על הדעה שלי. מה כדאי שיהיה לאיש בדיקות תוכנה? * פדנטיות ושימת לב לפרטים קטנים. ככה רואים הרבה יותר באגים
וככה מתעדים את העבודה הרבה יותר טוב- תוכניות בדיקה, מפרטי בדיקות וכו' * נסיון ויכולת טובים בפתרון בעיות במחשב. הכלים שמשמשים לפתרון בעיות, פעמים רבות משמשים לבידוד באגים. * יכולת ללמוד מהר ולבד. פעמים רבות אנשי הבדיקות צריכים להתחיל לעבוד על מוצר חדש כשאין עדיין תיעוד מספיק, והם צריכים להתחיל לבדוק אותו ולהתחיל ללמוד אותו בו זמנית. * כושר ניתוח והפשטה: שיסייע לעשות הכללות היכן שצריך, ובכך ליצור דיווחי באגים טובים יותר (למשל, על ידי זיהוי איזה סמפטום ראוי לבחינה יותר לעומק, וכך גילוי של באג כללי יותר * כשרון דפלומטי: שיאפשר ליצור ולשמור על יחסים טובים ומועילים עם צוות הפיתוח, למרות שאתם יום יום בעצם אומרים כמה עבודתם לוקה בחסר
* כושר ניסוח ותמצות בכתב- כדי שיהיה אפשר להבין מה לעזאזל ניסיתם לומר בדיווח הבאג שלכם...
יצא לי לעבוד עם באגזילה, עם מערכת הבאגים הפנימית של מיקרוסופט, ועם מערכת הבאגים של אדובי. שלוש מערכות שונות לגמרי, על פלטפורמות שונות. אבל, ברגע שאתה מבין את העקרון ויודע איך לעבוד עם אחת, קל מאוד לעבור לעבוד עם מערכת אחרת. כנ"ל עם כלים אחרים. דיסקליימר: אין לי תואר כלשהו, כך שמן הסתם דעתי מושפעת מעובדה זו. בנוסף, הנסיון שלי הוא בעיקר בדיקת יישומי דסקטופ צרכניים, כך שגם כאן, יש מן הסתם השפעה על הדעה שלי. מה כדאי שיהיה לאיש בדיקות תוכנה? * פדנטיות ושימת לב לפרטים קטנים. ככה רואים הרבה יותר באגים
שאלה טובה
לדעתי לא משתי סיבות עיקריות: 1. מאוד חשוב שבמהלך הפרויקט ישמור איש הQA דיסטנס מסוים מהתכנים, אתה אמור לספק ראיה אוביקטיבית על הפרויקט ותכניו ומעורבות שלך בתכנים תפגע באוביקטיביות זו 2. החלטה על פתרון צריכה לבוא מהפיתוח ומאנשי המוצר (אשר בקשר עם הלקוח) אתה אמור להאיר את עיניהם על בעיות של שימוש אבל לא להציע פתרון אשר לא מתאים למסמך הספציפיקציות. אתה כן אמור לציין שפתרון מסוים לא מתאים למסמך זה.
לדעתי לא משתי סיבות עיקריות: 1. מאוד חשוב שבמהלך הפרויקט ישמור איש הQA דיסטנס מסוים מהתכנים, אתה אמור לספק ראיה אוביקטיבית על הפרויקט ותכניו ומעורבות שלך בתכנים תפגע באוביקטיביות זו 2. החלטה על פתרון צריכה לבוא מהפיתוח ומאנשי המוצר (אשר בקשר עם הלקוח) אתה אמור להאיר את עיניהם על בעיות של שימוש אבל לא להציע פתרון אשר לא מתאים למסמך הספציפיקציות. אתה כן אמור לציין שפתרון מסוים לא מתאים למסמך זה.
מאוד תלוי
בתור התחלה, הפתרון ממש לא צריך לבוא מצוות הפיתוח. אנשי המוצר ואנשי ה-Field הם אכן אלה שצריכים להעלות פתרונות. אבל במקרה שבו המוצר מפותח ועדיין לא נמכר לאף לקוח, יש חשיבות גדולה ל-QA, שכן הוא כרגע "הלקוח" העיקרי והוא זה שלמעשה "טוחן" את המוצר ומשתמש בו. נכון שהרעיון לפתרון לא יישלח בצורה של "זה מה שצריך לעשות" אלא בצורה של הצעה תוך שיתוף מתכנני המע'.
בתור התחלה, הפתרון ממש לא צריך לבוא מצוות הפיתוח. אנשי המוצר ואנשי ה-Field הם אכן אלה שצריכים להעלות פתרונות. אבל במקרה שבו המוצר מפותח ועדיין לא נמכר לאף לקוח, יש חשיבות גדולה ל-QA, שכן הוא כרגע "הלקוח" העיקרי והוא זה שלמעשה "טוחן" את המוצר ומשתמש בו. נכון שהרעיון לפתרון לא יישלח בצורה של "זה מה שצריך לעשות" אלא בצורה של הצעה תוך שיתוף מתכנני המע'.
הממ...
נכון אומרים שמתכנתים לעולם לא יוכלו לבדוק את העבודה שלהם? אז אין ספק שזה נכון, אבל אני בתור איש הSYSTEM של המוצר גם לא יכול לגמרי לבדוק את המוצר כי אני לא dumb user, אז זה יוצר עוד בעיה, דברים שלי נראים מובנים מאליו לא מובנים כלל לקהל היעד של המוצר (dumb userים קלאסים). בשביל להתגבר על הבעיה הזאתי יש לי שתי לקוחות עתידיים שלהם נתתי גישה למוצר והם נותנים לי feedbackים, בעיקרון זה עובד יופי בשבילי. זה מביא אותי לשאלה של איך אנשי QA שזו היא עבודתם אמורים "לרדת" לרמה של dumb users ולראות דרך עינהם?
נכון אומרים שמתכנתים לעולם לא יוכלו לבדוק את העבודה שלהם? אז אין ספק שזה נכון, אבל אני בתור איש הSYSTEM של המוצר גם לא יכול לגמרי לבדוק את המוצר כי אני לא dumb user, אז זה יוצר עוד בעיה, דברים שלי נראים מובנים מאליו לא מובנים כלל לקהל היעד של המוצר (dumb userים קלאסים). בשביל להתגבר על הבעיה הזאתי יש לי שתי לקוחות עתידיים שלהם נתתי גישה למוצר והם נותנים לי feedbackים, בעיקרון זה עובד יופי בשבילי. זה מביא אותי לשאלה של איך אנשי QA שזו היא עבודתם אמורים "לרדת" לרמה של dumb users ולראות דרך עינהם?
התשובה היא פשוטה
אבל מסובכת יותר לביצוע. כלומר, אנשי QA מעורבים בד"כ ביותר חלקי תוכנה מאשר צוותים שונים של תוכניתנים, ולכן ניתן לומר שגם אם אינם מכירים את הפונקציות למיניהן, הם מכירים את המע' עליה הם עובדים על בוריה, וברור שכך, שכן הם צריכים לבדוק את המע' בפינות, ובד"כ הם אלה שצריכים למצוא את ה"פינות" הללו, כדי להגיע לאותן הפינות, מה שצריך זה בד"כ הוא עצירת פעולת הבדיקה ופשוט "לקחת את הזמן" בניתוח המע' והבנה איפה נקודות החולשה שלה ואיך ניתן "להתקיל" אותה שם. כדי להבין ולמצוא את מה שרואים ה-Dumb users, יש צורך בהאטת התהליכים (שאותם אנחנו בד"כ מבצעים פעמים רבות, לעיתים עד שהם נהפכים אוטומטית) ועל כל פעולה (או קבוצת פעולות) שמבצעים פשוט לשאול "למה אני עושה את זה", כלומר "לצאת מהקופסה" ולהתנהג באופן זר לגמרי למערכת, כאילו זו הפעם הראשונה שרואים אותה. אין ספק שישנם פרמטרים שגם אנשי הפיתוח וגם מהנדסי המערכת לא חשבו עליהם עד הסוף (לעיתים אפילו לא חשבו עליהם בכלל) וע"י התנהגות כזו ניתן לעלות על אותן נקודות.
אבל מסובכת יותר לביצוע. כלומר, אנשי QA מעורבים בד"כ ביותר חלקי תוכנה מאשר צוותים שונים של תוכניתנים, ולכן ניתן לומר שגם אם אינם מכירים את הפונקציות למיניהן, הם מכירים את המע' עליה הם עובדים על בוריה, וברור שכך, שכן הם צריכים לבדוק את המע' בפינות, ובד"כ הם אלה שצריכים למצוא את ה"פינות" הללו, כדי להגיע לאותן הפינות, מה שצריך זה בד"כ הוא עצירת פעולת הבדיקה ופשוט "לקחת את הזמן" בניתוח המע' והבנה איפה נקודות החולשה שלה ואיך ניתן "להתקיל" אותה שם. כדי להבין ולמצוא את מה שרואים ה-Dumb users, יש צורך בהאטת התהליכים (שאותם אנחנו בד"כ מבצעים פעמים רבות, לעיתים עד שהם נהפכים אוטומטית) ועל כל פעולה (או קבוצת פעולות) שמבצעים פשוט לשאול "למה אני עושה את זה", כלומר "לצאת מהקופסה" ולהתנהג באופן זר לגמרי למערכת, כאילו זו הפעם הראשונה שרואים אותה. אין ספק שישנם פרמטרים שגם אנשי הפיתוח וגם מהנדסי המערכת לא חשבו עליהם עד הסוף (לעיתים אפילו לא חשבו עליהם בכלל) וע"י התנהגות כזו ניתן לעלות על אותן נקודות.
ScrollLock
New member
וזה אולי המקום לדון בהסמכות?
לכמה מכם יש CSQE או CSQM?
לכמה מכם יש CSQE או CSQM?
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.