2016 Issue #1 | ASTQB Website | Certified Tester Lookup | Request Info | FAQ

How much do you know about the Agile process, the correct developer-to-tester ratio, and whether non-Agile teams can complete work faster than those which are Agile? Our featured article offers lessons in Agile implementation.

Articles in this issue:

• In the Agile Trenches with XBOSoft’s Clients
• BCS Works with ASTQB to Offer Certified Mobile Tester
• ASTQB and CMG Partner to Develop Performance Testing Certifications
• ASTQB Local Group Sponsorships
• ISTQB Worldwide Software Testing Practices Report Released
• News and Offers from ASTQB Accredited Course Providers
• Say Hello to ASTQB at These Events

Editor’s Note: With so much interest in Agile methodology, testing, and the ISTQB Agile Tester Certification, we thought it would be helpful to hear from those working with Agile day to day. We invite you to read the enlightening article below, and to learn more about ISTQB Agile Tester Certification at http://www.astqb.org/agile-tester/

Lessons in Agile Implementation
By Philip Lew, XBOSoft

As a software testing and QA consulting company that prides itself on strong relationships, we work very closely with our clients to make sure everyone meets their goals. But sometimes, we run into Agile implementation issues that make reaching those goals a little sticky. The difficulties of implementing Agile, whether into an organization that hasn’t yet touched on Agile or an organization that can’t seem to implement the methodology to a beneficial standard, take much work to overcome but the work put into implementation is rewarding. We sat down recently with one of our clients to discuss the constant battle that is Agile, which provided a lively discussion as we worked our way through different levels of the Agile process, the myth behind developer-to-tester ratio, and the idea that non-Agile teams can complete work faster than those which are Agile.

Developer Acceptance Testing – On the Spot
We started by addressing the importance of having a developer acceptance test (DAT) review right at the developer’s workstation level to get a demo of the solution to the user story in Agile methodology. This is absolutely vital to the Agile process since the concept of Agile is to increase efficiency by reducing the number of handoffs, approvals and meetings that prevent the client from getting to production sooner. Applying the proper solution the first time around is the key to making sure that time isn’t wasted, so having a DAT review at the base of the project ensures that getting the solution demo to the client won’t be a setback to their production.

Sprint Execution and Scaling
Moving forward to the sprint execution level, we delved into the idea of whether or not a Test Manager or QA Manager plays a role in the Agile process if that level mostly consists of QA testers and engineers. We find that when there is scaling involved, QA managers are involved too. They oversee the QA engineers and testers when the company reaches a size that would make sense to set standards, policies, resource allocation and recruitment. This helps organize the “bigger picture” and allows teams to work on a strategic level, as opposed to a tunnel-visioned, tactical level. Some companies say they like to handle these situations with a sort of matrix organization: managers at the Agile team level and "domain leads" at the functional level. This way, there can be one team at both the tactical and strategic levels, with a QA Domain Lead who can oversee everything.

Developer-Tester Ratio
While the lead watches over the team, he or she might worry that there is an uneven number of developers and testers. However, there isn’t reason to worry because the developer-to-tester ratio really depends on the team’s needs. Making sure that your team is successful requires team work and shared responsibility, so the necessary developer-to-tester ratio is not a hard science— the right balance is contingent upon a variety of factors such as the skills of the testers and developers in your team, the amount of test automation used, who’s responsible for writing test automation, and even the stability and experience of the team in working together. If your team needs three testers for every one developer but everyone else says they only need a two-to-one ratio, keep in mind that that is the ratio at which your team can deliver the necessary results. As long as your Agile team is committed to the sprint and everyone is on board with helping to complete all of the sprint scope, the developer-to-tester ratio will vary between organizations.

Acceptance Criteria
Aside from a suitable developer-to-tester ratio, acceptance criteria in user stories at the planning and scope level also needs to be available for success. It is crucial to planning, and planning requires sized tickets, which require an understanding of the scope of each ticket. In order to avoid over- or under-engineering, acceptance criteria is used to set expectations between the product owner and the team, and within the team itself. Ensuring that all tickets include acceptance criteria from both business and technical perspectives also encourages total team engagement, a necessary organizational trait that determines when the team can reach the point where a user story can be considered completed and closed from both development and testing perspectives.

