Comprehensive Software Testing Techniques and Agile Methodologies

This content covers unit test development examples, test cases for different types of triangles, JSON specifications, and the transition from traditional software practices to Extreme Programming (XP) that paved the way for Agile methodologies. It highlights the importance of software testing and the evolution of development practices.

• Software Testing
• Agile Methodologies
• Extreme Programming
• Unit Tests
• Development Practices

luid367 Follow

Uploaded on Sep 15, 2024 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

1. Agile and Scrum Kevin Scannell, David Ferry CSCI 5030 Principles of Software Development Saint Louis University St. Louis, MO 63103 1

2. Homework: Unit Test Development Example self-test from Myers classic book (The Art of Software Testing, 1979). A program that takes three integers as input (supposed to represent side lengths of a triangle) and outputs scalene , isosceles , equilateral , or error (not a triangle or some other problem). For definiteness and modernity, imagine that this is implemented as a REST API and that the input comes in as bytes in JSON format, e.g. this is a valid input: { "a" : 3, "b" : 4, "c" : 5 } Exercise: Write out a comprehensive set of unit tests. CSCI 5030 Principles of Software Development 2

3. Homework: Unit Test Development Do you have a test case or test cases that: is a valid scalene triangle? is a valid equilateral triangle? is a valid isosceles triangle? is a non-triangle? e.g. (1,2,5) (use triangle inequality) has one side = 0? has one side negative? is (0,0,0)? contains all three permutations of an isosceles triangle? e.g. (2,3,3), (3,2,3), (3,3,2) is a degenerate triangle (sum of two equals the third)? contains all three permutations of the longest side in a degenerate triangle? e.g. (2,3,5),(5,2,3),(2,5,3) contains floats and not ints? contains less than 3 numbers? Did you specify what the answers should be next to each test case? Average among professional programmers: 7.8/14. CSCI 5030 Principles of Software Development 3

4. Homework: Unit Test Development Some more, given the JSON specification: that contains non-UTF-8 encoded text? that contains malformed JSON? that is well-formed but isn t a hash? that represents values of a,b,c as strings not numbers (OK?) Notes: Software testing is a skill every bit as much as programming is. Ask any experienced QA person. Programmers can easily think of positive tests (direct tests of functionality). Negative test cases (all possible errors) are harder. Testing can only ever show the presence of errors, it can never show your program is error-free. CSCI 5030 Principles of Software Development 4

5. Before Agile there was Extreme Programming Vanderburg does a good job of early history Early software practices (i.e. ad-hoc or waterfall) often didn't work, and could fail entirely (Still happens today- see Obama s Healthcare Marketplace rollout) Waterfall problems: Heavyweight, rigid processes Long feedback loops Excessive documentation Problems after delivery or change in requirements implies 100% cost overruns and months of extra time Extreme Programming (XP) takes all of the lessons learned (as of about 1996-1999), identifies good qualities in programming practice, and takes those practices to the extreme. CSCI 5030 Principles of Software Development 5

6. Extreme Programming Four main practices: Coding - code is the unit of contribution (not documentation) Testing - all code needs tests before it is written and must pass before being integrated Listening - programmers must listen to customer's needs and business logic Designing - system design should be as simple as possible and ongoing Taken to the extreme: Code reviews are good, so we should use pair-programming to code review constantly Testing is good, so the programmer should have unit tests for every feature and every change, and the customer should have their own acceptance tests. All tests would be run at the end of every day. (What if a feature takes more than a day to develop?) Frequent communication with the customer is important, so the customer should send a representative that is always on site and able to provide instant feedback. Design is good, so rather than making one design document to start and then implementing that, we should always be designing incrementally as we code, test, and communicate. Build the simplest possible system and only add complexity when the current feature needs it. CSCI 5030 Principles of Software Development 6

7. Example XP Practices Many individual XP practices Have a simple shared metaphor about how the system works. Shared between developers and customer, so no technical language, but use stories and names instead. Facilitates both developer and customer understanding of what is supposed to happen. E.g. Assembly Line program: a data item enters the factory and is put on a conveyor belt, and as it goes along the conveyor a worker at each station has their own story about what happens, etc. Unit test and integration test daily Get a simple system running quickly, and then everything else is a release on a short cycle Keep things as simple as possible, and remove complexity wherever possible Collective ownership- anybody can change/fix anything Sustainable pace- measure your "project velocity" and understand what that means, 40 hour work weeks max, adding new bodies to a project slows it down, not speeds it up Customer must be always available- have a customer's expert on hand to provide feedback and set priorities during planning CSCI 5030 Principles of Software Development 7

