Tiina Kiuru Reaktor Innovations

Transcription

1 Agile Testing Tiina Kiuru Reaktor Innovations

2 Agenda What is agile? Agile values, principles and practices How to organize testing? How to implement testing?

3 What is agile?

4 Top 5 reasons: Why Agile? Software based on real and most valuable requirements - business needs and value drive development Shorter time to market You always know where your projects are - more transparency and controllability Focus on quality Lower project risk Better return on investment

5 Agile Values Agile Manifesto Agile Principl es

6 Agile Values Agile Manifesto Agile Principle s Agile Values These are important Processes and tools Comprehensive documentation Contract negotiation Following a plan These are even more important Individuals and interactions Working software Customer collaboration Responding to change Copyright Reaktor Innovations

7 Agile Values Agile Manifesto Agile Principle s Agile Principles Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

8 Agile Values Agile Manifesto Agile Principle s Agile Principles Working software is the primary measure of progress. Agile processes promote sustainable development.the sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from selforganizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

9 Values Defines the set of most important Values of what is truly important Principles Defines a set of ways to meet the values Practices Defines in detail how this is implemented in practice

10 Scrum Daily Scrum meeting 24 hours Product Backlog Sprint Backlog Sprint 1-4 weeks Potentially shippable product increment S print P la nning M eeting D em o, S print R eview & R etros pec tive M eeting Copyright Reaktor Innovations

11 Scrum in 5 Bullets Iterative, incremental, cyclic process Time-boxed development Evidence-based planning Inspect and adapt - feedback loops Cross-functional, self-managing teams

12 How to Organize Testing?

13 Basics of Agile Testing Individuals and interactions over processes and tools Tester integrated part of the team Working software over comprehensive documentation Testing right after feature has been implemented Customer collaboration over contract negotiation Customer participates in testing, continuous feedback Responding to change over following a plan Exploratory testing and test automation

14 Principles: Test Process Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale Purpose is to help in building quality into system No separate testing phase, continuous testing Test early and often: when a feature is implemented, it is tested

15 Test Process Principles: Working software is the primary measure of progress. Business people and developers must work together daily throughout the project Feature is not ready before it has been tested Direct feedback as soon as possible Bugs are fixed as they are found If you don t have meaningful feedback then you re not agile. You re just in a new form of chaos. -Brian Marick

16 Between Agile and Iterative Agile transformation is demanding currently testing is often something between iterative and agile, eg: Testing done in the end of sprint or after it This is not agile! Customer most probably does not get working software Bugs remain tasks are not actually finished by the end of sprint Creates endless quality debt stabilization sprints

17 Between Agile and Iterative Few test releases in each sprint A lot better than testing in the end of sprint Slow feedback loop tasks get ready late, pressure at the end of sprint Creates quality debt, if not enough time to fix bugs

18 The Role of Tester Principles: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Tester is like any other team member Quality belongs to everyone, tester is just a facilitator Quality contributor instead of gate keeper Testaajien yleisin virhe on kaapata laatukeskustelu kokonaan itselleen -Erkki Pöyhönen

19 The Role of Tester Principles: Business people and developers must work together daily throughout the project. Testers work with business representatives to understand their needs Testers work with developers to understand the system and to provide feedback All essential stakeholders contribute to testing

20 No Do You Need Specialized Testers? Yes In a crossfunctional team everyone does everything and the responsibility is shared, tester is just another team member Developers have the technical knowledge and customer has domain knowledge they can do testing Testing of complex systems is demanding and requires testing expertise Testers need a different mindset it is hard to switch between development and testing Responsibility and knowledge is shared, but also specialized experts are needed

21 Test Reporting and Documentation Principles: The most efficient and effective method of conveying information to and within a development team is faceto-face conversation Direct ongoing feedback to developers Communication with business representatives in order to understand their needs

22 Test Reporting and Documentation Principles: Simplicity--the art of maximizing the amount of work not done--is essential. Forget the test documentation templates and IEEE 829! Automate reporting as much as possible Diaries, tables, mind maps instead of word documents

