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

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

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

he icon   en icon

דרגו כתבה זו
(1 הצבעה)

טיפים לאוטומציה יעילה

במאמר Good Practices For Automating Functional Tests מאת Dave McNulla תמצאו נקודות חשובות ליישום אוטומציה בצורה יעילה. שימו לב כי keyword Driven Testing הינה דרך יעילה להפרדה בין הבדיקה לבין הקוד שעומד…
נכתב על ידי | רביעי, 07 נובמבר 2012 15:33
עמוד 2 מתוך 2

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

  • Contractor Life - Pt 2: Contractor or Consultant?

    This is the second piece looking at life as a contractor, when thatisn't your first choice of gig. The first part is here.Please continue with me on this journey,Contractor or Consultant? Loads of people work as contractors and really like it. They like it a lot. Most of these chose to become a contractor at some point. Some have become full time employees of contracting firms. Of course, many of those firms prefer to be described as "consulting services." Whatever. There is a difference. I won't go on a rant about it here. Maybe later.Having said that, part of the reason companies bring in contractors for software work is simple. They can be brought in for a specific purpose or task. They do the task. Then they go away - with money in their pocket.They (well, me included when working on a contract assignment, so "We") are software mercenaries. Most folks don't like that description. I prefer "privateer." We get hired to do a specific task. We do it. We leave and go to the next engagement. Sometimes they want us to stay and do another specific task. Then the contract might get renegotiated. Or not. Contractor? Consultant? There is one thing I have not said about contractors, software mercenaries or privateers. If my contract is for a specific task - that is the task I do. I am not acting as a consultant. My primary purpose there is not to help them improve and make their world better. Sometimes, if the[…]

    24.09.2020 | 3:35 קרא עוד...
  • 4 Questions for Evaluating Experiments

    4 Questions for Evaluating Experiments When you try something new, when to you expect to see results? How do you evaluate an experiment decided on in a retro to know whether your hypothesis was correct? This week I read a post that described a situation I see too often.The poster described a retrospective in which the team evaluated their two-week-long experiment using Test Driven Development (TDD, a software development approach). Two of the senior members of the team declared it hadn’t reduced defects released by much but did slow them down.For the sake of this little story, it doesn’t matter you have an opinion on TDD, or how these folks were thinking about TDD, or even if you know what TDD is. What struck me was that these senior members were ready to drop the practice after two weeks. That’s not enough time to learn to do TDD, let alone see substantial results. They reached a premature conclusion, and missed out on potential benefits.You can avoid that trap by asking these four questions when you evaluate your team’s experiments. 1. Have we allowed enough time to learn? If your team is trying a new practice or approach, consider how long it takes to develop proficiency. I have several friends who are experts in software development. They invested months practicing before TDD felt natural and comfortable. Learning almost always entails a period of reduced productivity before realizing benefits. This is normal, natural, entirely expected. For example, the second time I make a dish, always goes faster[…]

    24.09.2020 | 7:52 קרא עוד...
  • ZAGREB21 2020, Zagreb, Croatia

    This race was originally scheduled for March, but it was cancelled because of COVID-19. The original date was also when Zagreb was hit with the biggest earthquake in 140 years, so the race would be canceled without COVID-19. See my blog post Half marathon March 2020. The new date was on a weekend that I’ve planned to run 20-30 km anyway, so I’ve decided to run the race. Masks were required only at the start. Official time 1:50:41. Links ZAGREB21 at zagreb21.run ZAGREB21 at tentamen.eu

    24.09.2020 | 7:14 קרא עוד...


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