8. XP in a Nutshell Underlying principle: Short iterations are good, so make feedback loops as tight as possible. Pair programming gets feedback down to seconds/minutes. Unit testing and daily testing gets feedback down to hours and a day. Nothing goes unquestioned for weeks or months. Feedback is constant. (Contrast this to waterfall.) CSCI 5030 Principles of Software Development 8

9. Agile Agile Alliance Agile 101 Introduction "Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment. That's an odd way to talk about building software, isn't it? Yes and no... Agile is a philosophy Scrum and XP (and other) are frameworks that implement that philosophy It's a set of values and principles It's not a set of practices and rituals CSCI 5030 Principles of Software Development 9

10. The Agile Manifesto (2001) We value Individuals and interactions over processes and tools Completed functionality over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, the items on the left matter more. First meeting of agile founders was able to agree that this was the way forward over existing development techniques. CSCI 5030 Principles of Software Development 10

11. What does that sound like? The four values: Individuals, Completion, Customer Collaboration, and Responding to Change The four anti-values: Processes, Comprehensive Documentation, Contract Negotiation, Following the Plan Small Group Discussion: Juxtapose those sets of words, what are your reactions? CSCI 5030 Principles of Software Development 11

12. The Agile Principles 1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 7 Working software is the primary measure of progress. 8 Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 2 Welcome changing requirements, even late in development. Agile processes harness change for the customer s competitive advantage. 3 Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 9 Continuous attention to technical excellence and good design enhances agility. 10 Simplicity the art of maximizing the amount of work not done is essential. 4 Business people and developers must work together daily throughout the project. 11 The best architectures, requirements, and designs emerge from self-organizing teams. 5 Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 6 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. CSCI 5030 Principles of Software Development 12

13. Notes on the Principles No details about the process/methodology here! Principles that should underlie any good process. Human aspects here (#4, #5, #6, #8, #11, #12)! Especially 5 and 8: Happy developers produce good code. Customer aspects here (#1, #2, #4, #8)- Happy customers come back. Bald assertions mostly! Remember to read everything critically. Small Group Discussion: Compare with your experience as a developer. Are there contexts where you d disagree with any of these principles? CSCI 5030 Principles of Software Development 13

14. Scrum in 30 Seconds A product owner creates a prioritized wish list called a product backlog . Final arbiter of requirements. Team members can add things too. Backlog items are customer-centric features. The form of backlog items is up to you; user stories, or whatever. During sprint planning, the team pulls a small chunk from the top of product backlog to create a sprint backlog, and transforms those into a set of specific tasks that need to be completed. The team has a certain amount of time, a sprint, to complete its work - usually two to four weeks - but meets each day (15 minute standup) to assess its progress (daily scrum). Along the way, the Scrum Master keeps the team focused on its goal. No management authority. At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder. Sprint review shows the product owner (and potentially other stakeholders) a working demo, those stakeholders provide feedback. Sprint retrospective is for team to self-assess their performance. What went well, what could be improved? As the next sprint begins, the team chooses another chunk of the product backlog and begins working again. CSCI 5030 Principles of Software Development 14

15. Scrum Attributes Scrum is hard- scrum will initially show you more about your organization than it will show you about software development. There is no Product Manager!!! That role is split between the product owner and the team itself. Team is self-organizing. Scrum is forward-focused: What did I do yesterday, what do I need to do next, and what is blocking or preventing me from doing that? It is a report to teammates, not to product owner. Scrum develops a learning team, a team that reflectively optimizes itself. CSCI 5030 Principles of Software Development 15

16. Scrum Discussion Small Group Discussion: What is "potentially shippable" mean to you? Small Group Discussion: What does "done" mean to you? Small Group Discussion: What happens if you're near the end of a sprint and you're not going to get all of your backlog items done? CSCI 5030 Principles of Software Development 16