טסט טסט אחת שתיים

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

מצגת זו הוכנה ע"י עמוס אוזן מחברת BMC

לפרטים נוספים ולמצגת המלאה -

תגיות: QA, TACT, testing, בדיקות, טאקט, טאקט בדיקות, טאקט בדיקות תוכנה, מדדים, מטריקס גלובל

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

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

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

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

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

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

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

וכמובן לבצע שליחה של הנתונים לתחנה המקבלת.

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

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

2. להכין אפיון מפורט הכולל תקשורת , תרשימי זרימה , חיבורי חומרה ותוכנה , פונקציונאליות וכו’

3. פיתוח התוכנה חייב להתייחס ל – ICD על מנת להבין כיצד ובאיזה סדר ומובן באיזה מבנה להעביר את ההודעות.

4. פיתוח החומרה חייב לעמוד בתקנים כגון MIL STANDARD ישנם תקני חומרה שהם חסמים כמו לדוגמא ROHS.

5. יש לבצע UNIT TESTING לכל אחד מהרכיבים הן התוכנתיים והן החומרתיים.

6. יש לבצע אינטגרציה STEP BY STEP ע"י חיבור כל רכיב בצורה בודדת ורק לאחר שהכול מנגן יש לחבר את הרכיב הבא.

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

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

9. יש לבצע בדיקות מסירה מעמיקות הכוללות את כל הציוד בשטח.

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

11. מומלץ לבצע הטמעה ארוכה שתכלול הכשרות מלאות לכל הדרגים.

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

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

אז שיהיה בהצלחה באתגר

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

בשנים האחרונות אנו ערים לתופעה הולכת וגוברת בשם NEAR SHORE, רבים נוטים לבלבל בין NEAR SHORE , OFF SHORE , ON SHORE וכו’.
חברות רבות גדולות ומכובדות הבינו ש – NEAR SHORE אינה סתם תופעה חולפת היא כאן ובשביל להישאר!!!

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

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

2. חפיפה מלאה על מתודולגיית העבודה והתהליכים התוך ארגוניים של הלקוח – יש ליצור תאום צפיות מלא ולחפיפה לגבי תהליכי העבודה של הלקוח וכן מתודלוגיית העבודה על מנת לייצר ממשק חלק ומתואם עם הלקוח , אולי אפילו ליצור תהליך חפיפה פנימי עם הלקוח ולאחר מכן מעבר אל מחוץ לארגון ל – NEAR SHORE .

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

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

לסיכום אין כמו ב – NEAR SHORE (על בסיס אין כמו בבית ) רק שימו דגש דגש על מפתחות הקסם והדרך להצלחה מובטחת!!!

בהצלחה ותנסו להנות גם מהדרך.

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

תגיות: דגשים לעבודה במודל NEAR SHORE עשה ואל תעשה, טאקט בדיקות

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

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

במערכות הפעלה קודמות כגון סימביאן, היה על המפתח לדאוג שאפליקציה שפותחה לגודל מסך של 240×320 תרוץ בכלל וכן תיראה בצורה מושלמת על מסכים בגדלים שונים (640×480) ועוד.

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

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

אז איך זה נעשה?

מערכת ההפעלה אנדרואיד, מחלקת את המסך ל-4 סוגים שונים/גדלים שונים: Small, Normal, Large, Extra Large

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

ldpi (low), mdpi (medium), hdpi(high), xhdpi (extra high)

הגדרת המונח density בצורה המקצועית:

Density – Based on screen resolution, the spread of pixels across the physical width and height of the screen. A screen with lower density has fewer available pixels spread across the screen width and height, where a screen with higher density has more. The density of a screen is important because other things being equal (UI element such as a button) will appear larger on the lower density screen and smaller on the higher density screen. Applications can provide custom resources for each of these densities — the platform handles any necessary scaling of the resources up or down to meet the specific screen density

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

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

ניתן ורצוי להשתמש בסביבת הפיתוח של אנדרואיד (Android SDK) אשר ניתנת להורדה חינם.

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

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

Android create avd ,,, — skin WVGA800

לסיכום – לפניכם חיתוך סוגי המסכים השונים עפ"י הפרמטרים שהוגדרו למעלה:

• QVGA (240×320, low density, small screen)

• HVGA (320×480, medium density, normal screen)

• WVGA800 (480×800, high density, normal screen)

• WVGA854 (480×854 high density, normal screen)

• WQVGA400 (240×400, low density, normal screen)

• WQVGA432 (240×432, low density, normal screen)

ערן קינסברונר

מנהל הבדיקות של TI במודל נירשור מטעם טאקט בדיקות

