הצעת עבודה

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

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

להלן ההגדרות המדוייקות.

1. Full time position.
2. Design tests: Understand system behavior, Cover new requirements and affected features
3. Execute tests: Run pre-defined test cases.
4. Open, analyze, track and retest defects. Identify failures, Define failures impact & severity
5. Provide status and progress reports, Summarize test results and Report testing status.

Skills
1. Independent learning ability
2. Multitasking
3. Good interpersonal relations
4. Cope with pressure conditions
5. An organized and responsible personality
6. Technical approach
7. Personal Integrity and Dedication to the profession.
8. Ability to analyze/use technical documents (Specifications, project specific documents)
9. Deep understanding of system architecture (hardware and software).
10. Intercommunication skills – ability to interact with and receive full cooperation of project members (without formal authority).
11. Both Team working and independence capabilities

Pre-Requisite
1. Internet understanding and knowledge – Mandatory.
2. Excellent Hebrew and English (Writing, Speaking) – Mandatory.
3. Experience with Windows operating systems– Mandatory.
4. Academic Degree (Science / Computers) – Advantage.
5. Experience in Software Development - Advantage.

ניתן לשלוח קו"ח למייל זה:
doronb@blogtv.com

איך לסקור מסמך בדיקות בשלושים שניות?

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

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

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

כל אחד מסעיפי הדרישה סובב סביב מונח. למשל דרישה לעורך מסמכים:

Save: the save function is design to preserve the document state as is, so the user will be able to restore it later.

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


3.  מחפשים במסמך הבדיקות את המילים הללו.

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

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

מהם הנושאים שכל בודק ווב צריך להכיר?

HTTP status codes:
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

Cookies:
http://en.wikipedia.org/wiki/HTTP_cookie

IIS:
http://searchwindowsserver.techtarget.com/definition/IIS

Internet Explorer Security Options:
http://technet.microsoft.com/en-us/library/dd346862.aspx

Advanced Options:
http://www.yoingco.com/internet_options_advanced_tab_ie8_windows_7.htm

How to Enter Proxy Settings in Internet Explorer:
http://www.wikihow.com/Enter-Proxy-Settings-in-Internet-Explorer

FF Settings:
http://kb.mozillazine.org/Firefox_:_FAQs_:_About:config_Entries

DNS:
http://computer.howstuffworks.com/dns.htm

SSL:
http://www.youtube.com/watch?v=SJJmoDZ3il8

Registry:
http://www.yoingco.com/how_to_use_the_registry_windows_7.htm

Keyboards Shortcuts:
http://support.microsoft.com/kb/126449

VM:
http://en.wikipedia.org/wiki/Virtual_machine

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1015180

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009402

XSS:
https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29

Win 8:
http://blogs.windows.com/windows/b/windowsexperience/archive/2012/02/29/introducing-windows-8-consumer-preview.aspx

IE11:
http://www.pcmag.com/article2/0,2817,2427047,00.asp

תרגול "רטוב" של כישורי הבדיקה שלכם

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

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

הלינק: http://adam.goucher.ca/parkcalc

אין דיזיין, לכן אקספלורטורי קלאסי.

כמה באגים מצאתם?

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

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

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

