stuartdobson.net

As discussed in my last article , Writing good Acceptance Criteria gives the Agile team clarity and helps them work towards a common goal, saving time and effort while increasing quality. Now I'd like to dig into the details of how to write good Acceptance Criteria. Behaviour Driven vs Procedural Driven Mindsets Many of us may be used to writing/seeing procedural driven tests; step by step instructions with actions and expected results. Procedure-driven tests are often imperative and trace a path through the system that covers multiple behaviors. As a result, they may be unnecessarily long, which can delay failure investigation, increase maintenance costs, and create confusion. Acceptance criteria, and indeed Behaviour Driven tests, should instead be behaviour driven. This means they should be Declarative , specifying how a system should behave in a particular scenario. Procedural/Imperative: Given the user opens a web browser And the user navigate

I've tried all the game controllers. They all have such major pros and cons. If someone could put all the good features into one controller, it would be amazing. Xbox I owned the Duke , and I didn't mind it, but I have decent sized hands and it still felt like a bowl with buttons so when they brought out the newer controller I felt it was a good move. Ever since then Xbox controllers have been the most natural, comfortable controller out there, without question. I had a 360 controller for over a decade and a half across the Xbox 360 and PC, and it just worked.  I love the concave thumbsticks, I'm cool with the offset sticks, the buttons have always felt solid and the triggers get smoother with every release. It's a solid controller in every way, the D-pad on the new Series S controller is clicky but robust, the whole thing is comfortable and high quality. I love the Xbox controllers. They are now, however, missing some significant features. Switch What can I say. They a

Acceptance Criteria can be seen as a chore, a convoluted, verbose set of prose with the sole purpose of satisfying "the business". At best, its value is underestimated and it is often written as a vague list of requirements. Given the right attention, Acceptance Criteria can be extremely valuable to all members of a Scrum team. Before it can be done correctly, we have to understand its value. So what exactly is the point of Acceptance Criteria? Purpose of Acceptance Criteria To define boundaries Acceptance criteria help development teams define the boundaries of a user story. In other words, acceptance criteria help you confirm when the application functions as desired. To reach consensus Having acceptance criteria synchronises the development team with the client. The team knows exactly what conditions should be met, just as the client knows exactly what to expect from the developed functionality. To allow for accurate planning and es

Imagine you're reviewing some code, as part of a Pull Request, and the developer has misspelt a variable. Or added a magic string instead of a constant. Or put the expected/actual parameters in an assertion the wrong way around (although it kinda doesn't matter because they're the same)? You can politely comment on it, and perhaps they will fix it up. But sometimes you might be met with resistance.  "It's not that important." To a degree, they're right. These are pretty trivial observations. There are probably bigger things to address, such as the logic, the architecture, the test coverage etc.  However, in coding, these trivial issues tend to come back to bite you, either as bugs, or as maintenance headaches. You don't want to nag people. You don't want to become a "clean code nazi". But you can firmly assert that you think a mistake is being made and that a potential issue could arise.  There are some things in coding that are a persona

Acceptance tests can be used to verify end to end functionality in a way that is understandable to the business. They are very broad compared with unit tests, and when automated via a tool like Specflow, are based on a more natural language. It's important that we use this natural language to keep tests simple and concise, rather than trying to write long-winded "functional" tests. Good Gherkin Before writing Acceptance tests, learn about Acceptance Criteria Best Practices . The ability to write good Acceptance Criteria translates directly to Acceptance testing. They both follow the same standards and they can be written in the same way. We should attempt to apply these best practices apply to Acceptance tests as much as is practically possible, especially when it comes to grammar as this helps us stick to a standard. The most important thing is to remember that Acceptance tests should be written with the Given, When, Then syntax where: Given sets up a state, When is an a

It seems to be by default that classes, methods, etc are created with the public access modifier. This is not actually the case, the default is internal class/private members, but public seems to be the de-facto choice by a lot of developers. If you're creating a public class - you have a big responsibility. Your code can now be used by anything else in the application, or even outside it. This means if you change the internal working of it, you will affect everything that uses it - and you have no control over what that is. This means a couple of things. Naming is always super important Naming of public classes and methods and their expectations should be crystal clear. Don't rely on comments to convey intentions. It must be highly obvious what the class is for, what it does, and how method parameters are used. It should be specific and adhere to the Single Responsibility Principle - one reason to change. If someone comes along and adds a parameter to one of your methods t

OK, no developer wants to create bad quality code. But for most developers, quality is seen as something separate from development, something that is checked after the work has been done. It is something that QA do, after you throw your code over the fence. Thinking about quality at during development is a burden, slowing down the creation of functionality, holding up new features. Thinking about quality before development, well that's just crazy talk. Old Habits Die Hard In the Agile world, this is starting to change. Quality is being baked into the development process and there is more interaction between development and QA during the development phase. At least, that's the theory. In practice, we often slip back into bad habits of throwing code over the fence. The reason we keep falling back into bad habits is because the attitude around quality is the same as it always was. It is still seen as something separate from development, separate from design, separate from pla