Recommended
Recommended
More Related Content
What's hot
Similar to Java Zone 2017 - Build the right system
Similar to Java Zone 2017 - Build the right system (20)
Recently uploaded
Recently uploaded (20)
Java Zone 2017 - Build the right system
- 1. JavaZone 2017 @chaugstvedt Cecilie Haugstvedt, Test Lead Build the right system - It's not enough to build the system right
- 2. @chaugstvedt Who am I? @chaugstvedt, photo by iaffs.no
- 3. 3 Wife, mother and tech enthusiast working as a test lead. Me, according to my Twitter bio
- 4. 4 Resistance is futile - start writing accessible websites now! Vegard Haugstvedt
- 6. 6
- 7. Testing 7
- 9. Build the right system - It's not enough to build the system right 9
- 10. Building the System Right
- 11. Building the Right System
- 12. Building the System Right TDD Unit tests Language Frameworks Libraries
- 13. Building the System Right Building the Right System Shift-left Personas BDD Mob programming Exploratory testing TDD Unit tests Language Frameworks Libraries
- 14. 14 How bad can it get?
- 15. 15 What you built What the customer needed
- 16. 16 # of users you gave a discount # of users the customer intended to give a discount
- 18. Shift Left 18
- 19. Traditional shift-left Requirements Design Development Testing 19 «Building the System Right»
- 20. Agile Shift Left 20 Requirements Design Development Testing Requirements Design Development Testing Requirements Design Development Testing
- 21. Ask Questions! 21 • What are the different pricing categories? Preliminary • Are these ALL the categories? • Do these rules apply EVERY time? Probing • Do you need any more categories? Possibilities
- 22. 22 Never ASSUME, because when you ASSUME, you make an ASS of U and ME.
- 24. Personas 24
- 25. 25
- 26. 26 The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use. Usability according to ISO
- 27. 27 Allan the Attendee Front-End Developer, fresh out of college. Conference Goal: Learn! Allan is at JavaZone for the first time and doesn’t know which sessions to attend. After the conference, he wants to watch sessions he missed online. Most important features: Program, videos
- 28. 28 Cecilie the Conference Speaker Test Lead and Speaker Conference Goal: Make connections! Cecilie is at the conference to present and network. Most important feature: Presentation page
- 29. 29
- 30. Using Personas to Improve Accessibility Characterstics • Watch TV-shows with subtitles • Surfs the web on public transport and in glaring sunlight Implications • Text all video • Make sure the buttons and the color contrast are large enough 30
- 32. BDD – Behaviour Driven Development 32 TDD ATDD DDD BDD Specification first
- 33. 33
- 34. 34
- 35. BDD = Shared Understanding by Discussing Examples 35 Developer Tester Business Representative What if…? What I want is… Is that the same as…? Domain Expert Have you thought about...?
- 36. BDD Process 36 Scenario fails Reach common understanding in workshop Elaborate into automated scenario Implement story using TDD Scenario passes Business needs Feature complete with documentation and regression test
- 37. BDD Tooling 37
- 38. Executable Specification 38 Withdrawal with sufficient funds Given I have 100$ in my Account When I request 20$ Then 20$ should be dispensed And I should have 80$ in my Account Given When Then
- 39. Executable Specification 39 Withdrawal with sufficient funds Given I have 100$ in my Account When I insert card AND enter pin AND press «withdraw cash» AND enter 20$ AND press OK Then 20$ should be dispensed And I should have 80$ in my Account Given When Then
- 40. 40 Good Bad
- 41. 41
- 43. Given – When – Then 43 Feature: Calculating Income for Parental Leave Given I have an income consisting of 10$ in Fixed salary And 10$ in Holiday pay And 10$ in Hourly pay And 10$ in Bonus And 10$ in Tax-free labor income, children under 13 years + 50 OTHERS When I filter out income relevant for Parental Leave Then I should have 10$ in Fixed salary And 10$ in Hourly pay + 20 OTHERS
- 44. 44 Parental Leave March Type Amount Fixed salary 10 Hourly pay 10
- 45. 45 Parental Leave March Type Amount Fixed salary 10 Bonus 10 Tax-free labor income, children under 13 years 10 Hourly pay 10 2 extra lines, 1 missing line
- 48. 48 All the brilliant minds working on the same thing… at the same time…. in the same space… and on the same computer... -Woody Zuill
- 49. How does it look? 49 Navigators Driver
- 50. But what about productivity? 50
- 51. 51 <
- 52. • Communication Problems • Decision-Making Trouble • Knowledge Transfer • Quitting Team Members 52
- 55. Scripted Testing 1. Visit stand A 2. Visit stand B 3. Visit stand C Exploratory Testing Go explore area 1! 55
- 57. Charter Template Explore <what> (With <resources>) To discover <your mission> 57
- 58. Charter Template Explore the JavaZone stands in section 1 To discover the best snacks 58
- 59. Charter Example Explore the submission form With keyboard only To discover potential accessibility issues 59
Editor's Notes
- Hi. My name is Cecilie Haugstvedt and I’m here to talk about how you can build systems of value.
- So, who am I? This is a picture of me and my son.
- Wife, mother and tech enthusiast working as a test lead. That’s me according to my Twitter bio
- And since I mentioned my husband: you might have seen him walking around the conference together with our son Allan. He had a presentation yesterday: Resistance is futile - start writing accessible websites now! If you didn’t have a chance to see him I would recommend looking up the video afterwards.
- Another way to sum up who I am is to cover topics I’m passionate about. First off: Accessibility.
- This staircase is tough to get up with a stroller but impossible with a wheelchair. Similarily, for me web sites with poor color contrast is hard to use in bright sun light. For others, they are impossible to use. I prefer to use the keyboard to navigate forms and get irritated when it’s not possible, others cannot use a mouse and get stuck in the same situations.
- Testing. This is a no-brainer. I work as a test lead. If I didn’t like testing I would have changed my job.
- Last: Methodology. Agile, DevOps, Continuous Improvements. I spend 8 hours a day at work and I don’t won’t to work in a suboptimal way.
- Back to the title of my presentation. Build the right system - It's not enough to build the system right. What does this mean?
- Building the System Right is about using the proper tools and methods to build a solid system instead of a shack
- Building the Right System is about not building a cabin when your customer wants an urban apartment
- Let’s first look at «Building the system right». This is where us technical people often like to start. We can use test-driven development, write plenty of unit tests, switch to a better programming language or framework, find a new library. All these things help us build a better system and are good given that we’re building the right system.
- If we’re building the wrong thing, all the items on the left are just a waste of time. It doesn’t matter how good your barn is if the customer doesn’t want a barn. The items on the right helps us build the right system. I will cover each item in more detail later but to sum up we have: Shift-left, Personas, Behaviour Driven Development, Mob programming and Exploratory testing
- Before we move on to the actual techniques I’d just like to look at how bad it can get?
- In the most extreme cases, you might be building the wrong application. If you build a fancy mobile app for college applications and the users need a web application where they can enter lenghty text and upload all the documentation, there’s a mismatch .
- In another example, you may have grouped together customer groups that should have been treated differently. Mistakes like this can be costly.
- So moving on to techniques. First out is shift-left
- Shift left is an approach to development in which testing is performed earlier in the lifecycle.
- Traditional shift left testing belongs in the category of «building the system right». Instead of testing after development we focus more on unit and integration testing during development. This is good, but not enough.
- In agile shift left we move the testing activities earlier both by working in iterations and by focusing on testing earlier in each iteration.
- You are not getting the full advantage of shifting left if you do not ask questions. There are different types of questions to ask. Preliminary questions such as «What are the different pricing categories?» are a good starting point. Follow up with probing questions. There are two words that are good to use in probing questions. ALL and EVERY. Are these ALL the categories? Do these rules apply EVERY time? Often you will find that this is not the case. Possibilities are meant to get people thinking of alternatives. Don’t ask about this if there’s not any room for doing it.
- Remember the golden rule of questioning: Never ASSUME, because when you ASSUME, you make an ASS of U and ME. Ask questions instead!
- So moving on to techniques. First out is shift-left
- The next method we’re going to look at is personas. Personas are fictitious users that represent a cluster of users with common characteristics. The hope is that by making a persona happy, you satisfy the whole group of users the persona represents.
- Why do we need personas? You are not your user. Neither is your project owner. Asking a number of random users what they want is most likely going to get you a list of different and sometimes conflicting desires.
- To design a usable solution, you need to design a solution for specified users, with specified goals in a specified context of use
- How does a persona look? Here’s one for JavaZone. Allan the Attendee is a frontend developer, fresh out of college. His conference goal is to learn! Allan is at JavaZone for the first time and doesn’t know which sessions to attend. After the conference, he wants to watch sessions he missed online. For Allan, the most important features is the program and videos. He wants an easy way to see whats coming up next when he looks for a session at 4 o’clock Thursday.
- Here’s a different persona. Cecilie the Conference Speaker is a test lead and speaker. Her conference goal is to make connections. She comes to Java Zone to present and network. For her, the most important feature is the presentation page. She promotes her presentation on Twitter and LinkedIn beforehand and want to link directly to a page with time, room and a short presentation of her talk.
- So why do we use personas? It’s easier to argue that Cecilie would like to have her twitter handle on the presentation page than to come up with all kinds of features that might satisfy the needs of a generic conference goer. Instead of designing for a generic group you can think of Allan and develop features specifically for the first-timers. And so on.
- Given that you already use personas, you can hit two birds with one stone and add in some accessibility features. Maybe Cecilie watches all TV-shows with subtitles. Well, video texting would be a good idea. It would also make the videos accessible to peeple with hearing impairments. Maybe Cecilie surfs the web on public transport and in glaring sunlight. Better make sure the buttons and the color contrast are large enough to enable her to set up the program on the bus.
- So moving on to techniques. First out is shift-left
- Behaviour Driven Development is a synthesis of testdriven development and acceptance test driven development combined with ideas from domain-driven design.
- So what is BDD? In short: BDD is using examples at multiple levels to create a shared understanding and surface uncertainty to deliver software that matters.
- There are two parts to this: using examples to create a shared understanding
- How do we do this? One way is to start off with a specification workshop. A business representative starts off with what he or she wants and developers and testers contribute by asking questions and coming up with examples.
- The BDD process starts with business needs. We reach a common understanding by discussing examples in the specification workshop. The examples are transformed into a working scenario which at first will fail. We implement the story using TDD and the scenario passes. At this point we should have a complete feature with documentation and regression test. And we move on to the next business need.
- There are a number of tools that support BDD: Cucumber, JBehave, Specflow and FitNesse is just a few. A little bit of a warning here: just using the tools does not mean that you’re doing BDD. Used properly, these tools support BDD but you can easily use them as just another test automation tool without getting any of the benefits of BDD.
- Common for most of the tools on the previous slide is that they require an executable specification in the Given – When – Then format: Lets look at withdrawal with sufficient funds. Given I have 100$ in my Account When I request 20$ Then 20$ should be dispensed And I should have 80$ in my Account
- There are a number of pitfall you can get into when doing BDD. Number one is putting technical details and GUI information into the scenarios. The scenarios are for business logic only.
- Pitfall number two is skipping the collaboration and using the BDD tool as a test automation tool. It’s OK to agree on the scenario and letting someone enter them into the tool sitting alone, but when the collaboration is missing all together you’re not doing BDD.
- Pitfall number three is thinking that Given – When –Then scenarios are the only way to do BDD.
- This is a screenshot of a page in the paper version of the Norwegian a-melding – a report with information about salary and employment that all employers in Norway have to deliver each month. I’ve been working with the income calculations in NAV where they take this information and calculate your monthly income for a number of benefits.
- This is how a scenario in the given – when –then format would look at this project. The + 50 others represents different types of income that would have to be in each scenario to cover the business rules for calculating income. We are not talking implementation details that can be abstracted away from the business users, we’re talking crucial business rules determined by Norwegian law. Obviously the scenario would become illegible in the given - when – then format.
- Instead of scrapping the idea of BDD we used a different tool: FitNesse. In FitNesse, tests are expressed as tables of input data and expected output data. The tables we set up was a lot bigger than this, but you get the point. This is an example of a test before we run it. We expect all the other information than fixed salary and hourly pay to be filtered out.
- And this is an example after we run it. Both missing and extra lines are marked, making it easy to spot income that should have been filtered out but wasn’t and income that should have been included but was filtered out.
- So moving on to techniques. First out is shift-left
- Next out is mob programming. Mob programming is pair programming taken to the extreme.
- One way to define mob programming is this: Mob programming is all the brilliant minds working on the same thing… at the same time…. in the same space… and on the same computer...
- So how does it look? You have one driver who’s at the keyboard handling input. The remaining team members take the role of navigators, providing direction for the driver. If you sit as the driver and have a new idea for how this should be done you hand the keyboard over to someone else and explain the idea. Every five or ten or fifteen minutes you change the driver..
- But what about productivity? How can it be productive to have the whole team working in the same room?
- Four programmers working separately will hopefully accomplish more than one programmer working alone. How can four people working on one computer compare to this?
- The idea behind mob programming is that when you have all the team members in one room, you get rid of a lot of the most common productivity killers. You have the customer and business experts in the room so there’s no need to make assumptions or put things on hold waiting for someone else to make a decision. There’s not a problem where the only one who knows how to do deployments quits because you all know how to do deployments. You don’t take
- So moving on to techniques. First out is shift-left
- The last example I’ll cover today is exploratory testing.
- The best way to describe exploratory testing is to compare it to scripted testing. Lets say our goal is to test the Java Zone stands. In scripted testing, we would make a list of the stands to visit and what we should check at each stand. In exloratory testing we would have a charter such as «explore area 1». If the goal is to check that stands fulfill certain criteria, scripted testing is the way to go. Exploratory testing helps us find the surprises that’s not on the list such as noise levels or best gadgets.
- As you probably can imagine just saying to a bunch of people that they should all go and explore the stands will not result in much useful information. First off, everyone needs a charter, a specific area to focus on. This way, we avoid that everyone is testing the ice cream stand and no one visits the rest. Second, we need to timebox the testing. We want people to have time for the other activities, such as going to the presentations. And last, but not least, we need that everyone takes some sort of notes so that they can share their findings. Mindmaps and sketches are OK.
- So how does a charter look? This is one example of a charter template. Explore <what>(With <resources>)To discover <your mission>
- Back to our JavaZone example. A mission for JavaZone could be Explore the JavaZone stands in section 1 to discover the best snacks
- A more software related example would be Explore the submission form With keyboard only To discover potential accessibility issues
- So these are the methods I’ve covered: Shift-left, Personas, Behaviour Driven Development, Mob programming and Exploratory testing Are there any questions?