 This session is from user personas to testing a project manager's journey towards be hats My name is Michelle Lauer my technical project manager at bio raft. I've been a Drupal developer Since the Drupal five days. I didn't do the math and what year it was I also organized the the Manchester, New Hampshire Drupal meetup contributing author to the definitive guide to Drupal 7 and I organized something called Drupal nights along with bio raft You're gonna do Drupal nights org you have all of our sessions that we record once a month and I'll free for you Just extra learning stuff So by raft the the platform is a scientific research management system and provides an integrated portal for compliance safety oversight training inspections It's essentially it's a Drupal site. It's software as a service. It's a multi site application And we are hiring looking for talented Drupal devs So those are the postcards that I'm passing out We need you to help prevent the next zombie apocalypse because you know you just mix two chemicals wrong and that you get a zombie attack So we'd love for you guys to come find us. There's a couple of us around here So my journey started I started by our off about a year ago And anytime you start a new company, you're inheriting, you know some stuff So I was inheriting existing technical debt We were inadvertently creating new bugs on top of that and although we were going through and doing manual QA for During every release. It was time-consuming and I didn't feel like we were getting ahead. We kind of had plateaued I'm gonna tell you about how I came to our solution Which is about user personas user journeys user stories and finally automated acceptance testing Existing technical debt are things you could fix now, but you don't and you pay for it later And that's what we are experiencing now our application is you know 10 years old Of course, we've upgraded in things, but we are inheriting a lot of stuff over time There was a lot of business pressure in the early days to release quickly and so we cut some corners We said, oh, we'll get back. We'll refactor that later and and we didn't and that caused some issues now our components are not nearly as loosely coupled as we would like and The documentation just inside the code isn't as good as we'd like. So that's our technical debt It kind of keeps me up at night actually What I've decided to do is accept the decisions that were made in the past that's great It got us to where we are and I'm really happy where we are as a company and as an application And so we just need to address new things So we need to very slowly start refactoring when we have a task that is working with some older code We refactor it then we don't start from the beginning and refactor everything We're making the decision to not create any new technical debt all new code is written So it's more loosely coupled so we can piece together the building blocks together The other issue I was mentioning is that you know new bugs every release we release code and the next day We're patching that release because we we missed something and one of our client will call us up And say did you guys mean to do that? And we'll say oh, sorry. No, we didn't let me go fix that real quick And you know one tiny change that you think you're you're addressing one section of the site You can have ripple effects in other sections of the site And it's challenging if you catch it too late, you know, that's when you you get the client calling you We're really good about peer code reviews every line of code is looked at by another developer or myself Before it goes out. So we're trying really really hard to mitigate this We even do this whole manual QA process every single ticket that goes out We checked didn't meet the spec Did you actually do what you were supposed to do and then did it break anything else? We go through and check that we also have what I call the big testing ticket And we go through every single vertical of the site or we go through and say, okay Someone who's got blog section great and they go through basically try to click everything our email sending our status is being changed The workflow moving around as expected and it is extremely time-consuming. It's repetitious doing this every single month On top of it. It's inconsistent. Well, what if I log in to the blog section as a Moderator versus a reader or I'm gonna have a different experience and our is our testing capturing that While I'm thinking about all these things that are challenging me that I'm sure challenge every and everyone who's got an application I was doing some continuing education. I attended a one-day course For agile and scrum fundamentals. I'm sure lots of you have taken a course similar to that I remember I'm a developer. I've worked on agile teams, but I've never tried to organize an agile team So I'm trying to learn as much that I can I did a webinar from Atlassian and where they talked about user personas and user journeys And that was was wonderful and even at our own Drupal nights I learned something one of my colleagues presented on be hat and he did a very technical description of it, how do you get it started and All of a sudden I just had this light bulb moment. I'm like, I'm gonna solve all my problems We already have a culture of quality at my company. We do code reviews. We do manual QA testing Now and we also even have these automatic data validity tests that run every night on cron to make sure the data is the right Type that we expect and things like that, but we need to start thinking about this from a new perspective I need I need some new goals. I want to focus more on the business value What parts of the site are actually most important to our application? And I also want to think about who we're testing as you can't do everything as admin you get a different experience You guys all know that And I also want to have consistent test coverage and repeatable test coverage So the solution that I came up with is Let's start with figuring out who those roles are We have a handful of you know kind of characters on our site Even Drupal roles and permissions and personalities and things. I'm going to try to bring those together and create personas I'm going to take that persona and walk them through a journey on the site. Let them achieve a single task or goal And I'm going to break that down into user stories and I'm going to note which tasks potentially are the most important with business value and With that too, I can start thinking about code coverage here as far as importance And the last thing is pulling all of that together. It will be able to start thinking about automated acceptance tests User personas. These are fictitious characters that represent each different type of person that visits your site What you're trying to create here You're trying to describe the tendencies of the user not not the tendencies of the user but more of their behaviors How do they interact on your site? What are they thinking? What are they feeling? So when you start creating these You first need to define your segments Are there people on your sites that are paid members? Do you have people that are only email subscribers? What about people that you know just donate money regular regularly? Is it important if someone's a man or a woman? Does it matter if they have children or not all these things in there? That you're starting to describe helps you figure out who this persona is Another thing is to start articulating any values and beliefs. They might have Maybe political persuasion. Maybe certain hobbies are important and also start figuring out some personality characteristics There's some people when things don't go right. They throw their arms up the yard. Oh my god It's broken. Well, that's a personality characteristic that you need to work within your site Whereas you got other people when something doesn't go right. They're more persevering and trying to find a solution on their own You need to get into their skin. What's their self-image? Any day-to-day worries are habits that you should be noting at all? And also an important thing is what value do they get from your organization? Why do they come to your site and share an article on Facebook? Why do they donate money? What makes them actually leave a comment on a post? And lastly you can start thinking about a little bit more droobily here is what roles and permissions do they have on your site? Are they anonymous users? Are they paid members? Are they some sort of super user or moderator? Another important thing to note is what tasks do they commonly Complete on your website. Are they uploading photos? Are they rating content? In bio raft. Are they scheduling inspections? Every site's unique. So this is something very specific to your application And the very last thing and I think the most important thing give them a face. Give them a name make them human I told you I was watching a webinar from Atlassian and this is a screenshot of that They've got Emma the Eager and she's got a tagline that says I want to learn as much as I can as quickly as possible If you guys end up watching this webinar There's a little saying where they actually have all of these personas taped around the office everywhere And they have a screenshot of the men's bathroom with it up there So it's it's in their head at all times all all people in the company are now thinking like their users every decision They make is like their users Further down on the card they're listing some of those other things I was talking about skills in this case Software and languages. So for Atlassian, you know Jira and Confluence, that's an important thing to capture for your website Probably not something important, but there's something akin to that that you guys can put on there So we started creating our own this is Roger O'Neill Roger O'Neill is environmental health and safety director. He's the department head He works, you know in the oversight group and his tagline I want to be a resource to the researchers not the safety police So we go through and we start outlining will tell me about Roger, you know, how does he react to problems? What's his role in bio raft? What are some of the tasks that he does and we start rating different pieces? So like I said his tagline is printed there I find that really important because that's the one sentence that helps you understand who this user is so now they've got a Face a name and a tagline Their their job position that may or may not be relevant on your site But for us, it's actually very relevant because the people who use bio raft are institutions and when you kind of need To know their hierarchy. Are they a lab member a lab manager, or are they you know an oversight group? Also important those characteristic traits and traits. I was talking about you know Someone who's really intelligent and you know an overachiever They interact with your site very very differently than someone who's a little intimidated by it I'm thinking of all the times, you know, I'm helping someone like my mother like go through Facebook She's really scared. She's gonna post something that she doesn't mean to our photos We're just all gonna upload and and that's a very different kind of person. That's someone who is not scared of technology So the role in bio raft Like I said, this is specific to our application But it's a paragraph that the Scott describes some of the duties. He does he oversees things. He delegates and What are some of those things that he does? Well, it's a task list here. He views dashboards. He views inspection logs even schedules inspections, which we'll talk a little bit about later and Starting to take your persona and outline. What are their common activities is really important? You can even go as far as to include some Drupal permissions and roles, you know Some sites have an administrator a content admin and just an authenticated user if that's the case Well, you may not you can exclude this section We have hundreds of permissions and roles group together in a new way in our application that we call job activities And these are some of the things that he does. He needs to be able to view institutional biological information He also needs to be able to view the group biological information, which is a little bit more specific So he's got extra extra power in his world This is my favorite we actually hired this girl to help us over the summer She's getting her master's degree in usability studies And she's helping me put all these together and she came up with this graph here I think the visual is very very powerful about you know technophobe technophile. Where does Roger on that scale? So he he's a little bit scared of technology, but you know what he is an expert at bio raft Which I think is really really often and the other important thing is how often is is Roger on the site, you know some of our our users are just the the researchers and When they get an email they come take their training And then they don't think about bio raft for three months, and so they're not on the site that frequently But Roger he's on the site every single day doing a different activity So you put it all back together again. We've got our user persona Next up is the user journey This is the journey that our persona is going to travel on User journey displays a user flow and it really helps you prioritize You know feature enhancements because we're gonna we're gonna start with that persona And then we're gonna take a goal on the website one of his common tasks And we're gonna plot all the actions that person does in order to complete that task The other interesting thing is marking whether these tasks are Are frustrating to the user if they're challenging or difficult how they feel Another screenshot from the Atlassian webinar and they have a really really complicated journey here But you can see even though it's blurry top left They've got their picture of the their persona that got some information about them They've got the journey and then the bottom underneath it. It's kind of their level of engagement for this activity So we've got Roger again His journey here is to ensure a lab will be inspected at a specific date And this is a very high level journey. I mean there's really only four steps. We're entering the system We're logging in we're determining. What's the lab name the date that it should be inspected and Who the inspector should be we add it and then confirm that we did that We've got a nice little graph here, and we've got smiley faces and frowny faces So we know how frustrating the task is for that user So we've identified from this this high level one that determining the lab date inspector is slightly frustrating So let's dive in a little bit deeper Well, what are the steps actually involved in that there's actually a couple ways that you can do that in many sites You know, there's there's five different paths to reach your goal So one of those here is clicking on the inspections in the accordion menu and finding the inspection queue Seeing what all the scheduled inspections are and determining if the lab you wanted to inspect is already scheduled or not So that yeah, not too bad. So that's not where the problem is But there's another way you could get there too instead of going into inspections you can go into all the all laboratory listing Finding the lab he wants to inspect then landing on the dashboard and then scrolling to the bottom to see if it's queued up already and that's where we've identified that Finding the lab to be inspected is actually the pain point So since we've identified that that means well maybe to dedicate some resources next sprint to to figuring that out more and Solving solving that problem When you're putting together you your user journeys You can separate these steps into certain kinds of categories to help you to organize it in your head better If you go online and look at pictures a lot of people actually print these categories in their journeys But the first thing is like discovery and pre-engagement that could be as simple as logging in You know, you've got to log in before you can do anything else. Then there's the investigation or the preparation phase Where you are navigating to the correct pages that you need to to figure out what your Your task is going to be your action, you know clicking submit Perhaps to get you to another page and at the very end the confirmation that your task is complete So that's one way to think about each of your journeys as you saw our the journey that we were talking about was very very simple It's very singular. It's truly scheduling an inspection. It's not even doing an inspection It's literally just putting it on the calendar. So it's very important that you break these down into very very small journeys So you can identify these pain points What I like to do is just to have a range of five, you know, happy neutral sad You don't need to get complicated. There shouldn't be an algorithm for this. It's just red yellow green Now the big question is is well, how do we know what these pain points are? Well, depending on your site pay attention to support requests I mean, we've got clients calling us and emailing us asking us questions like oh, how do I do that? Or I'm a little stuck here. This didn't work as I expected. Can you explain it better? Well, if we're getting a lot of calls in the same area, clearly That's a pain point for whatever reason either they require user training or we need to change our application depending on the scenario The other thing you can do is interview real users. The previous session was talking about that Well, how do you find these real users? One of the questions like well, I've got a site for a college We'll just walk out into the you know the common yard and start asking people great way to interview people But don't forget that your teammates are real users too if you've got a sales team and they're giving demos Trust me that salesperson knows what the pain points are. They do this every single day They know what they trip up on they know what areas they avoid in the demonstration because it doesn't work quite right So interview real people So we've got our persona Roger Roger takes a journey to schedule an inspection We can break that down even further Into user stories A user story is a description of a feature from the perspective of the person who's going to be using it Which is clearly in our case. It's going to be Roger The value comes from from putting the user experience first and on all of these situations and it really helps you understand Why why did we build this feature? I mean I could very clearly put you know a card in my sprint This is we really need a picture of a pony in the bottom right corner But someone says why and it asks me to write a user story I'm not going to be able to deliver that so should reevaluate how important that is But if you can answer why and there's business value in there, then it's worth developing that feature user stories follow the format as type of user I want some goal so that some reason you guys have all seen that before I'm sure as An environmental health and safety director. I want to check the inspection schedule for tomorrow So I know what to expect Clearly follows that pattern as the EHS director I want to schedule an inspection so that the inspectors know what their tasks are As an EHS director, I want to schedule an inspection so that the lab managers are prepared for the inspections See what I did there talk to her the same, but the why is different There's actually two reasons why you might want to do a task Those by the way potentially have two separate journeys to because you might be able to do a journey for this lab member Who checks their email to see if they have notification that an inspection was just scheduled or a reminder saying hey It's this morning. You might want to take all food out of the lab so you need to really think about the reason why and Different people different users in your system will have different reasons why More common examples that you might be familiar with as a member I want to upload photos so that I can share photos with others as an administrator I want to approve photos before they are posted so that I can make sure that they're appropriate One thing I want to make sure you guys realize is we use our stories is this is the fodder To actually creating a ticket in you know Trello or Jira to give to your developers You take these user stories and you make your balsamic mock-ups and you make sure they fit so the developers going through the very end and And did he accomplish his goal like can a regular member upload photos? Yes, that works Well, it's not very specific your mock-up will have some more information or maybe you need some sub stories Or elaborate more. I want to make sure not that I can upload photos necessarily I want to make sure when I go to my profile I can upload a new profile photo That leads us into behavior-driven development. We actually just spent a lot of time talking about behaviors And now we can use that to begin our our journey into testing our own application So BDD is a specialized version of test-driven development Which focuses on behavior specifications? It's not if I pass an array to a function that's expecting a string and my test fails This is really about what is the user expecting? The one unique thing about BDD or test-driven development is that you write the test first There are so many projects where you try saying to the client, you know We're almost done. We just have to write the tests and they're like, oh, no No, we don't have that in the budget and this test never get written. Well, what if you write the test first? Then it's always in the budget because they're gonna want that feature So you define a test set for the unit first you implement the unit you you code And then you verify that the implementation of the unit test actually succeeds behavior-driven development is for business analysts so project managers product managers and Developers the joint effort they need to collaborate and they take those user stories and they're going to transform them Actually into test cases There is an absolute direct correlation between every user story you've written and The behavioral driven development style test that will be written. It's just one next step you guys have to take User story we just saw this as a member. I want to upload photos so that I could share photos with others follows a pattern a BDD scenario given that I'm logged in as a member when I'm on my profile page. I should see a link to upload photos Again follows another pattern. They're very very similar. So once you've got the user stories Translating those into tests is just one extra step When pulling all these together with behavior driven development You have a file for each feature. So you've got a search feature a photos feature a blog feature What is that section of your site that you are testing you can get as granular as you want here? This is purely organizational and In each of those files, you're going to list your scenarios And my favorite part you get to tag them too just like you tag content so you can find it better So if I've got the an events scenario I can have one for browsing one for adding events and you can just add tags to it The other thing that's really really good is that you can tag something as test So when you are literally working on something at that moment, you can say only run these five And I only want to run things that are tagged with test So you don't have to go through your whole suite over time your sweet is going to get pretty big You know they could take a while to run and that's wonderful But you don't want to do that every time you add a semicolon so you can specify that That brings us to be had be hats just a flavor of behavioral driven development There's actually a lot of them out there, but Drupal has adopted be had as its favorite You're probably part of Selenium. That's another one too So it's just a tool Helps you write human readable stories. That's the key here These stories are not in some jargon that you need a PhD to understand. It's in English So it follows a pattern to that is very very easy to read. I talked about those files So here's an example of a feature file. This would be the events dot feature at the very top of the file You say what it is and then you kind of describe it a little bit in order to find events as a website user I need to be able to see them display Well, that's the motivation of everything in this file and the way this file will get Interpreted is after feature it expects three lines and it will not execute those three lines until we get down actually into the individual Scenarios you can use hashtags for comments and you can see I've added one here. It's purely that Demonstration purposes. They're not really necessary So for each scenario first thing I'm do is I'm tagging it. That's what the at sign is I'm tagging this one as Drupal nights I'm tagging this one as events You could say perhaps you're testing some things that are more Drupal core related like a user logging in It's kind of independent of your site in many cases. That's what Drupal does So you could tag something as core versus, you know, my site, which is Drupal nights We've got our scenario This is expected syntax as well The interpreters will expect to see a description of what each of these tests is and so the scenario is see the next Drupal nights event So given that I'm on Slash, well, that's the front page. Then I should see the upcoming Drupal nights block inside bar a region That's easy. You guys can write that right So we've got a couple things in quotes here These are actually variables so that our code in the back end can be reused you can pass in variable sometimes You're going to be inside bar a sometimes you're going to be inside bar B. So you just pass that in inside the quotes Same is true for upcoming Drupal nights. That's the H2 the block title another example This would be the contact dot feature for my site in order to submit feedback as a website user I need to be able to fill out a contact form So we tagged this as Drupal nights and contact. I've got a scenario do not submit form when required fields are not filled out So as I go through I Have filled out every single field Explicitly when I get to the line that says and I fill in message with empty quotes That means I didn't fill it out. I essentially skipped over it I hit submit and I should see message field is required So that then I should see it's just reading the text on the page and if it shows up It's there and then it passes that test This one's a little bit different. It's another way you can test the contact form This is showing how if filling out the entire form You get success and I was actually funny story So I'm playing with this, you know up in the lounge beforehand and making sure I get my screenshots for my code We're all correct and then I take a break and I look at my phone I'm like who's sending me all these messages Well, it actually submits the form. So keep that in mind. Make sure you're reroute emails on when you're you're testing So this one I should see your message has been sent and clearly it works because I got the email So all that human readable code we were just looking at is very very easy But this is where it becomes a collaboration between Product and project managers and the development team there needs to be a back-end that interprets all of that English And it's your file your feature context at PHP file Here we've got a function that if you can see the titles as I fill each field of form with random text So I don't know if you guys just saw when I was filling out the form I explicitly filled out every single field That might be the best test for your website But you also might want to say when I hit this form just fill out with random stuff I don't really care what's there. It could be any string And then we'll work with that. So that's another reason for the collaboration I only do does your development team need to come in and and write some of this PHP code in the background They're actually going to talk to you as you're writing your tests you filled out every single field Is that actually the right thing? Are you testing certain values and that's what the important thing is or are you actually trying to test that? You can submit a form and you don't care what the values are. It's all about collaboration One really cool thing with be had is there because there's such a great community in Drupal around it is this feature Context dot PHP you can actually download a bunch of them where they've got common Drupal things like if I log in If I search and all of that is ready to go you just need to when you look at that file It's it's written that the function name is kind of an English So you and it shows you in the comments Which unfortunately had a snip out of fear of actually how to write that step is as given I am on then I should see it gives you all that information So the next thing is let's run some tests, right? Here's a snippet of my terminal I choose to run these from my terminal and you can actually have it all run As a headless browser, so you don't see anything that happens or you can have it run through Selenium and that will actually pop up a browser and you can watch it click through everything and moves really really really fast, so It's hard to do that way But you can put in steps that say and I wait and I wait so it slows it down So your eyes can catch up and follow but you can actually watch every single test happen and it basically be clicked on So in this example, I'm running tags equal test I didn't want to run my entire suite just wanted to run my test ones It displays right there in my terminal the name of the feature and You know in order to find Events as a website user want to be able to see them display and then we see the tags This is the at Drupal Knights the ad events and also the at test Tells me my scenario tells me what file that scenario is on and what line it's on and The next thing it does is actually runs it given. I am on the front page Then I should see get notified about upcoming events block inside bar a and at the very very end It gives you the statistics the synopsis and it says we ran one scenario that one scenario passed and in Everything that we ran there was actually two steps and those two steps past and it color codes it and makes it green for you Here's another one that I tried running and it says When I fell out each field of contact site form with random text the sound familiar I just showed you the back end code for that so this time I'm running through and running it the contact form a different way I'm gonna fill and then I fill out the subject field with nothing So I overwrite what I had just filled out randomly so that I had one that was nothing and then I dance a jig I should get an error message Okay, let's look at my my statistics here I ran a couple other things with this so there was a total of three scenarios two of them passed One of them was undefined. I had no idea what to do with it So that breaks out to 15 steps 13 passing one was skipped completely never even touched and one was undefined So this was my test and when it got everything's passing it's all green until it gets to I dance a jig and There's no back-end code that tells it how to do that. It has no idea what to do So it goes yeah, that's undefined and because of that I can't complete this entire test unit So I'm going to skip the following one so That's a little scary like right now done defined. What do I do? Well, it is so nice that after it goes through it actually prints the code right there and says you can implement this step definition and it gives you the snippet of code for you to paste in your Feature context that PHP file now what it does say is it's it's an empty snippet It does have the great documentation at the top that says given I dance a jig That's that format that I said that you guys all need to follow It names the the public function very similarly But it says throw new pending exception So that means now it doesn't know how to test it yet and it's going to throw an error But it'll keep going as if it passed so that your skipped one will actually get tested And all you need to do is paste that into your file and as you're working with your developers too I'm either you or them could paste it in but that's a red flag like I got to go back and figure out How do I test dancing a jig? One of the important things when you're starting this especially when you've got a site That's you know start to ten years ago was like oh my god. Where do I begin? How do I test everything? So my recommendation is what has the most business value for you one of my obvious examples is uploading photos Every now and then when a safety officer is submitting an inspection They want to take a photo of broken equipment that happens every now and then if you run a Flickr site and someone can't upload a photo and that's that's devastating So your business value is testing that whereas my company we're going to put that on the back burner It's not that big of a deal. It's not going to make us Everything you know blow up for us So what feature if taken away would essentially render your site useless different examples registering logging in Customizing profiles our site no big deal. You're running something like a Facebook yet user profiles are very very important So making sure you start your test coverage with that Another way to go about it is you've been tasked with some new feature development So every time you've got new development You're writing tests for that immediately And very very slowly so you've got that they're like what's the related thing that I can tack on to this That's got high business value. I'm already in the section. I'm very very familiar with it So writing a couple more tests for the business value ones. You can add those on Users are the most important part of a website if you don't have users Why would you need a website? You need to put them first? You need to understand them and their needs That's why we're creating personas to try to figure out who these users are We're outlining their journeys and defining the user stories and these are things that as project and product managers You're doing anyways. Let's take that next step and move to behavior-driven development the other thing that's wonderful is that Agile practices like I mentioned and BDD it encourages communication between Those two departments a lot of times, you know the product team the developers they work in silos and communication is very very Challenging you're forcing them to work together if the project manager is writing the human readable code And the developer comes in to write the back-end test for that and then all of a sudden there's conversation going on Is that really what I want to do? Do I want to fill out every field on the contact form? Or is there another way? Is there a better way? And there's a bonus if you migrate your site to another version of Drupal and you haven't done a whole rearchitecture and redesign Or maybe you switch it to another platform all of your scenarios Will still work the back-end code will need a little bit of work But the the user stories and then the scenarios that you had written should all be the same So to recap this all started because I couldn't sleep Technical deck was keeping me up at night. We kept making new bugs and we trying our darkness to QA everything And it just taking forever. We were not being efficient So we needed to find a better way and this was our better way We started defining personas, you know a site maybe has ten personas Jot those down like on a napkin take one of them and really Flesh it out figure out who that person is and for us. That's Roger. We feel very very close to Roger We're actually very fortunate So we have all these client sites, but we also have Earth Institute which is our our demo site And it is a fully functioning filled out version of bio raft and Roger is the EHS officer in that So from the day that I started at bio raft. I was introduced to Roger, but he didn't have a face All he had was you know like a job description and that's it. So it's about taking that one step further Figuring out what their most common tasks are highlighting which journeys have the highest big business value And then breaking those into steps your user stories and writing your test cases first Then developing and then it's acceptance testing you if you approve those test cases as the product manager They go develop and it passes well then they did their job right it matched the spec that you are already approved approved So taking the deliverables from these best practices that everyone preaches in project management and usability It's amazing fodder to start a behavioral testing initiative in your organization So I've got this great little picture here. I love pictures It's not a full circle But everything that you start with the user personas work to journeys break it down into stories and Bam you've got behavioral testing and then you sleep at night. So I did a lot of research So I've got a lot of links. I recommend that you download my slides to click on these links I will be posting these to Drupal nights org as I had mentioned earlier We once a month via Google Hangouts we do Presentations down in Cambridge. They all go on this website slides and video and anytime anyone on my team presents at a camper Con it's another place for us to upload slides So that's where I'll be going to post these later today or tomorrow, but it'll be on triple nights org Any questions? Yes, there's a microphone right here What do you want to shout? Group would you be my group? So it you start the process by thinking in my head is like well Who's the most important user on my site? What type of person is that your power user of sorts and there might be you know a handful so you don't need to grade them but take someone like that who is in your site very very frequently and I guess it start Sketching out a napkin have a brainstorm step brainstorm session You know where there's no wrong answer and write down every single one of those in a very high-level form and then discuss Okay, which one has the highest business value and then take that one and do the deep dive and then go back to your entire list We have a couple of our personas completely flushed out But the rest are still sitting on a napkin because we're It's business value. Who do we want to spend our resources on? And so it depends on your site by categories. I mean for us. It's very very easy We have actually a role in the site. That's environmental health and safety. We have a lab member We have a principal investigator So those are very easy for us to pull from Your site and maybe obvious or you might have to think it might be everybody in your site is actually The same role, but you're really thinking about personality traits and other characteristics Like the person that is scared of technology versus the person that is trying to hack your system And you could take those different paths as well Yes So you can like I was just filling out that form with your name Well, you could have a scenario that says, you know, if I fill out the form with 47 characters, I should see an error message that says only 40 characters is allowed So it really depends on your what's best for your organization A lot of organizations filling out the form with the random text and hit and go just making sure it submits is all They need in other cases Data validity is actually the important thing. So you're in your human readable step You say if I fill out the form with you know, whatever X number characters And then I should see whatever that error message is so you can do that for each one Yes Well So the question is is how do you get project managers to want to write tests and participate rather than just the developers where I'm coming from the perspective. I'm like, yeah, I need to get my developers to do it now I think the easiest way is they've already done 90% of the work if they've got their user stories They're 90% of the way there You I mean the one thing about agile is that you know, you're iterative and you change your processes and you there is no Flavor of agile that is the right one. It's what works for your organization So maybe instead of writing strict user stories. Just have the right to tests They're very similar. I mean we saw that pattern, you know, okay, so we change we we flip the bottom two lines essentially That's how I would do and they're 90% there. The other great thing too is If after they're coming back and doing the spec check after development It's very clear if the developer has done a job or not and all they need to do is Basically, it ensures if the test are written. Well, the developers will follow the spec every time Which is really nice. Nothing is worse than like doing the final confirmed You know phase of testing and going well, this works wonderfully, but you didn't follow the instructions Well, the test is going to tell you that Yes, so I recommend starting with new features That you are developing for your site first and start that process with them So all of a sudden you're adding a blog feature to a website that no longer that didn't have that before Write your tests Build it run the tests, but then the question is well, what about this article feature that I already got? When do I fit that in? one way is Blogs and articles maybe behave a little similarly so that you can borrow some of those tests and Exit start with the new features and then slowly build out the one the other parts of your existing parts of your site That have the highest business value. What if the things that if they were broken on production would really make people cry? Yes at the moment. We are not using any tools That's an excellent thing to try to figure out because we're not looking at lines of code You can count functions on a site and say I've got 50 functions, and I've got 49 tests I'm doing really good, but this is this is the user's experience To for Rogers example in order for him to schedule an inspection I showed you you know the high level and then two possible, you know paths you could take just to do that I bet I could find 50 Okay, maybe not 50 So there's no way to track that unless you're making a list of like these are the ones I need to accomplish now. There's no way to know It's the user's experience. It's quite variable Yes Sure, I have extremely limited experience as in order to compare But the one thing I'll say is that all of these tests that we were writing you've got two ways to run them You can run the be hat test with the headless browser That's just running in the command line or you can say hey use selenium and fire up firefox for me And that's what selenium looks like is it's firing up firefox another thing that I have seen it was a presentation I went to at I believe it was Boston PHP and they were talking about selenium and I felt like that they were writing Code extremely repetitively. It could have been the style of the developer or the limitation of selenium The one great thing about be hat, which I was not sharing much code here This but you can actually put a table like a matrix of data and say can you loop through this? This is my Variables for x my variables for y and I'll run through the whole thing So if you've got cases where you've got a field and it's got eight You know restrictions on it needs to be 40 characters and he's an explanation point He needs this and needs that you can have your test cases run through and Try this this should be my error try this one I should get this error and all in one test so you're not writing that function every time Is in be hat so that I find that to be a benefit to Yes Talking about developer overhead to write the the PHP back-end code for it at the moment I'm the one writing it and it takes a very long time for me So I cannot begin to estimate a seasoned PHP pro how how that would work The benefit is is the organization is already done for them because when you write your tests If there is not a back-end code you get that pop-up function that says this is what you need to do next and you Prioritize that what I like is that the consistency You can preload your system with certain variables and saying I Before you run this test take care of this this business work We need to make sure that this user is created a fresh user Rather than using some real person on your test site so you can take care of all of those So you know what your outcomes are going to be because you've preloaded the system and then it can clean up after itself as well I Hate it when people ask well, does test to take more time? Well, of course it does but do you have a better product because of that? Yes, you do I the question is how much time do you allocate what percentage of your your Project to testing and I don't know the answer This is something right now that an initiative that I started at my company and it's a slow process where I'm I'm still learning out The best way so that I can get everyone on board. They all think it's wonderful Very supportive, but we haven't actually got to this point where we're we're implementing everything for every for every feature. Yep Sure, our sprints are the entire thing is roughly four weeks Basically on a Wednesday, we release code and and then Thursday's like retrospectives and kickoff and everything like that We do a feature freeze three weeks in and then release Four weeks so our we try to test things on each tickets going forward But that last week is essentially a testing sprint not only are we testing the tickets? But then we're doing that that major like my big testing ticket We're going through and trying to click everything in the blog and everything and our developers all Participate in that we even pull in some people from the the account management team You know to come in and help us with that because it's so big and so important the things that we find by just Unvariably hitting up bugs in the system We're not at that point yet. We're still doing the the user stories with the the mock-ups User story with mock-ups To to be hat-testing So we do things a little bit differently as far as estimating goes We're not necessarily we're not billable per hour based on our institution a lot of times what we're developing is a Collaborative approach so when we estimate tickets, it's actual true development time It does not include any any testing or bounce back and things like that So our organization is a little bit different, but you ask well, how do you factor that into the whole process? It's not about the sprint. It's about the ticket each ticket has a test involved with it so if I have a ticket to Change Let's see you've got username printed like you welcome username the top of the site and that the ticket is to change that to Welcome first name last name well before you start writing, you know that that theme override you go in and you say You find all of the existing tests or if there aren't any make your test right then and there Then you write your code and then test it so it's it's part of the development process in the development hour So I guess I agree. Yes. Yeah, you can't close the individual ticket until the test is back as it was written You developed you ran the test the test was successful then you can close your ticket out The challenging thing though is like that's that's for the per ticket That's new development is when you're trying to to go through your backlog of These are the features already on my site and tackling those like when do you when do those get tested and you just weave those in? Yes So with be hat there's a YAML file Which is just a text file that has a couple variables in it and it asks you what's the URL you would like to test? So you put you know development dot biaraft comm and that's what it goes and tests So you can I mean one of the last demonstration I saw they went to Wikipedia and that they tested Wikipedia So you can test anything that you can access, you know via the web or via your local machine What I've so I have gone through one of the the Drupal be hat modules And grabbed the back end code and was looping through that and I added that in Time for about one last question So when I ran that via the command line There were the statistics at the bottom and it said we ran two tests in those two tests one passed one failed and Of what we ran and this to test there was actually you know 13 steps and these are the ones that passed These are the ones that failed so They can see basically you've got greater code coverage every single release and these are the number one's passing and Depending on what fails. I mean that's kind of up to you if it fails. Is that is that a release blocker? It depends what that test is you may say, you know, no, we'll get that and you know Next week during patch, you know, they're fixing things or or not, but in an ideal world Yeah, it's a month's print So you've got time to run this over and over again You can run the ones just for what the area you're working in but then you can periodically actually run your entire suite of tests and check Your entire application because if you're only running the ones for the section you're working in You're not going to notice that thing that keeps me up at night is where I change something here and that breaks So you do need to constantly run your entire suite Awesome guys. Thank you very much and stickers