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

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

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

he icon   en icon

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

בודקי תוכנה – מגמות לעתיד

נכתב על ידי 
שבת, 28 פברואר 2015 19:10
דרגו כתבה זו
(2 הצבעות)

בודקי תוכנה – מגמות לעתיד

הקדמה

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

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

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

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

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

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

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

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

סיבה ראשונה  - נגישות וצורך :

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

בנוסף, הפלטפורמות שתומכות באותן טכנולוגיות רק הולכות וגדלות, דוגמאות קלאסיות :

מחשבים.

טלפונים.

טאבלטים.

מכוניות.

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

סיבה שנייה - הכרה בחשיבותו של תחום הבדיקות :

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

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

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

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

סיבה שלישית – פיתוח קריירה :

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

אז האם קריירה של בודק יכולה לענות על ביקושים אלו...? כמובן שכן! הסיבות לכך הם רבות :

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

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

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

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

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

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

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

סיבה רביעית – בודקי תוכנה הם המשפיעים ביותר בתהליך ה-SDLC:

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

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

אז למה בודקי תוכנה כ"כ חשובים בתהליך ה-SDLC ?

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

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

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

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

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

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

הכישורים הנדרשים מבודקי תוכנה

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

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

סקירת המאפיינים

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

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

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

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

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

דוגמה פשוטה שתמחיש את הנושא:

מורכבות שמגיעה מסוגי הפלטפורמות הנתמכות:

מורכבות שמגיעה מסוגי הטכנולוגיות הנתמכות:

מורכבות שמגיעה מסוגי מערכות ההפעלה הנתמכות:

Web based application.

Client-Server based Server application.

Mobile based application.

Cloud based application

Software that supports wireless technology.

Software that support different types of storages (Isilon, NTAP-CM...).

Software that support different types Networking (LAN, WAN, Bluetooth...).

Microsoft Servers (2003 /2008 / 2012...)

Unix Server (Fedora, Red-hot...).

Mobile OS (WinOS, Android...)

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

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

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

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

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

יכולת לבצע בדיקות לכל אורך חיי התוכנה (SDLC)

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

בנוסף, עובדה בסיסית ומוכחת שכול בודק מתחיל חייב לדעת:

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

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

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

בדיקות דינמיות – כל הבדיקות שקשורות לשימוש בתוכנה עצמה(בדיקות פונקציונליות , ממשק משתמש , ביצועים ועוד) .

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

שליטה בכל המדיומים הקשורים לתוכנה

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

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

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

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

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

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

סיכום

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

בתודה מראש,

דוד צמח

שונה לאחרונה ב שלישי, 16 פברואר 2016 06:28

חובה להיות משתמש רשום במערכת בכדי להגיב - ההרשמה/כניסה בכותרת האתר

חדשות מעולם הבדיקות

  • Fifteen Free Tools to Help With Testing

    Fifteen Free Tools to Help With Testing There are a great many articles, blog posts, and presentations that discuss automation frameworks and strategies.  But even the most robust automation framework won't eliminate the need to do exploratory testing.  There will always be situations where we need to generate a large amount of text to test a text field or where we need to encode a string in HTML to test for cross-site scripting.  In this week's post, I share fifteen of my favorite free tools that make testing faster and easier.  Text Tools:1. Letter Count:  This tool will count the characters or words in a block of text.  I use it for creating strings with a specific character count when I test text fields.2. Lorem Ipsum Generator: I use this tool when I need to generate large amounts of text for text fields where a user will be able to enter several paragraphs of text.3. Convert Case: This tool comes in handy when I'm testing with Postman and my assertions are expecting the exact casing for string comparison.  Convert Case will set all the characters in a string to lower case, upper case, sentence case, alternating case, and more.JSON Tools:4. Pretty Print: JSON objects need indentation to be easily readable.  This tool will take care of all of the indentation and spacing for you.  This is especially helpful when you receive flattened JSON in a response and you want to be able to read through it.5. Online JSON Viewer: This tool will flatten your JSON for you by removing[…]

    15.12.2018 | 2:14 קרא עוד...
  • Hacking Password Reset Functionality

    Hacking Password Reset Functionality So I have recently returned from 3 months travelling around Colombia and Central America and I am ready to get back to work! One thing that stayed with me during my travels is the amount of time technology would generally appear in conversations from Bitcoin to GPS systems – this gave me further motivation to expand my career in this varied and extremely interesting field. I recently got an email from Pluralsight with an invitation to use the platform for their free weekend, so I thought it would be a good opportunity to take some security classes. Especially considering one of my 2019 goals is to complete the CEH qualification. The course I decided to do focused on web hacking password reset functionality. Please continue reading to learn more about the various ways password reset functionality is vulnerable to attacks. There are generally 3 different ways to reset user password on websites: Password reset links (by far the most common) Generating a new Password which is sent (in plaintext) to the users email Question and Answer style A typical password reset link could look like this: https://example.com/reset.php?token=12345ab6 or it could look like this, using two parameters -> user ID and token https://example.com/reset.php?userId=12345&token=12345ab6 The userId parameter is unnecessary in the second example, as each token should be unique to the user, making the userId parameter arbitrary. A vulnerability which can be easily fixed is that the link should only be valid for a certain amount of time (enough time for the[…]

    15.12.2018 | 1:20 קרא עוד...
  • I Represent the User! And We All Do

    As a tester, I try to represent the interests of users. Saying the user, in the singular, feels like a trap to me. There are usually lots of users, and they tend to have diverse and sometimes competing interests. I’d like to represent and highlight the interests of users that might have been forgotten or overlooked. There’s another trap, though. As Cem Kaner has pointed out, it’s worth remembering that practically everyone else on the team represents the interests of end users in some sense. “End users want this product in a timely way at a reasonable price, so let’s get things happening on schedule and on budget,” say the project managers. “End users like lots of features,” say the marketers. “End users want this specific feature right away,” say the sales people. “End users want this feature optimized like I’m making it now,” say the programmers. I’d be careful about claiming that I represent the end user—and especially insinuating that I’m the only one who does—when lots of other people can credibly make that claim. Meanwhile, I aspire to test and find problems that threaten the value of the product for anyone who matters. That includes anyone who might have an interest in the success of the product, like managers and developers, of course. It also includes anyone whose interests might have been forgotten or neglected. Technical support people, customer service representatives, and documentors spring to mind as examples. There are others. Can you think of them? People who[…]

    15.12.2018 | 11:33 קרא עוד...

טיפים

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