אם בפעם הקודמת דיברתי על התנאים להצלחה, הנה התנאים לכישלון (לנגד עיני מדובר בחברה בסה"כ רצינית, עם עובדים טובים ובעלי מוטיבציה):
1. דרישות מוצר שאינן ערות גם לפן הטכני, מסמכים שאינם ברמה גבוהה ומקצועית.
2. חוסר במסמכים מפורטים של הפיתוח.
3. חוסר בבקרה שוטפת של מנהל הפרוייקט שמעלה אף הוא את התנאים להצלחת הפרוייקט ומוודא שהם קוראים.
4. חוסר בתהליכים מסודרים של פיתוח הכוללים:
    א. ישיבות review של המסמכים של כולם.
    ב. מעבר מסודר בין הגורמים השונים (מהמוצר לפיתוח, מהפיתוח לבדיקות וכד').
5. ניהול פרוייקטים פסיבי שאינו כולל:
    א. בקרה על כל הנאמר למעלה.
    ב. וידוא שלכל צד במערכת יש את כל הנדרש בכדי להצליח (מכלים טכניים עד לזמנים).
    ג. ניהול גאנט ודוחות וכל מה שהמושג "מנהל פרוייקטים" מביא.
6. שינויים בתוכניות הן לפעמים הכרחיות ואנחנו חייבים להיות דינמיים. אבל שינויים יום-יומיים בהחלט לא מועילים לאף אחד ומצביעים על ניהול שגוי.
7. חוסר lesson learned ובכלל חוסר בגרות של אירגון ללמוד מטעויות.

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

סודות ההצלחה

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

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

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

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

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

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

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

אלו מסקנותי:

א. האימון שלנו במנהלים הבכירים, בדרך של החברה ובחזון שלה.

ב. מטרה ברורה ובת השגה (ככל שתהיה קשה) שכל החברה הייתה מחוייבת אליה.

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

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

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

ה. הידע והיכולות הטכניות שלנו.

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

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

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

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

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

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

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

והיום, מה המצב היום?
אני לא מתיימר להכיר את המצב לאשורו בארץ, ולכן סימן השאלה בכותרת. אבל אני יכול לדבר מניסיון.
אין ספק שהיום באמת כבר מוטמע בכל מפתח שהבודק הופך את הקוד שלו עצמו ליותר טוב, וחוסך לו עגמת נפש. יודעים שיש לעדכן אותנו, להתייעץ איתנו ובעצם אנו חלק אינטגרלי של הפיתוח ולא פחות או יותר טוב, גם בטכני וגם ברמה החברתית. מצויין. אז מה בכ"ז לא טוב? להלן התשובה
אני לא פגשתי יותר משניים שלשה לא רק מנהלי פיתוח, אלא גם מנהלי בדיקות, שמעניינת אותם המתודולוגיה. ישאלו אותי בראיון מה זה XML, מה זה session cookie וכד', שאלות אגב שמראות כמה מעט מצפים מאיתנו. אבל כמעט אף אחד לא שאל אותי: איך אתה מבצע את העברת המוצר מהפיתוח לבדיקות? איך אתה מוודא את איכות המוצר? מהם הקריטריונים להצלחה של חדר הבדיקות? בקיצור, אף שאלה על מתודולוגיה. ואת זה אני לא מבין!
יכול להיות מישהו שהוא עילוי טכני, האם זה יבטיח את איכות המוצר? ברור שלא. אם הוא לא מודע בכלל לבדיקות יוזביליות, סביר שהמשתמשים לא יהיו מרוצים. הוא עלול לבזבז ימים בריצה סביב זנבו כי הוא לא עשה בדיקות שפיות למוצר לפמני קבלתו לחדר הבדיקות ועוד.
לעומת זאת, אם יש טכנולוג שלא מכיר היטב את התחום הטכני שבו עוסקת החברה, אבל שהוא בעל ידע מתודולוגי טוב בתהליכי בדיקה, האם הוא לא יועיל מהיום הראשון (ועוד יותר כאשר הוא ילמד את הטכנולוגיה)? להיפך: ללמוד טכנולוגיה זה הרבה יותר קל ממתודולוגיה, בטח שלטכנולוג. לעומת זאת מתודולוגיה זה לא רק תהליך, זו הפנמה של רוח הדברים, לדעת מה טוב גם במקרים שלא היינו בהם בעבר, ועל איזה חלק המתהליך אפשר לוותר במקרה מסויים כזה או אחר, וזה, חברים, בא רק אחרי ניסיון של שנים.

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

Exit Criteria

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

מה מכיל מסמך זה? כמובן שזה תלוי בארגון. מה שהייתי מכניס מחולק לכמה סעיפים:
ביצועים:
1. המוצר עומד בעומס של X פניות במשך Y ימים עם תגובה ממוצעת של Z שניות לפנייה.
2. כמה downtime היה.
3. הזמן הדרוש ל-Quick Recovery
איכות כללית:
1. אין באגים פתוחים בדרגת חומרה של major ומעלה.
2. כיסוי הבדיקות היה מלא.
3. 95% מסך הבדיקות עברו בהצלחה.
4. במידה והיו שינויים מרחיקי לכת בתשתית, האם התבצאו מספיק בדירות בעקבות תיקון זה?
מסמכים:
1. כל המסמכים אושרו (אני כמובן רושם סקיצה כללית בהיי לבל, בפועל יש למלא את המסמכים הרלוונטים)
2. כל המסמכים נמצאים במקום מוסכם.

בדיקות גנריות של שדה טקסט

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

לחצ/י כאן