When it comes to agile, we all know and practise standups, retrospectives, sprint plannings, showcases etc. Quite a few times, teams end up following these set of rituals and ceremonies without understanding the guiding principles of agile.
 
In this talk I will present some testing practices that various agile teams employ. Some of these practices are anti-patterns and have the exact opposite effect of what is expected, while others become an anti-pattern sooner or later if not tweaked according to the changing situations.
 
I will talk about the aspects like "Whose responsibility is Quality?", 'Measuring agile tester's success", "Balance between automation and exploratory testing". Along with each of the anti-pattern, I will present the remedies to fix these anti-patterns.
 
4 favorite thumb_down thumb_up 7 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  • Talk about the guiding principles of agile
  • Talk about few (8 to 10) anti-pattern stories that happen on a day to day basis in agile teams and cover the following for each story
    • Root cause of the situation
    • Guiding principles violated
    • Long term effects of the situation
    • Fixing the situation
  • Conclude with key take awyas

Learning Outcome

  1. Understanding the core principles of agile
  2. Measuring the success of QAs in an agile environment
  3. Understanding when to follow the rituals and when to stop
  4. Understanding the importance of collaboration between the various roles in a software development team

Target Audience

developers, project managers, product managers, quality analysts, testers

schedule Submitted 2 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Joel Tosi
    By Joel Tosi  ~  2 years ago
    reply Reply

    Hi KK,

        I like the format of the session - showing the reason, effect, and remedy.  That is a nice touch.  Your remedies are a little fluffy though to me.  During your presentation, will you give more concrete examples?  Some of the remedies are around 'collaborate' more - how? when? In what context? What if teams are separated by distance?  To me, that would greatly help attendees.

    Best

    Joel

    • KK Sure
      By KK Sure  ~  2 years ago
      reply Reply

      Hi Joel,

      Thanks.

      I presented this talk at ATAGG coference in November. While talking about causes, effects and remedies, I have described all three in detail during the presentation. I've kept those details out of the slides to keep it concise.

      Although, I can rework on the slides to include this important information explicitly. Hope that helps.

      Let me know if you have any other questions.

       

      Regards

      KK Sure

      • Joel Tosi
        By Joel Tosi  ~  2 years ago
        reply Reply

        Thanks KK.  I can appreciate keeping the slides concise.  Could you provide me with some examples that you would use in the session to help make it a little more concrete?

        Best,

        Joel

        • KK Sure
          By KK Sure  ~  2 years ago
          reply Reply

          Hi Joel,

          Here are few examples that I will talk about in this session. I will share these examples in relation with the appropriate story this example will be relevant in.

          1. Story kickoff: When talking about collaboration between different roles on a project, Story Kickoffs play an important role in mitigating risks like late detection of defects, scoping of the functionality per story, test strategy etc.

          2. Dev/QA pairing: 

          Pairing between Developers and QAs in reviewing unit tests and designing functional tests (UI, Integration, System) will get the team closer to having a proper test pyramid. Pairing across these roles also ensures shared ownership of the quality, rather than putting the onus on QAs/Testers alone.

          3. Story Done Definition: A loose definition of story done will result in a lot of unwanted and unnecessary defects. This in-trun demands rituals like bug bashes, which do not fit right in an agile context. A proper story done definition ensures that functionality is being signed off by the customers/product owners before being called Done.

          4. Showcases: Getting timely and frequent feedback on the software developed is core to agile. This ensures that the software development team is on the right track. Showcase is one such opportunity for agile teams to  gather feedback from product owners.

          5. Empirical forms of measurement vs. sheer numbers: Metrics like test coverage and reliability, trend of production defects over releases, trend of support calls post production release are much more relevant than number of defects found or fixed per week. 

          6. BDD: Behavior driven development enables development teams to drive the code by the desired end user functionality (acceptance criteria). This helps teams to share the ownership of the automated test suite.

          7. Cost Vs Value graph for test automation: Evaluating return on investment before automating every possible test scenario will help keep the test suite robust and the costs low.

          Hope this helps.

          On the second thought, I could put these examples on slides, in a concise manner. Please let me know what you think about that, and I will make the changes accordingly.

          Also let me know if you have any questions.

          • Joel Tosi
            By Joel Tosi  ~  2 years ago
            reply Reply

            Thanks KK.  I think having something in the slides, maybe not the examples but 'Try this' would be helpful. Think about your audience and when they leave your session, if they looked back on your slides it would be nice to have that example.

            Best,

            Joel

            • KK Sure
              By KK Sure  ~  2 years ago
              reply Reply

              Hi Joel,

              Here is a draft of the updated presentation: http://www.slideshare.net/kksure/testing-in-agile-antipatterns-and-remedies-draft

               

              I've put placeholder text in the 'try this' section of each story. I will replace these slides with appropriate pictures.

              Let me know your feedback on this.

            • KK Sure
              By KK Sure  ~  2 years ago
              reply Reply

              Thanks Joel.

              Thanks for the feedback. I really like the 'Try this' section idea. I will incorporate this in my slides.


  • Liked Sreedevi Vedula
    keyboard_arrow_down

    Sreedevi Vedula - Test Driven Development of Infrastructure Code in Chef

    Sreedevi Vedula
    Sreedevi Vedula
    Quality Analyst
    ThoughtWorks
    schedule 2 years ago
    Sold Out!
    60 mins
    Demonstration
    Advanced

    Chef is a popular Infrastructure Automation framework based in Ruby. It comes with a host of testing tools bundled with it like ChefSpec for unit testing, ServerSpec for system testing and TestKitchen for integration testing. This session is a demo of how to use these frameworks to test drive cookbook development.

  • Liked Vinod Kumaar R
    keyboard_arrow_down

    Vinod Kumaar R - Build it like sports teams

    Vinod Kumaar R
    Vinod Kumaar R
    VP Engineering
    Recruiterbox
    schedule 2 years ago
    Sold Out!
    20 mins
    Talk
    Intermediate

    Is it easy to get a crash course in football by Pele or Maradona for a week and produce a world cup winning football team?

    Answer is NO. Then why do lots of people in the corporate world think of hiring scrum trainers & expert developers to train their team for a week and then expect their team to undergo a transformation at a magical scale?

    German football team made it a point to transform their team and it took them a lots of years before they were able to reach the pinnacle. A quick side by side comparison of what is causing agile transformation to fail.

    Vision

    Football: Someone was there owning this entire transformation, the German football association spent a lot of time identifying talent in their teens and groomed them.

    Office: In the corporate world switching jobs every few years have become common, but there is no passing on of the context, resulting in the new person taking charge, starting from all over again, as well as frustrating existing good performers who have to rebuild the perception.

    Infrastructure

    Football: Players expecting state of the art training facilities, fitness programs and new shoes are not a luxury, it is a necessity.

    Office: Computers have become so cheap compared to the salaries, yet the policy of providing the best tools and good work environment are archaic.

    Coach vs Management

    Football: Coaches are given their due powers to help the team achieve the goal. It is very easy for anyone to comment on how professionals should play their game, there would be no use adhering to the metrics if the team cannot win. Winning is the only measure for management.

    Office: Often coaches are seen as part of the management or management tries to heavily influence coaching which results in a team which will work either for metrics or to please higher ups without the actual result that it had aimed for.

    Training

    Football: Just the ability to kick the ball does not make a footballer. Training will be introduced to increase physical strength & stamina, better mental wellness, injury prevention, tactics and strategy.  A heavy investment is made in the training facilities.

    Office: In the software industry a generation is about 2-3 years. Computer science degrees are nowhere near what is state of the art in the industry. At many places the on boarding process is either very shallow or not up to date with the recent developments, leaving people to learn most of the things hard way. Given too many things to learn and the information overload, this results in inefficient learning and application of knowledge on the job. We need to prepare people to find answers that are not available on Google.

    Team composition

    Football: Rookies don’t learn by watching greats from the bench, instead they play along with the veterans. Every sports team makes sure to have the right composition with a mix of rookies, emerging players and veterans. That is how they sustain a winning team.

    Office: Architects and Leads often do not code or are not part of the team every day, this means that most of the time the team just looks up to for advice or waits for reviews. There should be a good mix of people at all experience level so that there are enough people to try new things, enough people who have mastered few things and enough people who challenge change.

    Above all – Persistence

  • Liked KK Sure
    keyboard_arrow_down

    KK Sure - First Amongst Equals - Can UX be there?

    20 mins
    Case Study
    Intermediate

    Traditionally, in software development, user experience (UX) wasn't valued as much as developing of the software itself. But this has changed rather radically. However, creating an enriching user experience in an agile fashion is still challenging. Most of the agile engineering practices in use are around building software but seldom address UX. When building a product in an agile fashion, UX in an incremental fashion becomes important.

    In this talk, we will present our experience of creating UX in an incremental fashion for a virtual wallet. We will also talk about the different challenges we faced such as, educating various stakeholders on the value of incremental UX, building collaboration between developers and experience designers and abstracting design components, along with the solutions we devised to tackle these challenges.

  • Liked Krishnan Nair
    keyboard_arrow_down

    Krishnan Nair - Process Agility - the nemesis of business agility?

    45 mins
    Talk
    Advanced

    We've come far in our journey of Agile as a software development methodology. From stand-ups to showcases to sprint planning meetings to burn-ups (or downs), we've got it down pat when it comes to processes to follow to be considered Agile. However this heads-down, process defined agile, often hinders real agility required to meet business needs. Is doing a three hour sprint planning meeting every week the most important thing to do when you have to get a minimal-viable-product out in the market? How much of automated functional testing should you do when you know that your product's beta version is only going to validate assumptions of your business idea? Should you write tests at all? There is no formulaic answer.

    In this talk, KK and Krishnan will talk about their experience of how much Agile is too much Agile. We look at how to find the right balance between following agile practices and being responsive to your business. How much agile is too much and how less is too less?

    We will do this by looking at:

    • A couple of successful agile adoption stories
    • Look at why agile was successful in the contexts above
    • Discuss why this success will limit us if we are not careful
    • Talk about a start-up and how the things that led to success in the first 2 stories limited us in the start-up context
    • Look at approaches to understand what agile practices/processes to follow to be business agile
    • Close by summarizing the challenges facing agile (as we see it) and how success in process agility will limit us in business agility
  • Liked Fred George
    keyboard_arrow_down

    Fred George - Enabling Emergent Technologies

    Fred George
    Fred George
    Consultant
    Fred George Consulting
    schedule 2 years ago
    Sold Out!
    60 mins
    Keynote
    Intermediate

    The latest new, cool tool comes along. Will you be allowed to use it? Probably not! So how can you change that?

    This presentation looks at the introduction of new technologies at three companies, The Forward Internet Group in London (a start­up originally, now grown to 400+); MailOnline, the online version of the Daily Mail newspaper from London (a very old organization with an existing IT shop); and Outpace, a Silicon Valley startup.

    In both cases, Programmer Anarchy was introduced. This managerless process (not unlike GitHub in its value propositions) empowered the programmers to make technology choices and to freely experiment with new technology. In the case of Forward, massive growth and profits ensued. In the case of MailOnline, re­development of core systems into new technology has been launched, and expectations significantly exceeded.

    This presentation will touch on the various aspects of implementing Programmer Anarchy at MailOnline:

    • Team building through programmer training

    • Pilot project without managers, BA’s or dedicated testers

    • Reinforce the model with new HR structure emphasizing skills over titles

    • Create self­organizing teams of 5­8 developers (multiple such teams)

    • Charter teams with a specific project, and let them deliver

    • Avoid artificial schedule pressure

    The intent is to provide a possible roadmap to get your latest technical toys moved into production systems. 

  • Liked Sreedevi Vedula
    keyboard_arrow_down

    Sreedevi Vedula - Infrastructure As Code - The secret sauce for Continuous Delivery

    Sreedevi Vedula
    Sreedevi Vedula
    Quality Analyst
    ThoughtWorks
    schedule 2 years ago
    Sold Out!
    60 mins
    Demonstration
    Intermediate

    Developing Infrastructure as Code as a practice is increasingly adopted by organizations that want to have Continuous Delivery. Infrastructure As Code requires treating infrastructure as code, applying the same development techniques that one uses to build application software. This talk discusses the need for having infrastructure as code, the several frameworks available in this space (like Puppet, Chef, Ansible), what they bring to the table and the philosophical differences between them and the testing tools and frameworks available to test infrastructure as code. The concepts would be supported by snippets of infrastructure code written for an open source application.

  • Liked Sreedevi Vedula
    keyboard_arrow_down

    Sreedevi Vedula - The Practical Pyramid

    Sreedevi Vedula
    Sreedevi Vedula
    Quality Analyst
    ThoughtWorks
    schedule 2 years ago
    Sold Out!
    20 mins
    Talk
    Intermediate

    An Ideal Test Pyramid is an invaluable technique to succeed with agile. However, it is challenging to have this ideal pyramid in practical projects for several conditions in the projects, like legacy code bases. To have a good test pyramid, several best practices of software development need to be followed. This talk discusses the practices that help in implementing test pyramid and the challenges faced by many teams in doing that and suggestions on how to overcome them.