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

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

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

he icon   en icon

מבט מערכתי לבודקים – Systems Thinking

נכתב על ידי 
שבת, 03 ינואר 2015 11:53
דרגו כתבה זו
(1 הצבעה)

מבט מערכתי לבודקים – Systems Thinking

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

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

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

מה יקרה כאשר הגישה לרשת הנתונים משובשת ובזמן עומס יתר?

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

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

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

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

חומר קריאה נוסף:

http://www.mkltesthead.com/2013/07/get-understanding-of-systems-thinking.html

 

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

סדרת טיפים זו "כיצד להפוך לבודקים טובים יותר" מתבססת על דיון ב: Software Testing Club

99 Things Testers Can Do To Become Better Testers

ה-eBook החינמי שנוצר בעקבות דיון זה: 99ThingsEbook.pdf

וסדרת פוסטים מאת Michael Larsen בשם: Ways Workshop 99 - בה מיכאל מרחיב על כל אייטם וגם מספק הנחיות כיצד לתרגל הנושא.

 

SystemThinking habitsofst

 

 

שונה לאחרונה ב ראשון, 31 מאי 2015 05:13

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

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

  • 5 Things to Read This Week - 22nd Oct 2019

    5 Things to Read Agile Greece Summit Last week I’ve recommended a great talk on Exploratory Testing given by Maaret Pyhäjärvi on the Agile Greece Summit. If you are interested in other talks from this even, you can go to its Youtube channel: here Continuous Delivery and the Theory of Constraints by Steve Smith Again from the Agile Greece Summit, Steve Smith talks how the Theory of COnstraints is essential to understand the practices of Continuos Delivery. Beth Skurrie - Microservices. Test smarter, not harder Have you heard of Consumer-Driven Contracts tests? Although not completely novel, this technique is getting only traction in the last couple of years, a bit after the establishment of microservices. In this talk,Beth Skurrie gives us a introduction to Pact, surely one of the best tools to create and manager contract between services. Trisha Gee: Reading Code Is Harder Than Writing It One day I will make a (long) text on everything I think is wrong on how programming and software engineering is taught (things are getting better nonetheless). One of them is how people do not read code when learning how to code. I mean… do not read good code. Some small refactoring, a bit of polymorphism, and ban, semester project written with more 2 colleagues in 2 all-night-long programming sessions. Not the best way to develop craftsmanship… Trisha here talks about how important is this skill for anyone dealing with coding. I will talk on Automation Guild! Yep… I will be one of[…]

    22.10.2019 | 6:00 קרא עוד...
  • Sprint Zéro ou Sprint Un ?

    Sprint Zéro ou Sprint Un ?Bonne ou mauvaise pratique ?Le Sprint 0, aussi appelé phase préparatoire : pour ou contre ?Cela part de bonnes intentions, qu’on pourrait trouver a priori louables : n’est-il pas intéressant de prendre un tout petit temps à préparer un minimum avant d’aller le dur du développement ?Encore une sujet contre-intuitifLe Sprint Zéro, c’est un sujet qui divise !On a le camp de ceux qui soutiennent ce qui semble logique et naturel : on prépare son sac avant de partir en expédition ! On réfléchit à ce qu’on va dessiner avant de donner les premiers coups de crayon ! Et ainsi de suite. La conclusion est logique : il faut bien préparer des choses avant le premier Sprint. Faire donc le Sprint Zéro.Et on a le camp de ceux qu’on pourrait presque qualifier d’extrémistes du Scrum : mais non, on démarre direct par le Sprint Un, et voilà. Pourquoi un Sprint Zéro ??? Sans exclure la possibilité qu’un Sprint Zéro puisse parfois être une bonne idée, les cas de figure où c’est une pratique réellement pertinente sont minoritaires. Le Sprint Zéro est une mauvaise pratique.Pourquoi un tel clivage ?Et bien, parce que le sujet est contre-intuitif. L’intuition nous suggère bien qu’il est pertinent de faire un Sprint Zéro.“Ah oui ? Comment tu fais alors ?”En ce qui me concerne, je fais partie du camp de ceux qui militent contre le Sprint Zéro.Face à cette question du Sprint Zéro, Nadjat ATTOUMANE a pris le temps de me challenger de manière très concrète. (merci à elle !)À quel moment on se pose pour :- Commencer la construction du backlog[…]

    21.10.2019 | 11:46 קרא עוד...
  • Necessary Conversations – 1

    Thanks for meeting with me <fill in Project Manager’s name>!  I appreciate this opportunity to explore the testing approaches for this project.  I realize we have just started planning and have no product designs yet, but this is the best time to have this conversation. Soon, our team will begin to absorb and understand business needs, and transform them into viable products.  The Testing team, Testers and Test Engineers, look forward to collaborating with the team on that effort. Yes, I can see where you might believe there is nothing to test.  Many are mistaken in this belief that there must be a product before testing can execute.  I would argue that the business needs will require some scrutiny and I believe Testers are best equipped to ask questions about assumptions and details.  These questions will help clarify the needs, clarify product definitions, and reduce the number of defects resulting from misunderstood or poorly written definitions. Why the Test Engineers, then?  I’m glad you asked.  They listen to conversations for opportunities to make testing smoother for everyone.  By everyone, I mean Testers and Developers.  Basically, we have been practicing Shift Left, that is, moving evaluations closer to product construction.  We believe it can make a difference on this project. How?  When the project team delivers unit tests with their minimal viable products, we know requirements are probably met.  This helps the Testing team focus on risks.  The time to complete testing is likely shorter.  That improves Pace. Also, unit tests[…]

    21.10.2019 | 7:11 קרא עוד...

טיפים

לרשימה המלאה >>