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

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

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

he icon   en icon

לבדוק או לא לבדוק? - זאת השאלה

נכתב על ידי 
שישי, 05 יוני 2015 16:56
דרגו כתבה זו
(5 הצבעות)

לבדוק או לא לבדוק - זאת השאלה

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

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

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

1. מתי כבר הורצה הבדיקה? – האם יש טעם להריץ אותה כעת שוב?

2. מה השתנה מאז הרצתה הקודמת?

3. האם זו בדיקה ידנית או אוטומטית?

4. כמה זמן לוקח לבצע את הבדיקה?

5. האם בדיקה זו נכשלה אי-פעם בעבר?

6. האם רבים משתמשים בתכונה הנבדקת?

7. האם יש לנו היכולת לבצע ולנתח את תוצאות הבדיקה?

8. האם יש לנו כח אדם / זמן לביצוע הבדיקה?

9. האם הבדיקה הזו עדיין רלוונטית ונכונה?

10. האם זו הדרך הנכונה להריץ הבדיקה בשלב זה?

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

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

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

טיפ זה הופיע בגיליון #1 של מגזין עולם הבדיקות - http://goo.gl/sMeEMH

פוסט זה מבוסס על רעיון שהועלה בפוסט של John Andrews :

http://testingfromthehip.wordpress.com/2014/07/15/release-testing-to-do-or-not-to-do-that-is-the-question

 

לבדוק או לא לבדוק small

שונה לאחרונה ב שישי, 05 יוני 2015 17:09

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

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

  • TestCamp – a short relation

    TestCamp – a short relation Disclaimer Occasionally I cooperate with TestArmy as Trainer.TestArmy is the main organizer of TestCamp. First thing first I would like to formally Apologise to Damian Szczurek for forgetting his name on stage. I am really sorry it wasn’t intentional. What is TestCamp? TestCamp is Conference addressed mostly for younger testers still trying find their footing in IT world and our profession. At least that was the idea of the first edition looking at the subject on this one I think this year didn’t have as clearly targeted audience. There was still a lot of beginner level subject, but there were a few more advanced ones. Also, there was a lot of experienced testers in the audience. How was the conference? This time I won’t describe a presentation after presentation. I will present my top picks. As far as I am aware they will be available online on testuj.pl youtube channel. So you can watch them yourself. But first few things about the organization. Everything was running smoothly, even better then some other conferences but there are 3 things I didn’t like:THE HUGE PILLAR in the centre of the stage. with poor lighting. That’s why I decided to present outside of the stage. Another thing is there weren’t enough places to leave the plates glasses after taking the snack. And the snack areas basically had choke points at the entrances. So which presentations I liked? Nauka na błędach – root cause analysis w praktyce –  Katarzyna Balcerzak had great keynote about root cause analysis.[…]

    23.09.2018 | 1:02 קרא עוד...
  • Demystifying Machine Learning, Part 6

    Demystifying Machine Learning, Part 6 In the last post, we defined our neural network by providing it some specific hidden layers that will provide the basis for how the neural network model actually works. We were also able to dig in a bit to what’s happening behind the scenes. In this post, we’ll actually execute the neural network by feeding it the data and evaluating what gets produced as output. This will be the final post in the series and much of the points I make here have been covered in some way, shape or form in the previous posts in this series. My goal in this final post is to finish off the neural network we started in the previous post. This will actually be the second implementation of the same neural network you already developed. I did a few steps at the end of the previous post to help you visualize the model that had been created. Those statements weren’t strictly necessary for the operation of the network. Let’s level set and consider what script you should have in place. In your mnist.py, here is what you should have: import numpy as np import matplotlib.pyplot as plt from keras.datasets import mnist from keras.utils import np_utils from keras.models import Sequential from keras.layers import Dense, Activation (train_images, train_labels), (test_images, test_labels) = mnist.load_data() total_pixels = train_images.shape[1] * train_images.shape[2] train_images = train_images.reshape((60000, total_pixels)) test_images = test_images.reshape((10000, total_pixels)) train_images = train_images.astype('float32') test_images = test_images.astype('float32') train_images /= 255 test_images /= 255 train_labels = np_utils.to_categorical(train_labels) test_labels = np_utils.to_categorical(test_labels) total_classes =[…]

    22.09.2018 | 11:31 קרא עוד...
  • The sprint planning meeting that goes on forever | SupremeAgile

    The sprint planning meeting that goes on forever | SupremeAgile The sprint planning meeting is the longest meeting in the scrum framework and based on my experience it also the most exhausting meeting for most teams. The most difficult thing about this meeting is that team members often come to this meeting with the mindset that it will take the exact time written in the book…but it doesn’t! In scrum we have a very important term called timeboxing. A time box is an agreed upon and limited box of time that is used by a person or team to perform a dedicated activity (see here for more information about timeboxing). Everything in scrum is time-boxed, including the scrum planning meeting, so what happens when the meeting time is near the end, and the team hasn’t determined the goal or sprint backlog? Do we end the meeting and continue it next week? Should we extend it? Do we just end it? This scenario happens over and over, especially for new scrum teams that have neither the maturity nor the experience to conduct an effective sprint-planning meeting. So, what should one do in this scenario? To be honest, it really depends on what you want to achieve, but some common solutions that I love to use are: Let the team learn the hard way Let’s say that you have a team that is not willing to change their habits and continuously ignores the meeting’s timeframe. In this case, you can cut the meeting at the end of the time box, which will make the[…]

    22.09.2018 | 10:05 קרא עוד...

טיפים

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