Ben Weese

So I have 12 pages of notes I was going to go over and then for Monday I was going to go over ATDD. However a lot is going on so this will be my Monday post and I will not be regaling you with every awesome moment I had. Instead I will cover the Testing Breakouts I got to attend and any other thing that maybe a tester would like to know. The weekend was awesome and I would defiantly recommend going next year. So after the keynote by Pete Brown about the Internet of Things I went to my first break of the day ATDD, or Acceptance Test Driven Development.

So in the last article I explained TDD. ATDD is very similar as you can guess but it adds some steps. First you are going to start out with your user story or what the user is asking for. Then you are going to meet with your team to create acceptance criteria which then get converted to scenarios. This is what the developer will be using to write his unit test. So as a QA person your job is to make sure the right scenarios are created. Now the developer has to use what is called Red Green Refactor. This is where they create a test that will fail, why because there is nothing coded. Then they make the test turn green by coding the software then they refactor the code or clean it up.This makes sure they build the right code and it does what we want it to. This is also where they might add in automation. Now this again is not bad for QA as it gives us time to find the big bugs. When the code is does we will want to go over the user story again in order to check for any missing items. The story is broken out to role, goal, and reason. You also don’t want to have to much acceptance criteria as you will need to break down the problem into several unit test that are simple. When converting the Scenarios to unit test you will want to break them down to these components, given, when, and then. The hole point is developing test to develop the code. You can always add in a test to prevent a bug coming back. For the example they used Test Management in Visual Studio.

Next breakout was Automated Releases, so what does that have to do with QA? Well the basic concept didn’t other then they had the QA server updated every night with the newest so the software could be tested. They also would download some of the production databases so the updates could be tested on live data. This is genius and really helps catch bugs but when they get bigger they will no longer be able to get production data as there will be to much to grab. 

Next was a class on running a software conference so nothing to QA based. At the end though I found that he runs Code PaLOUsa in Kentucky and they are going to try to have a track for everyone including software testers this year. So save April 29-30 and about $550 + air fair and hotel and go check it out. I doubt I will have the money to go but I sure would love to. 

The last breakout I will go over is TDD misconception even though the one about procrastination was great it is not QA related. This was about how developers make excuses not do practice TDD. Remember TDD is not testing for the sake of testing that is my job. It is not a replacement for QA, nor the primary testing task. Test before you Code to ensure the correct code so you don’t code more then necessary. This helps with the design so it is not over done. So what were some of the motivations the speaker stated; you avoid syllabus shock, you code a little at a time and are not overwhelmed. You admit you are fallible as you know the test will break. This breaks up the problem making it easier to tackle. You get to focus on refactoring and keeping your code concise. You write less code and clean code. This is about production code and not about testing code. For more about it check out Uncle Bob’s Blog.