1 00:00:06,859 --> 00:00:10,640 - Janet just explained some key success factors 2 00:00:10,640 --> 00:00:13,960 to succeed with testing in Agile projects, 3 00:00:13,960 --> 00:00:17,171 but there's even more we can do to build confidence 4 00:00:17,171 --> 00:00:20,069 in the features that we release. 5 00:00:20,069 --> 00:00:23,349 Let's talk about some core testing practices 6 00:00:23,349 --> 00:00:26,839 that let us deploy frequently without worrying. 7 00:00:26,839 --> 00:00:30,050 We wrapped up our second book More Agile Testing 8 00:00:30,050 --> 00:00:33,148 with a list of confidence-building practices. 9 00:00:33,148 --> 00:00:36,091 These practices support the key success factors 10 00:00:36,091 --> 00:00:37,789 that you just learned about. 11 00:00:37,789 --> 00:00:39,920 Again, these aren't best practices 12 00:00:39,920 --> 00:00:42,499 because they don't all apply to everybody, 13 00:00:42,499 --> 00:00:44,859 but we do feel they're leading practices. 14 00:00:44,859 --> 00:00:47,610 It always depends on your situation. 15 00:00:47,610 --> 00:00:50,600 Confidence builds our courage to innovate, 16 00:00:50,600 --> 00:00:53,291 to experiment, to improve. 17 00:00:53,291 --> 00:00:55,061 Let's look at each one of these practices 18 00:00:55,061 --> 00:00:56,569 that can help us do that. 19 00:00:56,569 --> 00:00:59,560 Have you ever been in one of those endless meetings 20 00:00:59,560 --> 00:01:02,061 where a discussion seem to just go around and around 21 00:01:02,061 --> 00:01:04,978 in a circle but achieve no clarity? 22 00:01:05,829 --> 00:01:07,501 If that ever happens to you, 23 00:01:07,501 --> 00:01:09,421 our advice is to grab a marker 24 00:01:09,421 --> 00:01:12,181 and start drawing examples on a whiteboard 25 00:01:12,181 --> 00:01:14,571 to get the conversation back on track. 26 00:01:14,571 --> 00:01:17,500 It's the best way to illustrate business rules. 27 00:01:17,500 --> 00:01:19,379 Examples take many forms. 28 00:01:19,379 --> 00:01:21,261 We've talked about some of these, 29 00:01:21,261 --> 00:01:24,400 things like mockups, spreadsheets. 30 00:01:24,400 --> 00:01:27,749 Talk through them with your business stakeholders, 31 00:01:27,749 --> 00:01:30,469 with your delivery team. 32 00:01:30,469 --> 00:01:32,851 Use those acceptance test-driven, 33 00:01:32,851 --> 00:01:36,571 behavior-driven specification by example tests 34 00:01:36,571 --> 00:01:39,400 to guide development with examples. 35 00:01:39,400 --> 00:01:42,581 They may be executable automated tests or not. 36 00:01:42,581 --> 00:01:45,198 We've talked a lot about exploratory testing 37 00:01:45,198 --> 00:01:48,611 because we think it's so key to building confidence 38 00:01:48,611 --> 00:01:50,229 in our software product. 39 00:01:50,229 --> 00:01:52,221 Testers can help other team members 40 00:01:52,221 --> 00:01:54,861 learn exploratory testing skills. 41 00:01:54,861 --> 00:01:56,920 This is something that my team has been doing 42 00:01:56,920 --> 00:02:01,087 quite successfully, having developers pair with a tester 43 00:02:02,878 --> 00:02:05,861 to do exploratory testing before finishing a story, 44 00:02:05,861 --> 00:02:08,669 or as they gain their exploratory testing skills, 45 00:02:08,669 --> 00:02:11,640 developers can pair with each other to do this. 46 00:02:11,640 --> 00:02:14,011 That lets us catch problems sooner 47 00:02:14,011 --> 00:02:16,149 and they record what they learned 48 00:02:16,149 --> 00:02:18,149 about that particularly story 49 00:02:18,149 --> 00:02:20,280 so that anyone doing additional testing 50 00:02:20,280 --> 00:02:23,040 such as a product owner doing acceptance testing 51 00:02:23,040 --> 00:02:25,621 knows what's already been tested in that story. 52 00:02:25,621 --> 00:02:27,400 It can save some time. 53 00:02:27,400 --> 00:02:31,109 And it also allows programmers and product owners 54 00:02:31,109 --> 00:02:35,061 to know to go beyond the happy path of the story level, 55 00:02:35,061 --> 00:02:37,549 to try some misbehaviors, 56 00:02:37,549 --> 00:02:39,627 to maybe even channel some personas 57 00:02:39,627 --> 00:02:43,069 and see how different users would use the system. 58 00:02:43,069 --> 00:02:46,109 This all allows testers to have more time 59 00:02:46,109 --> 00:02:48,821 for exploratory testing at a feature level, 60 00:02:48,821 --> 00:02:50,531 thinking about that big picture, 61 00:02:50,531 --> 00:02:53,600 thinking about impacts on other parts of the system. 62 00:02:53,600 --> 00:02:56,278 So, pairing with other team members 63 00:02:56,278 --> 00:02:57,541 do things that might be missed 64 00:02:57,541 --> 00:02:59,499 like checking for backwards compatibility 65 00:02:59,499 --> 00:03:02,482 when you build new features or change old features. 66 00:03:02,482 --> 00:03:05,052 Transferring these professional testing skills 67 00:03:05,052 --> 00:03:07,823 benefits everyone in building confidence. 68 00:03:07,823 --> 00:03:11,272 When we talked about the big picture, as Janet mentioned, 69 00:03:11,272 --> 00:03:13,464 we are always working in these small chunks 70 00:03:13,464 --> 00:03:15,202 and small increments and that's good. 71 00:03:15,202 --> 00:03:18,384 It helps us finish things as we go. 72 00:03:18,384 --> 00:03:19,922 It helps us focus. 73 00:03:19,922 --> 00:03:23,184 But, we don't wanna forget impacts on other areas. 74 00:03:23,184 --> 00:03:25,064 We don't wanna forget about the value 75 00:03:25,064 --> 00:03:26,813 that we're trying to deliver. 76 00:03:26,813 --> 00:03:30,413 And Janet compares this to putting together a jigsaw puzzle. 77 00:03:30,413 --> 00:03:32,962 You don't necessarily have to complete the entire puzzle 78 00:03:32,962 --> 00:03:34,512 to get value out of it. 79 00:03:34,512 --> 00:03:36,664 Maybe you're most interested in seeing 80 00:03:36,664 --> 00:03:38,562 the faces of the people in the puzzle 81 00:03:38,562 --> 00:03:40,373 or maybe there are some nice flowers 82 00:03:40,373 --> 00:03:42,792 and you just wanna do that part of the puzzle. 83 00:03:42,792 --> 00:03:44,544 What's the most value to you? 84 00:03:44,544 --> 00:03:46,802 We can do that with our software as well. 85 00:03:46,802 --> 00:03:48,853 We can't necessarily test everything, 86 00:03:48,853 --> 00:03:51,382 but we can test the most important things 87 00:03:51,382 --> 00:03:54,642 and remembering those additional quality attributes 88 00:03:54,642 --> 00:03:57,792 like performance, usability, and security. 89 00:03:57,792 --> 00:04:01,464 Learning continually, we've talked a lot about learning. 90 00:04:01,464 --> 00:04:03,772 You can't fix every problem at once, 91 00:04:03,772 --> 00:04:05,892 so use your retrospectives. 92 00:04:05,892 --> 00:04:07,893 Identify what's holding you back, 93 00:04:07,893 --> 00:04:11,384 what's the one thing that you would like to get better at, 94 00:04:11,384 --> 00:04:14,373 what's the one goal that your team wants to achieve? 95 00:04:14,373 --> 00:04:16,584 And think of some small experiments 96 00:04:16,584 --> 00:04:20,173 to get closer to that goal or to solve that problem. 97 00:04:20,173 --> 00:04:22,544 When we have self-organizing teams 98 00:04:22,544 --> 00:04:24,602 that feel safe to experiment, 99 00:04:24,602 --> 00:04:26,412 that's when we get the innovation 100 00:04:26,412 --> 00:04:29,272 that gives our company the competitive advantage 101 00:04:29,272 --> 00:04:31,710 and makes us more successful. 102 00:04:31,710 --> 00:04:35,024 Cross-functional teams with diverse skillsets, 103 00:04:35,024 --> 00:04:36,392 remember those t-shaped skills 104 00:04:36,392 --> 00:04:38,464 and those square-shaped teams, 105 00:04:38,464 --> 00:04:40,771 help make sure all the testing gets done 106 00:04:40,771 --> 00:04:42,521 at the appropriate time. 107 00:04:42,521 --> 00:04:43,893 Remember your context. 108 00:04:43,893 --> 00:04:45,864 We talked a lot about that. 109 00:04:45,864 --> 00:04:49,064 Apply the Agile values, principles, and practices. 110 00:04:49,064 --> 00:04:50,510 That's what's important. 111 00:04:50,510 --> 00:04:54,081 Just learn those and apply them in your own context. 112 00:04:54,081 --> 00:04:57,704 We've talked about how your team might be subject to audits 113 00:04:57,704 --> 00:05:01,304 and regulatory agencies that perhaps have requirements 114 00:05:01,304 --> 00:05:04,842 for things that you don't have like extra documentation, 115 00:05:04,842 --> 00:05:09,009 so be sure to plan for discussing those things with auditors 116 00:05:11,263 --> 00:05:13,651 and discussing those things with your business 117 00:05:13,651 --> 00:05:15,944 to decide what can you do that works for you 118 00:05:15,944 --> 00:05:17,863 and meets these requirements. 119 00:05:17,863 --> 00:05:20,440 If you're working in a global enterprise company 120 00:05:20,440 --> 00:05:23,362 with distributed teams, maybe in different timezones, 121 00:05:23,362 --> 00:05:25,432 you have a lot of extra challenges 122 00:05:25,432 --> 00:05:29,144 to ensure good communication and to manage dependencies. 123 00:05:29,144 --> 00:05:32,942 If you're working on something like mobile application 124 00:05:32,942 --> 00:05:34,202 or embedded software, 125 00:05:34,202 --> 00:05:35,973 you have to be creative to find ways 126 00:05:35,973 --> 00:05:37,802 to test multiple devices, 127 00:05:37,802 --> 00:05:40,149 different operating system versions. 128 00:05:40,149 --> 00:05:43,013 You have a lot more complicated problems to solve 129 00:05:43,013 --> 00:05:46,333 than someone who's working on a web application 130 00:05:46,333 --> 00:05:49,262 that only needs to run on one browser. 131 00:05:49,262 --> 00:05:52,642 You may need to bring in people with specialized skillsets 132 00:05:52,642 --> 00:05:55,562 or you may need to devote time 133 00:05:55,562 --> 00:05:57,961 to learning those specialized skills. 134 00:05:57,961 --> 00:05:59,893 Be sure to plan for that. 135 00:05:59,893 --> 00:06:02,744 You may need to invest in new infrastructure, 136 00:06:02,744 --> 00:06:05,310 for example to make your continuous integration builds 137 00:06:05,310 --> 00:06:09,282 run faster and get that fast feedback that we need so badly. 138 00:06:09,282 --> 00:06:11,293 Whatever gets in the way of the quality 139 00:06:11,293 --> 00:06:13,282 that you want to give your customers, 140 00:06:13,282 --> 00:06:15,893 look for creative ways to solve the problem. 141 00:06:15,893 --> 00:06:18,561 Testers are good information providers 142 00:06:18,561 --> 00:06:22,864 and testing helps us inform the business about risks 143 00:06:22,864 --> 00:06:24,592 and we can also make suggestions 144 00:06:24,592 --> 00:06:26,522 about how to mitigate those risks 145 00:06:26,522 --> 00:06:28,802 with testing or other activities. 146 00:06:28,802 --> 00:06:31,352 If we can't get the necessary testing done 147 00:06:31,352 --> 00:06:33,992 before a particular business deadline, 148 00:06:33,992 --> 00:06:37,592 ask the business stakeholders whether scope can be reduced 149 00:06:37,592 --> 00:06:41,264 so that we can achieve the level of doneness that we want. 150 00:06:41,264 --> 00:06:43,162 We found that new Agile teams, 151 00:06:43,162 --> 00:06:45,093 because they're very eager to succeed, 152 00:06:45,093 --> 00:06:49,642 often take on too much work at once and they find that, 153 00:06:49,642 --> 00:06:52,453 "Oh, we don't have time to automate the test," or, 154 00:06:52,453 --> 00:06:54,112 "We don't have time for exploratory testing 155 00:06:54,112 --> 00:06:57,211 "because we have to deliver all of these stories." 156 00:06:57,211 --> 00:06:59,973 Manage your workload so that you build in time 157 00:06:59,973 --> 00:07:01,882 for all those necessary activities. 158 00:07:01,882 --> 00:07:04,482 And if they're new skills for you, 159 00:07:04,482 --> 00:07:06,222 build in time to learn them. 160 00:07:06,222 --> 00:07:08,813 You can limit your work in progress. 161 00:07:08,813 --> 00:07:12,472 For example, your teammate decide to only work at 162 00:07:12,472 --> 00:07:14,984 up to three stories at one time. 163 00:07:14,984 --> 00:07:17,812 If all the development activities are done for those stories 164 00:07:17,812 --> 00:07:21,979 then the whole team can help finish the testing activities. 165 00:07:23,064 --> 00:07:26,442 We're always faced with pressure from the business to say, 166 00:07:26,442 --> 00:07:28,202 "Can't you do a little more work? 167 00:07:28,202 --> 00:07:30,632 "Can't you get it done a little sooner? 168 00:07:30,632 --> 00:07:32,984 "Can't you meet this business deadline?" 169 00:07:32,984 --> 00:07:36,562 As Bob Martin points out in his book The Clean Coder, 170 00:07:36,562 --> 00:07:39,562 saying will try when we're asked to do something 171 00:07:39,562 --> 00:07:43,173 that we know is impossible doesn't help the company succeed, 172 00:07:43,173 --> 00:07:45,192 so it may be tempting to tell your manager, 173 00:07:45,192 --> 00:07:48,482 "Oh, yes you want that by next week? 174 00:07:48,482 --> 00:07:50,773 "We'll try," and you know good and well 175 00:07:50,773 --> 00:07:52,184 it's not gonna happen. 176 00:07:52,184 --> 00:07:54,864 You sometimes have to give a reality check and say, 177 00:07:54,864 --> 00:07:56,511 "We can't get that done, 178 00:07:56,511 --> 00:07:58,362 "but how about if we reduce the scope? 179 00:07:58,362 --> 00:08:01,040 "What do you really have to have by next week?" 180 00:08:01,040 --> 00:08:04,173 It's never fun to deliver any kind of bad news, 181 00:08:04,173 --> 00:08:07,552 but it's better than letting problems get out to production 182 00:08:07,552 --> 00:08:11,264 and affecting your customers in a negative way. 183 00:08:11,264 --> 00:08:13,362 When the whole team owns quality, 184 00:08:13,362 --> 00:08:16,813 look for ways to learn quickly about any issues 185 00:08:16,813 --> 00:08:20,543 with the new features that you want to deliver. 186 00:08:20,543 --> 00:08:25,082 And again, educate managers, others in the company, 187 00:08:25,082 --> 00:08:26,784 about the value of testing. 188 00:08:26,784 --> 00:08:29,972 Why does this investment and quality pay off? 189 00:08:29,972 --> 00:08:34,023 It forms a good basis so that we can deliver 190 00:08:34,023 --> 00:08:35,744 that business value frequently. 191 00:08:35,744 --> 00:08:37,561 We're not afraid to change our code. 192 00:08:37,561 --> 00:08:39,293 We're not afraid to add new features 193 00:08:39,293 --> 00:08:41,872 because we have all these supporting safety nets 194 00:08:41,872 --> 00:08:43,253 and regression testing 195 00:08:43,253 --> 00:08:45,271 and the knowledge to do exploratory testing 196 00:08:45,271 --> 00:08:46,989 and other forms of testing. 197 00:08:46,989 --> 00:08:50,322 So, for the company, that's gonna pay off in the long run. 198 00:08:50,322 --> 00:08:52,752 Collaborate across the delivery team 199 00:08:52,752 --> 00:08:54,592 and with the business stakeholders 200 00:08:54,592 --> 00:08:57,173 to find better ways to build quality in. 201 00:08:57,173 --> 00:08:59,710 If there's a testing bottleneck, 202 00:08:59,710 --> 00:09:03,877 again, engage the whole team in finding ways to remove it.