LOGIN
התחברות או הרשמה
Avatar
להמשך הרשמה ידנית – לחץ על כפתור ההרשמה, להרשמה/כניסה מהירה בעזרת חשבון רשת חברתית – לחץ על הלוגו בכותרת

אפס סיסמה - שכחתי את שם המשתמש

שם משתמש
סיסמה
זכור אותי

he icon   en icon

Daniel Gold

Daniel Gold

ראשון, 19 פברואר 2017 07:19

Tester - tired of your job?

Tester - tired of your job?

bigstock Portrait Of Tired Young Busine 41087092

If you are a regular visitor in high tech forums, chats and facebook groups, you must have read the amount of opinions saying QA Engineering is boring.

Sadly not all QA engineers are in this profession out of love for testing. Some see it as a transition point for becoming a programmer and feel like they have compromised, while others admit that they have become bored and frustrated of their daily work and routine.

But, is testing really boring?

Every time I'm asked that question I always say that it depends on how lazy you are. In my opinion - testing is a highly interesting profession that demands from us the ability to open our minds, use our imagination and always learn new things.

If you are a lazy person who does not like to challenge yourself, exploring, thinking creatively and acquiring new skills, if you don't have the passion for always learning new technologies, do not get your personal and professional satisfaction from searching and finding bugs and defects, then testing is not for you.

With that said, every job has its down sides and it is not always an exciting and thrilling job. When the learning curve is saturated, testing does have its monotonous aspects like executing the same test cases and writing repetitive reports.

So, how do we keep the motivation flame burning? Here are some things I do to stay motivated:

·         Learn- people get bored when they are not challenged in their everyday routine. I am always passionate of learning new things. Most testers get about 2-3 hours a week as their free learning time. Use it to hit the internet in search of information. New automation tools, testing tips and methods, instructional videos and courses to improve your coding knowledge and technical skills.

·         Attend regular meet-ups conferences and workshops – try to attend in as many meet-ups as you can. In addition to the valuable knowledge you will acquire, you will meet interesting people and hear about how they manage their time and tasks. Connecting with other testers, sharing information and knowledge and just chatting with someone from your field of work is always a positive experience.

·    Guide and instruct your team members - there is an old saying: "If you cant explain it in a simple way that means you don't understand it yourself". Teaching others is a great way to develop your own skills and deepen your understanding.

·         Automate your recurring tasks – incorporate automation into your work process. Automating recurring tests is a very positive way to take the load off the manual tester and it is a great way to grow professionally and acquire highly important skills. It is also a good way to break the routine.  Suggest it to your management- it could be your initiative and work in your favor in the long term.

·         Stay away from negative people - People observe behavior and atmosphere from their surroundings, so my advice is to surround yourself with positive people that are not frustrated and still passionate about their work.

·         Set long term goals- What are your carrier goals? Where do you see yourself in 5 years? Set clear long term goals and make everyday count as you work your way to them.

·         Write about your work – Testing is a very wide field of work and every company has its own specialization. Write about your experiences, the challenges you face at work, tools you work with, write "how-to" guides and instructional articles so other testers could learn from your experience. Sharing information can help others and the feedback you will receive could help you deal with you own challenges.

·         Talk to colleges from different companies and organizations – Hear how they work, learn about different work methods that could inspire your team, tools that can make your work easier and more versatile. Updates from the industry can work magic to your own testing performance.

·         Don't get stuck in a bad place – If you feel like you are fed up, unappreciated or if you feel that you are "marching on the spot" carrier wise, try finding another work place. I always say that no amount of money is worth going home frustrated.

 

 

בדיקות חוקרות ותסריטי בדיקה – משני צדדיו של המטבע

אתחיל את המאמר הבא מתגובה שרשמתי בפורום בדיקות תוכנה בדיון על חשיבותם של Exploratory Testing בנוסף ל – Scripted:

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

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

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

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

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

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

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

יתרונות בולטים לשיטת ה- Exploratory Testing:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ולסיכום:

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

 

yazitura

 

מהמשאית לעולם הבדיקות - הדרך שלי להגשמה עצמית

שלום רב לכל מי שפינה מזמנו לקרוא את המאמר שלי.

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

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

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

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

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

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

כמו אצל כולם, הגיע העת שבה התחלתי לחשוב על לימודים.

אקצר לשלב שבו מצאתי את התחום שהתאהבתי בו מהשנייה שהבנתי את מהותו- בדיקות.

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

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

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

אבל עברתי את הלימודים, ובציונים שלא יבישו אף בוגר, ועל כך ועל הדרך לתעודה אני גאה בעצמי מאוד.

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

אז לבסוף מצאתי אותה! העבודה הראשונה שלי בבדיקות- ולא יכולתי לבקש טובה ממנה.

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

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

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

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

הרושם הראשוני היה שכולם מסביב פשוט שלווים יותר.

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

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

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

פתאום זה הלם בי כמו פטיש 10 קילו, השעה 10:00 בבוקר ואני נקי, לבוש בבגדי האישיים ועובד עם לא אחר מאשר- הראש.

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

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

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

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

התחלתי לקבל פידבקים מהמנהלים, והתחושה הייתה נהדרת.

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

אלו החיים החדשים שלי, ואני מגיע כל יום עם חיוך ענקי לעבודה!

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

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

אז למה בעצם החלטתי לכתוב את המאמר הזה? 

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

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

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

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

ועכשיו קצת על עצמי ואיך הגעתי לתחום.

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

המחשבה הזאת הובילה אותי להתייעץ ממש כמוכם עם הרבה אנשים כשהשאלה העיקרית הייתה, מה ללמוד?

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

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

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

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

אז למה בחרתי בג'ון ברייס בעצם? אני אנסה לנמק ככל הניתן.

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

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

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

הלימודים הם לא קלים ותרשו לי להוסיף ולומר שאם לא הייתי "משקיע את הנשמה" בלמידה מעבר בבית, נוכחות מלאה בשיעורים (גם עם חום 39), ספק אם הייתי מגיע למעמד חלוקת התעודות ובטח לא עם ציונים שלא יביישו אף בוגר. (100 בפרויקט האחרון ו88 במבחן ההסמכה המסכם).

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

אני יכול להגיד לכם שהתחלנו ככיתה של 30 איש ונשארנו בסוף הקורס כ-15 תלמידים שמתוכם זכאים לתעודה רק כ-10.

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

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

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

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

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

אז אנא מכם לפני שתשקיעו כסף, זמן ומאמץ תשקלו את הצעדים שלכם ואל תאמינו לכל מה שמוכרים לכם יועצי הלימודים (שהם בעצם סוכני מכירות לכל דבר).

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

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

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

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

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

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

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

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

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

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

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

תודה לכל מי שהקדיש זמן לקריאה.

מאחל לכם המון הצלחה.

דניאל.

1.12.2015

9623481 Vector illustration Cartoon funny boy and computer Stock Vector