23 No Do You Need a Bug Management Tool? Feedback is given directly A failing automated test is a bug report Bugs are fixed as they are found no need to manage their state An unmanageable amount of bugs is just an indication of bad practices Yes All bugs are not found only with automated tests Often testing starts too late lots of bugs found in one sprint All bugs are not fixed they have to be controlled in some way In an ideal agile project bug management tool is not needed, but in reality it often has to be taken into use

24 Challenges and Common Mistakes Tasks marked as done before testing is completed (Definition of Done) Testing is not done from the beginning of the project Only features are tested, not the system as a whole Regression testing is neglected Testers are not part of the team

25 Test Process and Scrum Testing activities defined in backlogs Daily Scrum meeting 24 hours Testing tasks distributed among team members, not only to tester Product Backlog Sprint Backlog Sprint 1-4 weeks Potentially shippable product increment S print P la nning M eeting Tester participates and contributes as a team members D em o, S print R eview & R etros pec tive M eeting Only tested features in demo

26 Scrum and Testing in 5 Bullets Iterative, incremental, cyclic process Testing in the same pace with development Time-boxed development Time-box includes QA, QA included in the Definition of Done

27 Scrum and Testing in 5 Bullets Evidence-based planning Concerns testing as well; tools and practices are evaluated by the team Inspect and adapt - feedback loops Testing practices changed as needed Cross-functional, self-managing teams Testers are team members, quality belongs to everyone

28 How to do it in Practice?

29 Agile Testing Areas By Brian Marick

30 Unit Testing Cheapest way to build quality Done by developers Continuous integration Unit tests ignore user's point of view unit tests do not substitute system level tests! Frameworks: JUnit, TestNG, RSpec, JDave

31 Test Driven Development Tests written first Tests serve as documentation Behavior Driven Development Red-Green-Refactor Red: Failing test Green: Write code so that test passes Refactor: Code with better quality

32 Acceptance Testing Should be automated and run frequently Every team member should have access to test automation tools and scripts Automated regression tests Traditional test automation tools don t work for an Agile context because they solve traditional problems, and those are different from the challenges facing Agile teams.. - Elisabeth Hendrickson

33 Acceptance Test Driven Development (ATDD) Tests for a feature are defined before development starts Tests are specifications or examples of the feature Feature can be verified right after it has been implemented Usually keyword driven

34 Keyword Driven Automation Tests defined in natural language, eg. in html tables Customers and business people can specify tests Testers or developers take care of the implementation Frameworks: Fit, Robot, Concordion

35 Example: Keyword Driven Test case: Automation Test implementation:

36 Acceptance Testing - Challenges Maintenance costs of automation Automated system tests are slow It's not possible to automate everything cost-efficiently Unit tests and acceptance tests support each other Continuous running

37 Usability and Exploratory Testing Tests that cannot be automated Question acceptance tests Are acceptance tests valid? Finding new essential features

38 Exploratory Testing Exploratory software testing is a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the value of her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project

39 Exploratory Testing Purpose to find bugs, new features and to learn No detailed predefined tests Based on testers' expertise Can be done in pairs with customer, developers, users etc. Not equal to ad hoc!

40 Example: Exploratory Testing OK Wrong password Credentials Wrong user name Session handling & authentication Expiration Account locking Configuration Re-opening Configuration Basic case

41 Usability and Exploratory Testing - Challenges Keeping testing exploratory, not ad hoc Finding appropriate level of documentation Getting usability feedback as early as possible protos, simulations, early usability tests

42 Property Testing ~ Non-functional testing, excluding usability Reliability, Portability, Supportability, Security Early testing and feedback These issues have to be considered during development

43 Property Testing - Challenges Usually requires very specialized knowledge Has to be done also on complete system Specialized tools, that are not available for all team members Open source tools Early profiling Awareness

44 Summary Collaborate Adapt Explore Automate