איך להיות בודק תוכנה: מראיון למציאת הבאג הראשון

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

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

ראיון

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

לדוגמה, לשאול שאלות יוצאי דופן כדי לראות איך אדם חושב:

• המטוס יוצא מנקודה A בשעה 17:00, ומגיע לנקודה B בשעה 19:00. הוא בטיסה במשך שלוש שעות. למה זה יכול להיות?
• כיצד לוודא כי, לאחר שקיבלו את היישום המעודכן, המתחרים לא יכלו ללמוד את הפונקציות החדשות שלה?

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

גם עבור הראיון יהיה שימושי:

1. כדי לבחון את סוגי הבדיקות: בדיקות פונקציונליות ומחקריות, בדיקות אוטומטיות (כולל כלים עבורו), מתח ובדיקות מתח, בדיקות עשן.
2. בנוסף, קרא על בדיקות הקבלה ועל הקריטריונים שלה.
3. אם אנחנו מדברים על בדיקות יישומי אינטרנט, אז זה קונסולת הדפדפן ואת עבודתה, מספר וגירסאות של דפדפנים, לפקח על החלטות, כלי פיקסל לשכלול.
4. אם אנחנו מדברים על יישומים ניידים, אלה הם סוגים של פלטפורמות, emulators, בדיקות קופים. אל תשכח את הלוחות.
5. כדי ללמוד את סוגי עוקבי באגים. הפופולרי ביותר: ג’ירה, BugZilla, RedMine, גמל שלמה. לראות איך הם עובדים, מה המומחיות שלהם.
6. מנקודת המבט, הכלים הם Jmeter, פוסטמן, צ ‘ארלס. הם לא מאוד קשה לשלוט ברמה בסיסית.

יום עבודה ראשון

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

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

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

המשימה הראשונה

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

קח את היוזמה. אם לא קיבלת רשימת תיוג של היישום, לא לחכות, אבל לשאול את זה מן המורה. אם לארגון יש רשימת תיוג, אתה יכול לכתוב את זה בעצמך. בחברה שלנו, רשימת הסימון היא לעתים קרובות יותר ב- “Google Sheets”. להלן נתנו דוגמה של רשימת בדיקה כזו – אתה יכול לעשות את עצמו על ידי הדוגמה שלו.

עמיתים יהיה מופתע אם לקמפל רשימת בדיקה בצורת מפה של מחשבות, למשל Xmind.net.

רשימת בדיקה עבור בדיקות פוקימון GO

אחד הסוגים העיקריים של בדיקות עבור מומחה QA מתחיל, אולי, יהיה מעבר של רשימות, לבדוק מקרים של מומחים מבוגרים. שלב זה הוא הכרחי עבור טבילה מהירה יותר בפרויקט. כדי להגדיל את בסיס הבדיקה, מתחיל יכול להרחיב את הרשימה עצמה. בודקי ג’וניור הכינו גיליון לבדיקת יישום ה- Pokémon GO כחלק מהאימון בכתיבת רשימות. רק מקרים חיוביים מתוארים כאן.

הבאג הראשון במעקב

תיאור באגים בחברות שונות עשוי להשתנות, אבל באופן כללי יש עקרונות של צליל טוב.

נושא

הוא מתאר את הבעיה בכמה מילים. עדיף אם זה מתחיל עם שלילי: “לא עובד”, “לא קורה”, “טועה”, וכן הלאה. לדוגמה: “אין סנכרון עם השרת ב- iPhone 6”, “הפעלת וידאו ב- Nexus 5 אינה פועלת”.

תרחיש

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

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

בסוף הסקריפט, הסביבה שבה בוצעה הבדיקה מוצגת: גרסת היישום, הקושחה של המכשיר (Android 6.0.1, iOS 9.3.2). אם זהו יישום אינטרנט, ציין את גירסת הדפדפן.

מטרת השקית

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

מיפוי קריטי

סוגי הקריטיות של באגים ברוב המעקב מיוצגים על ידי הרשימה הבאה:

מיידי (חוסם)

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

Crit – דחוף

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

גבוהה

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

רגיל

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

נמוך

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

לימוד עצמי

כולם יודעים את החשיבות של חינוך עצמי – ההוראות שלי יהיו בנליות. אז מיד לעניין.

להלן מספר ספרים שאני אישית ממליץ לחניכים שלי:

• “בדיקת COM DOT”, רומן Savin הוא מדריך שימושי מאוד, כמעט ספר שולחן העבודה עבור בודק מתחילים. מכיל את חלק הארי של הידע כדי להתחיל בבדיקה ולהגיב בהצלחה במהלך הראיון לשאלות הנוגעות לחלק הטכני והתיאורי.
• “כיצד לבדוק ב- Google” – ספר עמוק יותר המתאר את ארגון התהליכים, אסטרטגיות וגישות שונות לבדיקה. הספר מסייע להבין מה איכות, איך ובאיזה שלבים זה יכול להיות מושפע.
• “המדריך של מדריך לעיצוב תוכנה מבחן”, לי קופלנד – הספר מתאר את סוגי בדיקות כמו “לבן”, ו “שחור” התיבה. טכניקות בדיקה שונות מפורטים, כמו גם כיצד להשתמש בהם ומתי להשתמש בהם טוב יותר. בספר ניתן למצוא מאמר מעניין על בדיקות מחקר, וזה מאוד שימושי עבור תחילת בודקי.

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

מסקנה

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

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