Velocity or Not to Velocity
But what do you do when your non-Agile teams are completing and closing tickets faster than Agile teams? Well, it’s unlikely that non-Agile teams will work more quickly than an Agile team because non-Agile teams require long, detailed documents that cover many aspects of the testing process. These take more time to produce than the shorter documents used in Agile testing, and stakeholders aren't as involved in non-Agile testing so feedback from stakeholders isn’t received until after much of the testing has been completed. In Agile testing, stakeholders participate in sprint reviews every two weeks during the testing process, which allows them to better guide the Agile team toward their vision and the client’s real needs, as opposed to waiting until the end to make changes and redirect. Essentially, non-Agile teams are expected to take longer to reach the right solution for the client.

Despite the definitions and expected responsibilities of non-Agile and Agile teams, depending on the company’s methodologies in use and its current phase, their teams can work faster without Agile if there really isn’t a need for the benefits and structure of Agile, such as visibility for the client or product owner, or user stories and sprints for organization. If your teams are small and nimble, then non-Agile teams can be advantageous. However, at scale, if a non-Agile team is working faster than your Agile teams, there is probably something wrong with the process or implementation, and investigation into quality metrics is probably needed.

Being Agile about Agile
When choosing to run non-Agile or Agile teams, you have to determine what will allow your team to perform better to deliver the best solution to meet the client’s needs. Non-agile teams may be able to perform faster, but then at the end, when the product gets delivered, get bogged down in final sign-off, with the net result not only being slower to production, but not meeting the needs of the client.

Working together to get through each sprint and iteration requires a willingness and dedication from your team that, once harnessed, can provide you with all of the proper tools to becoming an “agile” organization. And note that you don’t have to define ‘agile’ by some textbook, or what someone else is doing. You can be so-called waterfall or ‘non-agile’ and borrow methods from agile to form your own hybrid. Common borrowed items are prototypes with demonstrations (notice the different terminology but it’s all in alignment with agile principles of getting feedback), and frequent short meetings (called stand-ups or whatever you want to call them) to go over blocking issues and priorities.

SQE Training: Continue your journey along the ISTQB® certification path. Receive special savings on Advanced Level Certification courses for Test Managers, Test Analysts, and Technical Test Analysts through SQE Training. Save $300 when you register here by May 31 with promo code AST300. Have colleagues that need training too? Groups always save with SQE Training! Email groups@sqetraining.com for a custom group quote. *Restrictions apply, only valid on new registrations.

Rice Consulting: Rice Consulting Services is excited to offer the new ASTQB Certified Mobile Tester course in e-Learning format, as well a public class to be taught by Randy Rice in Irving, TX on April 19 - 20, 2016. Use code MOBILE2 to get a 10% discount on individual registrations. Groups of 3 people or more get a discount of 15%. Offer expires on April 15, 2016. If you would like an in-house presentation, just e-mail webrequest@riceconsulting.com for a custom quote.

RBCS: 15% off of RBCS’ ASTQB Virtual Certified Mobile Tester class! This hands-on course provides testers and test managers with an understanding of the fundamentals of testing on mobile projects. This course was accredited by the ASTQB January 2016. The course follows ASTQB Mobile Tester Syllabus 2015.  Visit our store and enter the code Vmobi16.  Your discount will be reflected in your final receipt. Expires July 1, 2016. 

ALPI: Let ALPI train & certify and your test team in 2016 and SAVE with multi-person discounts at any of our 3 locations: Bethesda, MD, Denver, CO, or Virtual Live. Choose ISTQB Certification Training: Foundation Level & Agile Tester, Advanced Test Analyst & Test Manager. Or choose Test tool Training from HP (QC/ALM,QTP/UFT,LR/PC) and Microsoft (MTM,CodedUI,LoadTest). Contact our Training & Education team at training@alpi.com or by calling (301) 654-9200 ext. 403. Offer expires May 15, 2016.