Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

QA team transition to agile testing at Alcatel Lucent


Published on

In this session I will outline/explore the journey of a common QA team without coding skills into Agile testing arena. Main focus on Acceptance Test Driven Development and executable specs. The session will be based on a real case study from Alcatel Lucent Haifa. At the end of the session you will understand the concept of executable specs,and ATDD, You will see real example of test implementation in ATDD tool (Cucumber) and will understand the steps required to make such transition with some do/not do tips in tool and process implementation (based on Alcatel case study).
You will get (printed) the suggested implementation plan and do/not do tips of ATDD automation tools implementation

Published in: Technology
  • Be the first to comment

QA team transition to agile testing at Alcatel Lucent

  1. 1. All Rights Reserved - AgileSparksQA TeamTransition toAgile TestingAlcatel-Lucent Haifa – Case StudyLiat Arad-Bitan – QA manager, Alcatel-LucentDr. Ronen Bar-Nahor – AgileSparks1
  2. 2. All Rights Reserved - AgileSparksBackground• Alcatel-Lucent (Haifa) specializes in contentmanagement solutions for tier-1 carriers• Decided to develop a new platform forcontent management for SaaS providers• Moving to new technology, developmentenvironment and Agile • ~30 developers• ~15 QA people (manual testing), 1automation expert2
  3. 3. All Rights Reserved - AgileSparksWhat We Achieved• Better quality … Continuously Working System!• More than 90% coverage• Refactoring with less fear and minimal regression efforts• E.g. Replace the database … Components …• Improved efficiency/reduced waste:• Reduced code freeze period• Test documentation maintenance• We develop only what is needed• We test only what was developed• We have full traceability for free• Re-use of automation code• QA plays a key role in the Scrum team• Better business understanding• Provides value to the team (not just “bug hunters”)• QA-Dev collaboration• High motivation (but some left…)3
  4. 4. All Rights Reserved - AgileSparksAcceptance Test DrivenDevelopment - ATDDAdd a testWrite some codeTests passed?Run testsRefactorDevelopmentfinishedYesNoNoYes20%75%
  5. 5. All Rights Reserved - AgileSparks5QA implementation steps• Agile training for QA leads, Exposure to ATDD• Sprint “zero”• Looking for ATDD tools (Jbehave, Cucumber, Fitnesse )• POC for a simple story• Decision on the BDD format• Chosing Cucumber (easy to learn, active community)• Train the team to write code• Frustration and fear from writing code• 1 week training on Java• Train in ATDD and BDD writing• Inspect and Adapt – more coaching 5
  6. 6. All Rights Reserved - AgileSparks6QA implementation stepsTips• Promote the new tester role• Represents the PO within the team• Train early the entire team on ATDD (fail first) andhow to write good BDD• Understanding the framework (Text<->code) is a must!• It is not so difficult to learn to write automation• Automation champion to support the QA team  a must• Need more focus on software engineering• Scrum team support  shared ownership• Read the Cucumber book!• Join the community6
  7. 7. All Rights Reserved - AgileSparksTIP - What we expected from anATDD tool ?• Express expectations in a language and format that allowcollaboration among the whole team• Minimum of test code• Test code written in the team’s “native” language• To play nicely with source control systems and continuousintegration• Pluggable to support a variety of interfaces (e.g. UIautomation)• Can become a product spec (documentation tool)• Active community7
  8. 8. All Rights Reserved - AgileSparksAcceptance Test DesignBDD approach - Behavioral Driven Development• TIPS• Working software over comprehensivedocumentation• No more huge textual test documents & documentsmaintenance• Document only the purpose, expected behavior and data• Code the steps !• Executable specs• Describe ALL expected business behavior• Decide later what will be tested in which level (UT, Manual, AT)
  9. 9. All Rights Reserved - AgileSparksAcceptance for MMF – Minimal Marketable Feature(MMF) smallest set of functionality that must be realized inorder for the customer to perceive value.
  10. 10. All Rights Reserved - AgileSparksWill it always fit into iteration ?• MMF describes the systembehavior  the product spec, nothow it was developed• Might be split into user stories• User story is a planning tool,covers MMF’s scenarios, They existuntil implemented and then theydisappear !TIP – Write Acceptance tests for MMF.Will be expanded while elaboratingstories DoD.
  11. 11. All Rights Reserved - AgileSparksBDD structure (Given-When-Then)Feature – [Feature/MMF title]As a [role] I want [feature] So that [benefit]Scenario 1: [Title/test purpose]Given [context/system state]And [some more context]...When [event/action] and [ next event/action]Then [outcome]and [another outcome]...Scenario 2: ...TIPS:• BusinessLanguage(and nottester)•ExtractData•Coaching
  12. 12. All Rights Reserved - AgileSparksExamples• Feature: Standard SignupAs a new user I want to create an account so that I canuse the applicationScenario: Signup with valid email/password combinationGiven I do not have an accountWhen I signup with email and passwordThen I should be logged inAnd my profile details should be filled in
  13. 13. All Rights Reserved - AgileSparksBDD Feature fileMMFUser storytagTestpurposeIn unittest/manualExtractDataThen …
  14. 14. All Rights Reserved - AgileSparksBDD code (java)14• Given  initial state for the test
  15. 15. All Rights Reserved - AgileSparksBDD code (java)15• When  user/system actions
  16. 16. All Rights Reserved - AgileSparksBDD code (java)16• Then expected results
  17. 17. All Rights Reserved - AgileSparksFrameworks, interfaces, drivers
  18. 18. All Rights Reserved - AgileSparksTIP - BDD Design• Integrate ATDD into the release process• PO writes User Story description in Jira• QA prepares BDD (after team sniffing)• PO reviews with the QA (and dev rep)• BDD is a condition for “ready story”• It is a step in the Kanban flow18
  19. 19. All Rights Reserved - AgileSparksBDD as part of ready story.Early integration (component teams)19Scrum+BDDDev2devintegrationIntegrationpoints/NFWriting theBDD for aUSE2E and NFT
  20. 20. All Rights Reserved - AgileSparks20TIPS - BDD Development• Team commits to the BDD!!!• Developer and QA review together the BDD and agree:• What to test, by whom and how to automate it(unit/acceptance)• Comment the unit or manual steps/scenarios in the BDD• Developer develops first the “API contract”• QA develops the automation (code review withdeveloper)• Developer works until BDD pass (end of iteration), QAworks on BDD of next iteration20Scrum Level 3Sprint 1 Sprint 2 Sprint 3PSPPSPPSP
  21. 21. All Rights Reserved - AgileSparks21TIPS - BDD Execution• Automation of a new story is executed only in thedevelopment environment (not to break the productbuild)• Once the Story is done (ATDD - all automation is pass) andchecked-in the main trunk also, the automation isactivated.21
  22. 22. All Rights Reserved - AgileSparks22Continuous Integration22
  23. 23. All Rights Reserved - AgileSparks
  24. 24. All Rights Reserved - AgileSparks
  25. 25. All Rights Reserved - AgileSparks
  26. 26. All Rights Reserved - AgileSparks26Make tests independent• Init state - Automate static test data creation• System level (all features) - Develop set-up utility• Feature level - Use Given step (without action)• Scenario level - Use background (cucumber)• Roll back system state• Delete scenario data at the end of the test scenario• Delete setup data at the end of test execution26
  27. 27. All Rights Reserved - AgileSparks27Re-use of steps/code• BDD steps reuse (execution)• Requires common data accessibility, e.g.:• Common member/code• Common data structure results• Change the data (BDD), re-use the code• Java utilities for actions/common behavior• Includes API calls that shall be easily replaced27
  28. 28. All Rights Reserved - AgileSparks28Re-use exampleFeature - Add UserGiven system admin existsWhen creating user with attributes:id|name | phone |1 | Ronen | 00000 |Then user created successfullyid|name | phone |1 | Ronen | 00000 |28Feature - Update UserGiven creating user with attributes:id|name | phone |1 | Ronen_1 | 55555 |And fetching user data|name ||Ronen_1 |when updating user with values:id| name | phone |1 | Liat | 00001 |Then user updated successfully:id| name | phone |1 | Liat | 00001 |Feature Get UserGiven creating user with attributes:id| name | phone |1 | user test | 21234545 |When fetching user data|name ||user test |Then user is fetched:id|name | phone |1 | user test | 21234545 |
  29. 29. All Rights Reserved - AgileSparksCOPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.E2E Re-Use Example“Saas provider” componentModule (source)Acceptance testsJavaFeatures“Admin user” componentModule (source)Acceptance testsJavaFeatures“Common” testingJavaE2E testingFeaturesjarjarjarGiven system admin logs inWhen calling createSaasProvider APIwith parameters: “Saas1”Then Saas Provider “Saas1” is createdGiven Saas provider Saas2 in the systemWhen calling createAdminUser API withparameters “Admin1”Then admin user “Admin1” is createdGiven system admin logs inWhen calling createSaasProvider API withparameters: “Advanced TV”And calling createAdminUser API withparameters “Advanced TV Admin”Then Saas Provider “Advanced TV” is createdAnd admin user “Advanced TV Admin” iscreated
  30. 30. All Rights Reserved - AgileSparksGUI automation• Development framework AngularJS• Carma – UT (for java script) + AT• Phantom browser (better performance)• Any browser (E2E)
  31. 31. All Rights Reserved - AgileSparksWhat next• Schedule work based on E2E priorities (toreduce cycle time)• Improve the Dev2Dev integration test• Executable spec …31
  32. 32. All Rights Reserved - AgileSparksTHANKS !32
  33. 33. All Rights Reserved - AgileSparks33Component, Integration &E2E Testing• Component testing• A Component is an independent unit  expose services• Tested with stubs in local component environment• MMF might be developed across components• MMF Integration testing (“white box”)• Risks areas mapped during MMF architecture review• Team exposes API for the early NFT and integration automation• Integration testing done by the teams in integration environment• E2E testing (“black box”)• No new java code- all reused from components acceptance tests• New BDD (feature files ) are written describing the flow(s) based onexisting BDDs 33
  34. 34. All Rights Reserved - AgileSparksMain Agile Implementationsteps• Working with AgileSparks from day1• 2 days Management Workshop• Agile principles (e.g. Kanban+Scrum, Done is Done, Zerodefects)• Backlog preparation• Story Mapping to create first MVP• Tool decision (Jira – already exist)• 1 day Agile Training to all teams (Agile thinking &Scrum)• On-the-job coaching34