בסקר אנונימי וייחודי שערכה לאחרונה חברת טאקט בדיקות בין מרבית לקוחותיה,נאספו נתונים מעניינים ומרשימים מאוד על שוק הבדיקות כיום, הכיוון שלו בעתיד וכן בעיות עימם השוק הזה מתמודד בימים אלה. המשתתפים בסקר נמנו על המגזרים הבאים – בטחוני/ציבורי/ממשלתי/פיננסי והייטק
להלן תוצאות חלקיות מהסקר (התוצאות השלמות יפורסמו בעתיד הקרוב).
על השאלה – מה מספר אנשי הבדיקות בארגונך, ענו כ-65% מהנשאלים כי קבוצת הבדיקות שלהן היא בין 0-20 בודקים, כ-20% נוספים ענו שמספר הבודקים הוא בין 21-50 בודקים.

על השאלה – מהו היחס (באחוזים) בין אנשי אוטומציה לאנשי הבדיקות בארגונך, ענו מרבית המשתתפים כי אין להם פתרון אוטומציה בארגון, וארגונים שיש להם אוטומציה ענו כי האחוז הוא 10%.
על השאלה – מהם הנושאים שבכוונתך להתעמק בשנה הקרובה ענו מרבית הנשאלים שינסו להתעמק בתחומי האוטומציה, עומסים ו- ALM
כאמור, תוצאות מפורטות ומלאות של הסקר יפורסמו בעתיד הקרוב.
ערן קינסברונר
מנהל הבדיקות של TI במודל נירשור מטעם טאקט בדיקות
למידע נוסף, מומלץ לפנות לאתר טאקט בדיקות www.tact.co.il

טאקט בדיקות שמחה להזמינך לכנס ה Java הראשון במרכז פיתוח ה Off Shore וה Near Shore הגדול בארץ

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

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

ההרצאות יעסקו בנושאים החמים והמסקרנים ביותר כיום בתחום Java/J2EE

שריין מקומך עוד היום בכנס החשוב!

ההשתתפות ללא תשלום אך מותנית ברישום מראש ובקבלת אישור הרשמה בסמוך לאירוע

למשתתפי הכנס תנתן הנחה של 15% על כל קורסי ה Java של ג’ון ברייס הדרכה

לרישום התקשר/י ל: 077-5702600 שלוחה 0, או שלח מייל ל registration@matrix-global.net

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

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

אתם מוזמנים לתת הערות מניסיונכם על הכלים המופיעים כאן או להוסיף חדשים:

כלים לתכנון בדיקות וצמצום יעיל של תסריטים

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

http://www.pairwise.org/tools.asp

כלים למעקב אחר באגים & כלי ניהול

Bugzilla –

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

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

האפליקציה ניידת מהwindows  ללינוקס ולהפך , באמצעות ALMWork‘s חינם של Virtual Bugzilla Server –      http://almworks.com/vbs/overview.html

האפליקציה אינטרנטית ולא נדרשת התקנה על ה- client

URL: http://www.bugzilla.org

Trac –

מבוסס אינטרנט. משמש לניהול וככלי מעקב אחר באגים. בעל ממשק "subversion"   בשילוב Wiki.

URL: http://trac.edgewall.org

Mantis –

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

URL: http://www.mantisbt.org

RedMine –

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

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

URL: http://www.redmine.org

OpenProj –

פלטפורמת ניהול פרויקט , אשר מציע פתרונות מתקדמים.

מנוע תזמון, תרשימי גאנט, דיאגרמות רשת, תרשימי WBS& RBS , תמחור ועוד.

URL: http://openproj.org/openproj

Funambo –

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

התכונות כוללות: ניהול המכשיר, "דחיפת" אימייל, נתוני משתמש, תקשורת נתונים ו"סנכרון ענן"( cloud synchronization )

URL: http://www.funambol.com/solutions/opensourceplatform.php

כלי "בדיקות יחידה"

בתחום IDEs, frameworks, וכלי בדיקות יחידה, קהילת הקוד הפתוח מציעה מגוון גדול של כלים.

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

JUnit

מיועד למסגרת בדיקות רגרסיה

URL: http://www.junit.org

כלים דומים: NUnit & TestNG.

JSystem

במסגרת בדיקות אוטומציה פונקצינאליות. מבוסס על JUnit

URL: http://www.jsystemtest.org

Jameleon

מנוע נתונים, במסגרת בדיקות אוטמציה

URL: http://jameleon.sourceforge.net

Fitnesse

שיתוף וקבלה של Testing Framework, וכלי תיעוד.

URL: http://fitnesse.org

GenerateData

Open-source data generator script

URL: http://www.generatedata.com/#about

