The document discusses various topics related to software testing including automated vs manual testing, crowd testing, Agile methodologies like Scrum and Kanban, tools that support Agile and testing practices, cloud-based testing platforms, mobile testing, security vulnerabilities, and online resources for software testing information. It provides an overview of key Agile concepts and how tools and methods have evolved to support new approaches to testing in modern software development.
SeeTest is a test automation tool that can test the user interface of any application, including mobile, web, legacy and desktop. It uses a patented technology to automatically record tests within minutes and works with all major testing frameworks. SeeTest supports all operating systems and browsers, and is used by banks, gaming companies, mobile developers and defense organizations to test their applications.
This document summarizes QA and testing trends in Israel. It discusses factors influencing QA staffing levels, including organizations that produce their own software, highly regulated industries, and those focusing on process improvement. New regulations and trends like cloud computing, Agile development, outsourcing, and the increased role of the CIO are influencing QA. Metrics like bugs, test coverage, and build passes are discussed. Israeli firms are adopting nearshore outsourcing and Agile. Pricing models are moving from fixed-price to time and materials. Developers and testers have different motivations and perspectives.
האם מעצבים צריכים לדעת תכנות - עם הערותsagishrieber
הרצאה שלי מאירוע חווית משתמש על בירה על הקשר בין עיצוב, תכנות, וחווית משתמש.
במצגת זו אעבור על הסיבה האמיתית שאנו- מעצבי המדיה האינטראקטיבית חייבים לדעת לפחות מעט של קוד.
The document discusses various topics related to software testing including automated vs manual testing, crowd testing, Agile methodologies like Scrum and Kanban, tools that support Agile and testing practices, cloud-based testing platforms, mobile testing, security vulnerabilities, and online resources for software testing information. It provides an overview of key Agile concepts and how tools and methods have evolved to support new approaches to testing in modern software development.
SeeTest is a test automation tool that can test the user interface of any application, including mobile, web, legacy and desktop. It uses a patented technology to automatically record tests within minutes and works with all major testing frameworks. SeeTest supports all operating systems and browsers, and is used by banks, gaming companies, mobile developers and defense organizations to test their applications.
This document summarizes QA and testing trends in Israel. It discusses factors influencing QA staffing levels, including organizations that produce their own software, highly regulated industries, and those focusing on process improvement. New regulations and trends like cloud computing, Agile development, outsourcing, and the increased role of the CIO are influencing QA. Metrics like bugs, test coverage, and build passes are discussed. Israeli firms are adopting nearshore outsourcing and Agile. Pricing models are moving from fixed-price to time and materials. Developers and testers have different motivations and perspectives.
האם מעצבים צריכים לדעת תכנות - עם הערותsagishrieber
הרצאה שלי מאירוע חווית משתמש על בירה על הקשר בין עיצוב, תכנות, וחווית משתמש.
במצגת זו אעבור על הסיבה האמיתית שאנו- מעצבי המדיה האינטראקטיבית חייבים לדעת לפחות מעט של קוד.
אנחנו רגילים להשקיע בתוכניות מפורטות כדי להגדיל את סיכויי ההצלחה של הפרוייקט, ובכל זאת מופתעים מהמציאות הנפרשת לפנינו.
כדברי האימרה הידועה, האם אין זה מטורף לעשות את אותם הדברים ולצפות לתוצאות שונות?
במצגת זו מתוארת אלטרנטיבה המבוססת על תכנון אמפירי, בהסתמך על תיאוריית המערכות המורכבות-אדפטיביות. המצגת מתארת כמו-כן מסגרות פופולריות לתכנון על-סמך מידע אמפירי כגון סקראם וקאנבאן
Agile sparks 2012 ux-vision - agile an ux - emenies or friendsTAL FLORENTIN
Agile and User Experience - Friends or enemies? (Hebrew)
Agile and UX are two major bases of product engineering. They come from different disciplines and have different agendas. What are the challenges between Agile and UX? How UX helps achieve the basics of Agile and how can the two work together?
This presentation was given during a webmaster & website manager\'s forum meeting, lead by people & computers company, Israel.
ההרצאה הועברה במסגרת מפגש פורום מנהלי אתרים של קבוצת אנשים ומחשבים
The document discusses Vision.bi Quality Gates, a centralized data quality solution. It provides an overview of quality gates and how they can be used for integration and business intelligence projects. Quality gates help define tests to constantly monitor and improve data quality. The document outlines various test types like check sums, referential integrity checks, and execution flow tests. It demonstrates how quality gates provide alerts, ensure data integrity, and validate data warehouse cubes. Clients currently using Vision.bi are also listed.
אנחנו רגילים להשקיע בתוכניות מפורטות כדי להגדיל את סיכויי ההצלחה של הפרוייקט, ובכל זאת מופתעים מהמציאות הנפרשת לפנינו.
כדברי האימרה הידועה, האם אין זה מטורף לעשות את אותם הדברים ולצפות לתוצאות שונות?
במצגת זו מתוארת אלטרנטיבה המבוססת על תכנון אמפירי, בהסתמך על תיאוריית המערכות המורכבות-אדפטיביות. המצגת מתארת כמו-כן מסגרות פופולריות לתכנון על-סמך מידע אמפירי כגון סקראם וקאנבאן
Agile sparks 2012 ux-vision - agile an ux - emenies or friendsTAL FLORENTIN
Agile and User Experience - Friends or enemies? (Hebrew)
Agile and UX are two major bases of product engineering. They come from different disciplines and have different agendas. What are the challenges between Agile and UX? How UX helps achieve the basics of Agile and how can the two work together?
This presentation was given during a webmaster & website manager\'s forum meeting, lead by people & computers company, Israel.
ההרצאה הועברה במסגרת מפגש פורום מנהלי אתרים של קבוצת אנשים ומחשבים
The document discusses Vision.bi Quality Gates, a centralized data quality solution. It provides an overview of quality gates and how they can be used for integration and business intelligence projects. Quality gates help define tests to constantly monitor and improve data quality. The document outlines various test types like check sums, referential integrity checks, and execution flow tests. It demonstrates how quality gates provide alerts, ensure data integrity, and validate data warehouse cubes. Clients currently using Vision.bi are also listed.
How to manage your testing automation project ttm methodologyRam Yonish
מנהלים רבים וארגונים רבים מיישמים אוטומציה בתהליך הבדיקות שלהם אבל עדיין מרגישים שההחזר על ההשקעה נמוך ואף שלילי. מחקרים רבים מראים כי הבעיה נובעת מחוסר תיאום ציפיות, זיהוי לא נכון של הבעיות שהכלים באים לפתור, בחירת כלי לא מתאים ותהליך הטמעה שגוי.
מתודולוגיית TMM (Testing tools management) באה לתת מענה בדיוק לבעיות שהוצגו. המתודולוגיה כוללת הגדרת השלבים השונים בפרויקט אוטומציה, החל מהגדרת הבעיה, דרך בחירת הכלי, בחינת הכלי, הטמעה ומדידת האפקטיביות שלו לכל אורך הפרויקט
The document proposes a Vgile methodology that combines elements of the traditional V-model lifecycle with agile principles like risk-based testing and small cross-functional teams. It advocates a hybrid approach to address the need for flexible yet reliable systems within shorter development cycles. Case studies and best practices are provided, including continuous integration, test-driven development, and maximizing communication through frequent meetings. The methodology aims to make testing activities more efficient through a focus on prevention and early static testing.
This document discusses return on investment (ROI) and provides three examples of ROI calculations:
1) A software testing example that shows how finding and fixing bugs early can save significant costs later and provide a ROI of 350%.
2) An example of how investing $70,000 in testing upfront resulted in $315,000 of savings, providing a ROI of 350%.
3) A brief example comparing investing $40 upfront versus $50 later, highlighting the potential cost savings from earlier investment.
A Successful Improvement Process With Measurable ResultsRam Yonish
The improvement process led to measurable results including a 25% increase in profits within a year. Key aspects of the process included establishing an improvement framework with principles, tools and metrics; having lines lead their own improvement plans with mentorship; and adopting practices like unit testing, continuous integration, coding standards, and root cause analysis. These changes helped integration by 25% and reduced customer defects over time.
A successful improvement process with measurable resultsRam Yonish
This document discusses a successful improvement process with measurable results at a global company. The goals of the improvement plan were to increase business results by improving project management, processes, and methodologies. The plan provided principles, tools, metrics, and an improvement framework to guide lines in developing and managing their own improvement plans with mentoring on real projects. Measurable impacts included integration time savings, better quality, and increased efficiency and profit.
The document discusses the maturity of R&D projects at Ceragon Networks. It provides charts showing metrics like the number of open and resolved issues over time. It analyzes the maturity levels of different projects, groups responsible for the most bugs, and common causes of bugs. The conclusion is that over half of open bugs are critical or high priority, most are resolved, and various groups and modules are responsible for detecting different amounts and severities of issues.
The document discusses the maturity of R&D projects at Ceragon Networks. It provides charts showing metrics like the number of open and resolved bugs over time. It analyzes bug data by group, module, tester, and severity. The conclusions section notes potential reasons for open bugs and bugs detected by different groups. It also includes charts showing bugs planned vs done and breakdowns by module and severity. The overall summary is that the document analyzes bug and project data from R&D to understand maturity levels and trends.
במצגת המצורפת, מציג לנו זיו מנדל (מנכ"ל משותף ג\'ון ברייס הדרכה, טאקט בדיקות ומטריקב גלובל) את תפיסתו והבנתו לגבי מגמות בעולם הטכנולוגי בכלל ובעולם הבדיקות בפרט
1) In 2009, Comverse hired a new Near Shore QA manager to improve its software testing processes and reduce costs.
2) The new manager found significant issues, including a large backlog of untested software, inefficient processes, and high employee turnover.
3) After implementing reorganization, process improvements and new tools, the manager helped Comverse pass more tests, reduce downtime, and improve employee satisfaction over three years.
This document discusses the benefits of nearshore outsourcing compared to offshore outsourcing. It states that some of the disadvantages of offshore outsourcing are reduced with nearshore since there are fewer time zone differences, cultural differences are smaller, and communication is easier. Nearshore offers a better balance between cost and quality than offshore.
This document provides an overview of testing tools for times of crisis, beginning with a disclaimer. It then lists and briefly describes various types of testing tools, including test management tools, test automation tools, freeware tools, and tools for specific testing types like compatibility and accessibility testing. The document concludes by emphasizing the importance of just getting started with testing and sharing knowledge with others.
This document discusses return on investment (ROI) and provides three examples of ROI calculations:
1) A software testing example that shows how finding and fixing bugs early can save significant costs later and provide a ROI of 350%.
2) An example of how investing $70,000 in testing upfront resulted in $315,000 of savings, providing a ROI of 350%.
3) A brief example comparing investing $40 upfront versus $50 later, highlighting the potential cost savings from earlier investment.
3. מטרות ההרצאה
• לעלות את המודעות לחשיבות של איכות הקוד ובעיקר
לעלות את המודעות לחשיבות של תפקיד המפתח
ביצירת קוד איכותי
• הצגת מספר הגיגים על תפיסת העולם והגישה של
המפתח בפיתוח הקוד והצגת מספר טכניקות ודרכי
פעולה לייצר קוד איכותי יותר
3
5. די דיינו די דיינו
אילו היו רק מבקשים מאתנו לכתוב יותר קוד – דיינו •
אילו היו רק מבקשים מאתנו לכתוב בטכנולוגיות חדשות – דיינו •
אילו היו רק מבקשים מאתנו לכתוב מערכות גדולות יותר – דיינו •
אילו היו רק מבקשים מאתנו לכתוב מערכות מורכבות יותר -דיינו •
אילו היו רק מבקשים מאתנו לתקן ולעשות שינויים כל הזמן – דיינו •
אילו היו רק מבקשים מאתנו לכתוב מערכות בשלל טכנולוגיות – דיינו •
אילו היו רק מבקשים מאתנו לתעד את המערכות – דיינו •
אילו היו רק מבקשים מאתנו לבדוק את הקוד שאנחנו כותבים – דיינו •
אילו היו רק מבקשים מאתנו שלא יהיו במערכות באגים – דיינו •
אילו היו רק מבקשים מאתנו שהמערכות יעבדו בביצועים אופיטמאלים – דיינו •
אילו רק היו מבקשים מאתנו שהמערכות יהיו ידידותיות למשתמש – דיינו •
אילו רק היו מבקשים מאתנו שהמערכות לא יפלו ושאם הם יפלו אז שיתאוששו מהר – •
דיינו
די דייינו , די דיינו , דיינו דיינו ...... •
5
6. שלושת חוקי הבאגים
• בכל תוכנית יש באג
• בין כל באג לבאג יש עוד באג
• באג מביא חבר
• והחוק הכי חשוב (הדיבר הרביעי) : היצירה של הבאגים איננה
אקראית, איננה מקרית ואינה "מכת מדינה משמיים". מדובר
בתופעה שאפשר להלחם בה גם ברמת המניעה וגם ברמת
הגילוי והורדת עלות הנזק
6
8. מספר הגיגים על החוק הרביעי
• לאורך השנים נכנסו מתודולוגיות ושיטות עבודה במקביל לעליה בסיבוכיות
, בגודל ובמורכבות של המערכות והטכנולוגיות
• מי שלא הולך קדימה ... הולך אחורה ....
• ולמרות העליה של כל הפרמטרים ... אנחנו רואים שיפור במגמת של
איכות הקוד והתוכנה ( לא מספיק עדיין , אבל יש מגמת שיפור ברורה)
• במחקר על המקומות בהם נמצאים הבאגים הסתבר שלמרות שיצירת
הבאג נתפסת "כטעות אנוש" יש תבניות פעולה דומות בין כל הבאגים (
שאלה למחשבה : איכן נמצאים רב הבאגים בתוכנה ?)
• המסקנה ניתן להלחם בכמות ובאיכות של הבאגים וניתן להוריד את
העלות של יצירת הבאגים בתוכנה .....
8
9. כלכלת האיכות והבדיקות
• ניתן להוריד את עלות הכשל הנובעת מהבאגים שאנחנו
מייצרים
• עלות המניעה – זולה בסדר גודל מעלות התיקון
• עלות הגילוי המוקדם – המפתח לשיפור בעלות התיקון
9
12. הצד השני של גרף בוהם
• עלות התיקון לא רק עולה אלא גם איכות התיקון יורדת ככל
שנגלה מאוחר יותר את הטעות .....
• הפרדוקס של גרף בוהם כשהוא מגיע לשולחנו של המפתח :
• ההשקעה בגילוי ובבדיקות נעשית בעיקר בסוף ( מתי שיש
לנו את העלות היקרה ביותר ואת האיכות הגרועה ביותר
לתיקון)
• התובנה : צריך לעשות יותר בדיקות ויותר בקרה בשלבים
מוקדמים של הפיתוח ( קרי באחריות המפתח)
21
13. תפיסת גוף הבדיקות על ידי הפיתוח – הטעות הקלאסית
• בשביל מה יש גוף בדיקות מרכזי ובודק תוכנה בפרויקט שלי ?
• שהם יגלו את הבאגים ... אני עסוק ביצירת הקוד הבא שלי
(והבאגים החדשים שלי)
• זה לא באג זה פיצ'ר
• הם מטרידים אותי כל הזמן בשאלות .... בשביל מה הם
מקבלים כסף ... בשביל להפריע לי
• התוצאה – גופי הבדיקות מקבלים הרבה יותר באגים ולא
משקיעים את הזמן בבדיקות הסופיות והאינטגרטיביות
(המטרה העיקרית שלהם)
31
14. למה מתכוון המתכנת כשהוא אומר...
בלתי אפשרי בעליל – אין לי מושג איך עושים את זה.
בלתי אפשרי - אין לי כוח לעשות את זה.
קשה – אצטרך לקרוא תיעוד.
באופן כללי, אפשרי – רק אתמול הורדתי מאינטרנט ספריה שפותרת את הבעיה הזאת.
עובד – מתקמפל.
אני מלטש את זה – לא מתקמפל.
בודק על בעיות לדוגמא – מחפש מצבים שבהם התוכנית לא עפה.
סביר - בהסתברות של %5.1
אנו מנסים כמה גישות שונות – עדיין אין לנו מושג מה לעשות.
אנו מכינים דו"ח מסכם על הגישה החדשה שלנו לפתרון הבעיה- כרגע גייסנו 3 סטודנטים שנה א'.
אנו ערבים שהלקוח יהיה מרוצה – אנחנו כל כך לא עומדים ב ,Deadlineשהלקוח יהיה מאושר כשיקבל לפחות משהו.
בדיקות קבלה עברו בסדר – לא ציפינו שזה יעבוד.
צריך לשנות את כל הגישה – הבן אדם היחיד שהבין בזה לפחות משהו, כרגע התפטר.
כן, כן, נבדוק מה קורה עם זה – שכחו מזה יש לנו גם ככה מספיק על ה ראש.
תחתמו בבקשה על האפיון – בואו נחלק אחריות לכישלון.
בא ונשמע את דעתכם – אנו יכולים לשמוע את דעתכם, כמובן, כל עוד מה שאתם אומרים לא משפיע על מה שכבר עשינו.
שנים של פיתוח - תוכנית אחת בסוף התחילה לעבוד.
אנו עושים את זה לפי סטנדרטים! – אנחנו תמיד עושים ככה!
יש הרבה גורמים שמשפיעים על זה – תשכח מלקבל תשובה נורמאלית.
אנו על סף פריצת דרך – בפעם האחרונה התוכנית כמעט עבדה!
יש לתוכנה תמיכה מלאה – אנו מבטיחים לשלוח עוד גרסה, אם הקודמת לא תעבוד.
יש לתוכנה תמיכה חלקית – אם משהו יקרוס, לא יהיה לכם עם מי לדבר.
הפרויקט צועד לקראת סיומו בצעדי ענק – אנו מקווים שפרויקט של 62 שבועות יסתיים לקראת סוף השבוע ה 84.
התוכנה עומדת בתקני איכות – התוכנה התקמפלה בסדר.
41
15. שינוי בגישה של המפתחים כלפי הבדיקות
•הפתרון : הבנה של המפתח שהחלק
החשוב של איכות הקוד נמצא אצלו. המטרה
איננה לסיים את הקוד בזמן אלא לסיים את
קוד איכותי בזמן ... וזה הרבה יותר קשה
51
19. על ארבעה בנים דיברה התורה
• חכם - לעשות את הדבר הנכון , בדרך הנכונה
• תם - לעשות את הדבר הנכון , בדרך הלא נכונה
• זה שאיננו יודע לשאול - לעשות את הדבר הלא נכון בדרך
נכונה
• רשע - לעשות את הדבר הלא נכון , בדרך הלא נכונה
שאלה מעניינת : מי הטיפוס הפופלארי בקרב המפתחים ?
והמסקנה ?
91
21. בתהליך הפיתוח של Class
• הבנת הדרישות והממשקים (כולל עקרון העקיבות והשלמות)
• בניית תרחישי הבדיקה לפני ביצוע הקוד
• תכנון ועיצוב הקוד מונחה בדיקות : test driven - TDD
(developmentחייב להיות חלק משיקולי הפיתוח)
• כתיבה נקיה והתמקדות בחשיבה בנקודות הרגישות של הקוד (
כולל תעוד הקוד)
• כתיבת ה- J UNIT/N-UNITלכל ה- Class
12
24. בסיום הפיתוח של Class
• ביצוע מבדקי היחידה של הקוד ותעודם (קופסא שקופה וקופסא
שחורה)
• ביצוע ( CODE REVIEWעצמאית , על ידי בן זוג או כלים )
• בדיקות רמת הכיסוי של הבדיקה ( בעזרת כלים – כמובן עדיף)
• תעוד הנקודות הרגישות ....
• העברת הידע הנדרש והתמיכה לגוף הבדיקות
• ביצוע בדיקות אינטגרציה (עדיף בסביבה נפרדת) טרם העברת
הגרסה לבדיקות (כולל בדיקות sanityאוטומטיות)
• להכניס לתהליכי בדיקות שוטפים Continuous integration
(חשוב מאוד לתהליכי הפיתוח שהביצוע של הבדיקות יתבצע
בצורה הדרגתית שוטפת ואוטומטית)
42
26. בתיקון הבאג
• שחזור הופעת הבאג במסגרת ה- J-UNIT
• ביצוע חוזר של הבדיקות ( ולא רק של מה שתיקנו)
• תעוד במערכת הבאגים של מהות הבאג ובעיקר תעוד
ההשפעה של התיקון על הקוד ותעוד הבדיקות שנעשו (אם
צריך מעדכן ומוסיף )J-UNIT
• העברת הידע לבודק כולל מפת ההשפעה האפשרית של
התיקון ( ואפשר לתת לו גם משוב חיובי על גילוי הבאג )
• ניסיון להבין מדוע נוצר הבאג , איך היה אפשר למנוע אותו ואיך
אפשר למנוע את הבאגים הבאים
62