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

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

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

he icon   en icon

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

מנהלי בדיקות ב Agile - יש דבר כזה?

נכתב על ידי 
ראשון, 04 ספטמבר 2016 10:46
דרגו כתבה זו
(3 הצבעות)

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

לאן נעלמו המנהלים?

האם עולם ה Agile גרם לנו להתפתח? או שאולי הוא מתאים רק בסוג מסוים של אנשים? או שאין מקום/צורך במנהלים בעולם ה Agile?

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

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

אולי אנחנו מיוחדים, שונים או מוזרים, אבל זה עובד לנו. ללא מנהלים שיעקבו, ינהלו ויקבלו דיווח שוטף על העבודה שלנו, העבודה נעשית על הצד הטוב ביותר. מתודולוגיות ה Scrum מכתיבות לנו 100% שקיפות ואחריות. אנחנו משתפרים ומתפתחים ללא שיהיה גורם שיניע אותנו חוץ מאחד את השני, שווים בין שווים.

אז אני חוזרת לשאלה הראשונה, מנהלי הבדיקות נעלמים? האם מקומם הינו רק בעולם ה Waterfall?

לדעתי, יש מקום וצורך לטפח בעולם ה Agile, את תפקיד ה QA Tech Lead, שיהיה מוביל ונותן טון עבור הבדיקות, תוך כדי עבודה בצוות הפיתוח – 100% hands-on.

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

שונה לאחרונה ב ראשון, 04 ספטמבר 2016 11:00

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

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

  • EarlGrey 2 —Direct Project Copy Setup Guide

    EarlGrey 2 —Direct Project Copy Setup Guide This post is part of a group of articles aimed at helping you set up & get started with EarlGrey 2.This post covers the set up of EarlGrey 2 in your project, using a direct project copy. Both video and written setup are provided!I. Copy EarlGrey21. Clone Earlgrey 2 repository into your project — make sure to clone the earlgrey2 branch!Tip: git clone -b earlgrey2 https://github.com/google/EarlGrey.git2. Download earlgrey2's dependencies. Tip: To do that, in the terminal, navigate to the EarlGrey2 directory, then run the following shell script:sh Scripts/download_deps.shMake sure that after this step, your folder structure is as follows:EarlGrey/SubmodulesII. Add EarlGrey2 to your project1. Open Earlgrey xcode project and make sure that both AppFramework and TestLib build.2. Add the EarlGrey.xcodeproj file to your project’s Xcode. Tip: To do this, drag the earlgrey.xcodeproj file from the EarlGrey directory to your project. Make sure that the project is added under your project — otherwise xcode will ask you to create a workspace and you don’t want that.III. Add an EarlGrey2 UI Testing TargetCreate a UI Testing Target if you don’t already have one!Open your UI Testing Target, and in Build Phases, add LibTestLib.a into the “link with libraries” section. Tip: When you press the + button, you should be able to find it by using the search bar — It should show up under the EarlGrey project.In Build Settings, add -ObjC to Other Linker Flags.Add the location of EarlGrey and eDistantObject to your User Header Search Paths.Tip: If you followed the step number 3, these directories should be under$YOUR_PROJECT_DIR/EarlGrey$YOUR_PROJECT_DIR/EarlGrey/Submodules/eDistantObject5. Add AppFramework — in Build Phases, create a New Copy[…]

    13.12.2019 | 7:38 קרא עוד...
  • How Testing Software is a Lot Like Playing Poker

    How Testing Software is a Lot Like Playing Poker From Omaha Hi-Lo to No-Limit Texas Hold'Em, poker can take hours, be entertaining and at times, nail-biting fun. Poker is a popular, high-stakes game and every hand can be different. There's a mental strategy in poker that's required to tell different hands, recognize a bluff and read the actions of every player. While it might not look like it, testing out new software is similar to playing a hand of poker. Poker games and software testing both require math, probability and intuition."If you can't learn from your experiences, you just aren't going to win," John Cernuto Play a hand of poker and you can easily find yourself calculating the risks and rewards. It's similar to any business or investment strategy and parallels software testing. Bill Gates probably summed it up best, "A player collects different pieces of information—who's betting boldly, what cards are showing, what this guy's pattern of betting and bluffing is—and then crunches all that data together to devise a plan for his own hand." This is a step often seen with processing different types of information. Poker games require a plan of attack and players need to analyze the actions of others."May the flop be with you," Doyle BrunsonAnother similarity between poker and testing software is the initial analysis. In poker, the players need to assess how all the other players are playing each hand. Are they all playing a big pot? It might be a tell that they have a big hand. Likewise, if they play loosely with small pots,[…]

    13.12.2019 | 5:52 קרא עוד...
  • QA&TEST 2019 – Pro Tester using Fault Injection

    QA&TEST 2019 – Pro Tester using Fault Injection Since the start of my career as a tester, I’ve always been obsessed with testers delivering tangible value to the business. I realized ‘redefining software quality’ was my calling. There were quite a few powerful stories that lead to this realization, and one of the most important ones I presented at the QA&TEST 2019 conference. This was a story about testers taking responsibility and recognizing how important it is to understand the underlying technology of the product. From this event emerged the three core values I feel which can reshape how we think about software quality. This talk was awarded the best presenter award at the QA&TEST 2019 conference,  Award ceremony video here. I thoroughly enjoyed the conference, the city and the hospitality. I talked about it in this article and a short shout out for the organizers on a job well done. Presentation key points Out of scope The products being very complex, it was impossible to test everything through black box testing. Areas which the testers were unable to understand how they work, or there was no way to test them, were not considered as the tester’s responsibility. While quality is everyone’s responsibility, but testers do need to make sure all bases are covered. It isn’t necessary that everything must be tested by a tester, but a tester should make sure that ‘someone’ is testing all the areas that should be covered.   Code coverage Code coverage is not the only measure to check, but certainly is one[…]

    13.12.2019 | 5:39 קרא עוד...

טיפים

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