Wireshark

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

URL: http://www.wireshark.org

כלים לבדיקות WEB

כלי אוטומציה

Selenium IDE

כלי open source לאוטומציה המוכר ביותר. כלי suite בשילוב IDE, RC ורשת. מאפשר להפוך כמעט כל יישום אינטרנט מבוסס HTML  לאפליקציית אינטרנט עשירת Java & AJAX.

פועל על כל הפלטפורמות: Windows, Mac, Linux, Solaris ואחרים.

מתאים לדפדפנים השונים: FireFox 2/3, IE 7/8, Safari 2/3, Opera

תומך בשפת תכנות רבות: PHP, Python, Ruby, C#, Java, Perl,

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

לפיכך, יכול להתאים כמעט לכל אחד.

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

Watir

פטפורמה רגישה ורבת עוצמה בין ה"קוד הפתוח"

משפחה של ספריות Ruby   לאוטמציית יישומי אינטרנט

תומכת בפלטפורמות רבות ובדפדנים השונים, ומשתמשי Ruby .

שפת scripting

מונע ע"י קהילה פעילה וגדלה.

URL: http://www.watir.com

iMacros

כלי פשוט ואינטואטיבי לאוטמציה, אינטרנטי ומתאים לכל המטלות הפשוטות והיומיומיות החוזרות ונשנות כמו compound data scraping ופונקצינאליות אוטומטית.

Auto-it

http://www.autoitscript.com

Watin

http://watin.sourceforge.net

STAF

כלי אוטומציה המבוסס על קהילת קוד פתוח

http://staf.sourceforge.net

כלים לסימולציית לקוח

Modify Headers

הדמיית לקוחות ניידים שונים וuseragents

XHTML Mobile

הוספת תמיכה של XHTML Mobile Profiles

כלים לאימות נתונים ו-extraction

Total Validator

אימות HTML

Html Validator

כלי נוסף לאימות HTML

W3C Page Validator

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

Regular Expression Tester

מאד שימושי עבור Regular Expression יצירות ובדיקות.

LinkChecker

קישור פשוט לתיקוף ההרחבה.

כלי Debugging, ניתוח ומניפולציה של נתונים

Firebug

Debugging אינטרנטי המקיף ביותר.

התכונות הרבות כוללות עריכה, ניפוי וניטור של CSS, HTML & JavaScript בכל דף אינטרנט.

Flash FireBug

Debug לקבצי SWF

YSlow

ניתוח ביצועים אינטרנטי של Yahoo!, המשולב עם Firebug

Fiddler

"סניפר" אינטרנטי.

Live HTTP Headers

הצגת כותרות HTTP של הדף במשך הדפדוף

כלי אבטחת מידע (penetration testing)

XSS

אתר חינמי לביצוע בדיקות XSS online

http://xss.progphp.com

HackBack

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

Tamper Data

צפייה/שינוי כותרות HTML ו- POST parameters

Access Me

Vulnerabilities test tool using unauthenticatedaccess

Requests

SQL Inject Me

Vulnerabilities test tool using SQL injection attact

XSS Me

Vulnerabilities test tool using cross-site scripting

(XSS) attackt

Fiddler

Web debugging proxy לתעבורת HTTP  וסניפר.

URL: http://www.fiddler2.com/fiddler2

TamperIE

שיבוש בקשות HTTP דומה ל TamperData של פיירפוקס.

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

www.webresourcesdepot.com/10-free-web-application-security-testing-tool

כלי ממשק משתמש ונגישות

FireSizer

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

Measure It

בדיקת גובה ומשקל רכיבי הרשת

Accessibar

בודק את  תצוגת דף האינטרנט וה text-to-speech.

כלים לתיעוד צילומי מסך

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

Spector – www.spectorsoft.com

Screen hunter – www.wisdom-soft.com

BBTestAssistant – www.bbsoftware.co.ik

testExplorer – www.sirius-sqa.com

FireShot

תופס צילומי מסך מפורטים של תחומי המפתח או השלמת דף אינטרנט

Snagit

timesnapper

כלים ללכידת מצב המערכת בעת דיווח תקלה

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

Vlog – www.vapisoft.com/vlog

כלים לבדיקות עומסים

Apache Bench (AB)

כלי עוצמתי להעלות אפליקציית web  על מערכות הפעלה שונות

URL: http://httpd.apache.org/docs/2.0/programs/ab.html

Jmeter

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

URL: http://jakarta.apache.org/jmeter/

WebLoad

מאפשר עומס רב עוצמה  לבדיקות STRESS וביצועים

URL: http://www.webload.org

כלים  ל"סנכרון נתונים"

