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

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

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

  • Humidifier For Home Heater

    Humidifier For Home Heater humidifier for home heater humidifier for sq ft. . . . . . . . . . . . . . .

    25.05.2019 | 11:08 קרא עוד...
  • ATA Meetup #22 - Bangalore - Amazing experience

    ATA Meetup #22 - Bangalore - Amazing experience Reached super earlyThe session was supposed to start at 9 AM and I reached by 7.45 AM. I did not want to be late. Due to weekend's minimalistic traffic and super driver, I surprised myself and I thought I can just enter and wait in the hall. The security asked me the contact person name and I told him that there is a meetup by Agile Testing Alliance - did not help. I called up Aditya Garg and somehow the security got convinced that I can at least pass the main barricade and sit on the makeshift park seats.It was nice to experience fresh air, have fruits and dive into an interesting book called "The Practicing Mind" by Thomas M. Sterner. The Practicing Mind I remembered the discussions with Shrini Kulkarni about consciousness, mind, awareness as I read the book. Around 8.40 AM, Thrivikram and Venkata P from HCL welcomed and escorted me to the induction hall where we had the meetup. The conversation between them and the security folks was an interesting one making me think of the process adherence vs value addition. Learning for me: Know the contact person in advance and keep them informed about surprises in plan. HCL ServicesThe first session was by HCL management represented by Prashantha M who highlighted the various services offered by HCL, the case studies and the learning. There were few really good questions by the audience who wanted to know more details about the insights shared to them.My tip: Knowing[…]

    25.05.2019 | 11:55 קרא עוד...
  • Performance testing (benchmarking) Java code with JMH

    Performance testing (benchmarking) Java code with JMH Contents:1) Introduction2) Is it easy?3) Common pitfalls4) Setup5) How to configure JMH?6) Configuration options7) Configuration - predefining state8) Demo9) Results10) Further reading1. IntroductionAs test engineers when we approach performance testing we usually only think about final end-to-end application verification with tools such as JMeter, Locust or Gatling. We know that such tests should run on a separate environment with conditions resembling production as close as possible. Unfortunately in some cases (especially with monolithic architecture) dedicated performance testing environment is hard to get. What to do in such cases? Should we test on common test environment? Or should we test on production? Or maybe we should change our approach to performance testing?  Each option has advantages and disadvantages.Today I'd like to describe low-level performance testing (often called benchmarking) of Java code. It does not require a separate environment. It can be executed directly from your IDE (although that's not recommended) or from the command line. Measuring the performance of critical pieces of code is essential for everyone who creates applications, frameworks, and tools. Testers are co-creators so it's also our responsibility. 2) Is it easy?Benchmarking correctly is hard. There are multiple optimizations implemented on the JVM/OS/hardware side which make it challenging. In order to measure right, you need to understand how to avoid those optimizations because they may not happen in the real production system. Thankfully, there is a tool which helps you mitigate those issues called JMH (Java Microbenchmark Harness). It was created for building, running, and analyzing nano/micro/milli/macro benchmarks written in Java[…]

    25.05.2019 | 8:10 קרא עוד...

טיפים

  • טיפים לאוטומציה יעילה - Dale Emery
    טיפים לאוטומציה יעילה - Dale Emery (How to Survive the Coming Test Automation Zombie Apocalypse (PDF slide deck By Dale Emery bit.ly/15XFGkp סט שקופיות מעולה המתאר את מרבית המחלות התוקפות פעילויות אוטומציה - ומדגיש כיצד לטפל בהן! על כל שקופית ניתן לפתוח…
    קרא עוד...
  • אל תחכה שיתנו לך הזדמנות
    אל תחכה שיתנו לך הזדמנות אם אתה רוצה להתפתח - אל תחכה שיתנו לך הזדמנות, קח אותה - למד, בצע והדגם הדבר בזמנך הפנוי - מישהו כבר יאמץ את זה וייתן לך את הקרדיט.   טיפים מחברי ITCB-AB
    קרא עוד...
לרשימה המלאה >>