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

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

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

  • The challenge of prioritizing bugs

    The challenge of prioritizing bugs ...

    20.10.2019 | 11:07 קרא עוד...
  • 92: 9 Steps to Crater Quality & Destroy Customer Satisfaction - Cristian Medina

    Cristian Medina wrote an article recently called "Test Engineering Anti-Patterns: Destroy Your Customer Satisfaction and Crater Your Quality By Using These 9 Easy Organizational Practices" Of course, it's sarcastic, and aims to highlight many problems with organizational practices that reduce software quality. The article doesn't go out of character, and only promotes the anti-patterns. However, in this interview, we discuss each point, and the corollary of what you really should do. At least, our perspectives. Here's the list of all the points discussed in the article and in this episode: Make the Test teams solely responsible for quality Require all tests to be automated before releasing Require 100% code coverage Isolate the Test organization from Development Measure the success of the process, not the product. Metrics, if rewarded, will always be gamed. Require granular projections from engineers Reward quick patching instead of solving Plan for today instead of tomorrow Special Guest: Cristian Medina.Sponsored By: Azure Pipelines: Automate your builds and deployments with pipelines so you spend less time with the nuts and bolts and more time being creative. Many organizations and open source projects are using Azure Pipelines already. Get started for free at azure.com/pipelines Support Test & CodeLinks: Test Engineering Anti-Patterns: Destroy Your Customer Satisfaction and Crater Your Quality By Using These 9 Easy Organizational Practices — The article we discuss in the show. tryexceptpass — Cris's blog

    20.10.2019 | 2:00 קרא עוד...
  • What is a Customer?

    What Is A Customer? In the world of Agile, and the world of business too, we hear a lot about “customer value”. Folks seem to have some kind of handle on “value” (although not everyone can agree on that one – see my post “What Is Value” for my take, based on Goldratt and his Theory of Constraints). And for the record, we might also choose to frame the question of value within the Antimatter Principle frame, and vocabulary: Value: The degree to which folks’ needs, in aggregate, are being (or have been) met. But what about “customer”? So simple and straightforward. Do we even need to define it? I thought not, until a recent conversation on Twitter gave me pause for reconsidering. Specifically, the idea that maybe folks are talking at major cross-purposes, with significantly differing assumptions and definitions for the term. If we can’t agree on a basic term like “customer”, what chance alignment of a whole host of fundamental questions about software, products and business generally? Here’s my definition, again using the Antimatter Principle as a frame: Customer: Someone (could be either a person, or a collection of people) whose needs we’re attending to. I’m pretty sure you’ll have a different definition of customer. I’d love to hear your take. Before I close this post, here’s a different definition, informed by Crosby and his Zero-Defects (ZeeDee) approach to quality: Customer: Anyone who receives or anticipates receiving something (e.g. a good or a service) from someone else. This[…]

    19.10.2019 | 5:51 קרא עוד...

טיפים

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