More Related Content
![[HCMC STC Jan 2015] Workshop Of Context-Driven Testing In Agile](https://cdn.slidesharecdn.com/ss_thumbnails/nhatdo-vuduongworkshopcontext-driventestinginagile-150208225650-conversion-gate02-thumbnail.jpg?width=560&fit=bounds)
![[Mush Honda] Software Testers From Good to Great](https://cdn.slidesharecdn.com/ss_thumbnails/mushhondasoftwaretesters-fromgoodtogreat-140717230218-phpapp01-thumbnail.jpg?width=560&fit=bounds)
Similar to Test Automation in Agile: A Successful Implementation (20)
Test Automation in Agile: A Successful Implementation
- 1. AT16 Agile Development Concurrent Session 11/13/2014 3:00 PM "Test Automation in Agile: A Successful Implementation" Presented by: Melissa Tondi ProtoTest Brought to you by: 340 Corporate Way, Suite 300, Orange Park, FL 32073 888-268-8770 ∙ 904-278-0524 ∙ [email protected] ∙ www.sqe.com
- 2. In the software test/QA/quality engineering field for more than fifteen years, Melissa Tondi focuses on organizing software testing teams around three major tenets―efficiency, innovation, and culture. Currently, Melissa is a vice president for ProtoTest and the founder of Denver Mobile and Automation Quality Engineering community. Her previous roles have been as director of software quality engineering for a 150+ person organization for the world's largest education company; QA consultant for health care, finance, and SaaS industries; and the president of Colorado's Software Quality Association of Denver (SQuAD).
- 3. U S I N G B A S E L I N I N G / G C D ( G R E A T E S T C O M M O N D E N O M I N A T O R ) T E C H N I Q U E S T H A T A R E I M P O R T A N T T O Y O U R T E A M Automation and Agile – Successful Implementation
- 4. Takeaways WHAT is Automation? WHO Cares about Automation? WHERE does Automation Belong in the Agile team? WHEN should it be done? WHY has it been unsuccessful for most? HOW can you ensure it is successful for your team?
- 5. WHAT is Automation? “Automation makes humans more efficient, not less essential” For this Talk, we’ll level-set and say that it is the Automation of Test Cases/Scripts/Scenarios But, remember, Automation concepts can be applied to all repetitive functions Rules of Thumb: If it’s done more than once, it should be a “first” candidate for automation Automation criteria should be defined by the discipline, but understood by its counterparts Not everything can and should be automated – leave that to the experts on your team. In this case, the Test team WHAT is it not? It’s not necessarily a replacement of humans, but in some cases it may result in that It is not a silver bullet with a one-to-one ratio of humans versus licenses
- 6. WHO Cares? We all do – right? What’s more important is, WHO do we need to convince? Usually, the person who makes the decisions to buy a tool, is not a practitioner themself. One reason why Open Source tools have a greater adoption and usage rate. Have Reasonable Buy-in from the Team, but don’t be Afraid to Make a Decision Experts, Mid-level, Novice/Beginners – choose a subset Choose a Technical Committee Open Question: WHO are you on your Agile team and what do you value most in automation?
- 7. WHERE does Automation Belong? Everywhere! Okay, okay, let’s skip the generalities: The tasks should be estimated just like any other task – there is not a need for the “iteration behind” approach (what’s this?) If you are practicing TDD, before coding begins In the Acceptance Criteria If you want to ensure something gets done, tie it to success – in this case, the Acceptance Criteria In the Test strategy
- 8. WHEN should it be done? At the Beginning, middle and end! Well, duh – but what does that really mean? Before (TDD) coding begins If not TDD, when coding begins – you don’t need completed code to test. Rule of thumb: if Development is not checking in/deploying code for Test within three days of the start of an iteration, consider breaking down user stories in to smaller chunks
- 9. WHY has it been unsuccessful for most? A tool is purchased and unreasonable expectations are mandated Have you ever heard these statements? Within 3, 6, or 9 months, everyone must be an Automation Engineer We are spending $2.5 million on this tool, we better justify that cost EVERYTHING must be automated! Record/Playback (i.e. the Demo from Sales) is the shiny object The faster the UI is automated and played back, the more value the tool has to those who pay the bills There is no guidance on automation criteria or priorities EVERYTHING must be automated! Maintenance of the scripts is not accounted for Rule of Thumb – build in 15-20% for maintenance and treat it as technical debt
- 10. HOW can you ensure it is successful for your team? Set Reasonable Expectations with Skill Sets If the Test team has mostly been manual, expect only a 25% success rate within the first six months Not all Developers can/should be automation engineers – hire the right people (if you can) Let the team choose the tools they want to use to automate – within reason Use the paid tools only when needed. In most cases, Open tools get 50-60% of the job done, but you generally pay for robust reporting Have Reasonable Buy-in from the Team - Experts, Mid-level, Novice/Beginners – choose a subset Choose a Technical Committee
- 11. HOW can you ensure it is successful for your team? Ask the “W” questions and let the answers determine the end result: WHY do you want/need to automate? The answers may surprise you. Assemble those answers and have an open discussion. Remember, Test owns the implementation, but the Agile team owns its success. WHO can automate? Can they begin now, or do they need training? There is nothing wrong with transitioning the tasks to those who have the skills first – be realistic with your velocity WHAT will we do with this automation once it’s complete? Be Honest with this one!
- 12. HOW can you ensure it is successful for your team? Start small, but be consistent What are the tests that Test executes the most? Smoke/BVT/ Sanity. Automate them! Which tests are most important to Development? Automate the Acceptance Criteria! Why? This ensures that it is agreed to and understood by the team It is the most important piece of information to determine a release’s success. It can serve as the demo to the Product Owner within distributed teams (or local) Treat the scripts like code – check it in, perform code review, package it with the release, etc. For teams with an “Us vs. Them” challenge, this helps strengthen the bond between the two disciplines
- 13. WHAT is this Baselining/GCD thing? GCD = Greatest Common Denominator. Find the common theme that each member can relate to. 1. Establish the topic or item to discuss – In our case: Implementing Automation Successfully 2. Define the collaborators/decision makers – should be a subset of each department or discipline for teams. In this session – I assumed, based on your attendance, that this topic was interesting to you. 3. Define terms (seems tedious, but is so important). We did this by defining automation for this session. It relates to Test.