DropBox

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

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

URL: http://www.dropbox.com

iFolder

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

URL: http://ifolder.com/ifolder

JFileSync

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

URL: http://jfilesync.sourceforge.net

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

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

רם

תגיות: open source tools, חושבים בדיקות, כלי בדיקות אוטומטיים

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

המרכיבים העיקריים שבד"כ יש להכליל בתוכנית הבדיקות הם:
1. תאריך קבלת מסמכי אפיון, מסמכי דרישות, דרישות לקוח –> אלו ועוד חייבים להיות מוכלים בתוכנית כתלות בהתחלת פיתוח הבדיקות ואף תחילת פיתוח ה – STP
2. בלוק שלם בתוכנית הבדיקות (גאנט הבדיקות) חייב להיות מוקצה לכתיבת STP ומסמכי STD רלוונטיים עם תאריכים מוגדרים התלויים בקבלת מסמכים מהפיתוח או מהנדס המערכת.
3. תחילת פיתוח הבדיקות (אוטומטיות וידניות כאחד) חייב להיות בתלות ישירה בהימצאות STP וכן STD’S אשר עברו אישור של מנהלי הקבוצות השונות (פיתוח, ייצור, מהנדסי מערכת, מנהל מוצר וכ"ו)
4. החלק הבא בתוכנית הבדיקות צריך להתייחס לאימות תרחישי הבדיקה המפותחים והרצת הבדיקות בפעם הראשונה על גרסאות תוכנה ראשוניות (תהליך "דיבוג" של הבדיקות).
5. החלק הבא לאחר "דיבוג" הבדיקות יהיה לרוב הקפאת פיתוח המוצר לקראת הקפאת פיתוח הבדיקות – יש המתייחסים לשני ה"מיילסטונים" הללו בטרמינולוגיה הבאה – קודם לכן יהיה שלב סיום פיתוח המוצר ורק לאחריו הקפאת הבדיקות ע"מ לוודא שהבדיקות תואמות את המוצר הסופי.
1. Feature complete/Feature Freeze
2. Test Development Complete
6. לאחר שעברנו בהצלחה את שלב הקפאת פיתוח המוצר והבדיקות (לאחריו אני ממליץ על שמירת גרסת הבדיקות בכלי ניהול תצורה כלשהוא כעוגן לגרסת התוכנה הנבדקת) יש להתחיל בסיבובי בדיקות לאימות האיכות ועמידה בדרישות האיכות כפי שהוגדרו במסמך ה-STP. לרוב נדרשים לא פחות משני סבבי בדיקה מלאים שביניהם יש להכניס זמן לפיתוח לתיקון תקלות/באגים שיימצאו בסבב הראשון.בשלב זה רצוי לוודא שקיימים גם מסמכי המוצר היוצאים ללקוח (כגון User guide, release notes, installation guide וכ"ו) והם עברו אישור של הגורמים המוסמכים בפרויקט.
7. לפני ביצוע סבב הבדיקות האחרון (יכול להיות השני או גם השלישי ומעלה – תלוי ברמת איכות ויציבות המוצר וכן בנכונות פיתוח הבדיקות) יש להגדיר תאריך אשר ייקרא הקפאת הקוד (Code Freeze) אשר משמעותו היא שלא משנים אף שורת קוד וניגשים לסבב אחרון על גרסא מועמדת לשחרור (release candidate) – כל שינוי בקוד או תיקון תקלה יידרש בשלב זה אישור מהנהלת הפרויקט.
8. השלב האחרון צריך להיות שלב שחרור המוצר שאמור להכיל אימות שכל תוצרי הפיתוח/בדיקות/שיווק וכ"ו נמצאים (דו"ח תוצאות בדיקה מפורט, מסמכי לקוח, גרסא מתועדת המצויה בכלי ניהול התצורה ומוכנה לשחרור ועוד).
לרוב מנהלי הפרויקט, פיתוח ובדיקות ישתמשו בכלים כמו MS Project או כלים תואמים לניהול משותף של הפרויקט על כל מרכיביו ותוצריו.

בהצלחה
ערן

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

למידע נוסף, מומלץ לפנות לאתר טאקט בדיקות www.tact.co.il

תגיות: QA, testing, בדיקות, כלי בדיקות, כלים

שלום,

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

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

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

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

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

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

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

למידע נוסף ניתן לפנות אליי ו/או לרם יוניש באמצעות הפייסבוק של טאקט בדיקות או דרך האתר שלנו www.tact.co.il

תגיות: mobile testing, QA, TACT, בדיקות מובייל, בדיקות תוכנה, טאקט בדיקות תוכנה, ערן קינסברונר