Monthly Archives: February 2017

The Clean Coder, Chapter 7 & 8

This week of reading: Chapter 7: Acceptance Testing and Chapter 8: Testing Strategies from The Clean Coder by Robert C. Martin, covered importance of acceptance testing and the role of Quality Assurance (QA) in the designing, building and delivering of a successful product.

In chapter 7, Uncle Bob explained that there is often misinterpretation and miscommunication between the stakeholders and programmers. One remedy to clear this uncertainty between stakeholders and programmers is to use acceptance testing. Acceptance tests eliminates communication errors between programmers and stakeholders. As Uncle Bob stated, “They are completely unambiguous”. Acceptance tests clears up the communication between what the stakeholders wants and what the programs should deliver. These tests can also be looked as a perfect requirements document.

In chapter 8, Uncle Bob elaborates on the different testing strategies in order to strive for an attempt that QA should find no bugs or defects in the software/product. For this Uncle Bob suggests that first, development team in an organization have to count QA team as part of their team rather than treat them as their adversaries. Development team have to work closely with QA to arrange hierarchy of unit, component, integration, system and exploratory tests. These tests should be run as often as possible which will assure clean system with maximum feedback.

So far in the semester, we been constantly discussing and defining what do we mean when we say we are done? By reading these chapters, it cleared up what does ‘done’ means for a professional developer. Uncle Bob states, “Done means all code written, all tests pass, QA, and the stakeholders have accepted.” Normally, every person or team has their own meaning and definition of done, but when it comes to the business world we have to be on top of our game. We have to be responsible for not only ourselves, but we have to make sure that the team thrives too, and is successful in completion of the project. I believe, I can apply this strategy to our own team projects at university and in professional career that my team’s success is my success. In order to do this, I should be as transparent, positive and open as I can be with my team members. We should reach the ‘done’ part together, not individually.

From the blog Software Learning and Development – Haider Hussain by hhussainsite and used with permission of the author. All other rights reserved by the author.

Clean Coder, Chapter 7 & 8

Chapter 7:

Chapter 7 is titled Acceptance Testing. Well that is kind of strange because one of the chapters in the book for Software Quality Assurance and Testing was all about this and I wrote a blog Post about this very topic. Acceptance Testing is the process of asking the customers about what they really thing the software you are making should do, IE its behavior. This will give you a set of requirements that you can use to create acceptance tests. Then these would be used to set a proper definition of done, like he explained in an earlier chapter. So when the software behaves correctly and passes the tests you are finished. This way of testing helps to clear up any trouble in the beginning and end of a project.  This helps everyone get on the same page. The developer and the customer will understand what the software should do and how it should behave.

Chapter 8:

Chapter 8 was titled Testing Strategies and guess what? You guessed it! This chapter is all about Testing Strategies. This chapter helps to outline some good strategist to use when testing. One of which is to develop tests so QA isn’t necessary. What I mean by this is if you find no bugs then QA can focus on harder problems and everyone helps to make a better product. The author then details the Test Automation Pyramid. Sadly it’s not a transformer. But they do include a nice diagram of the pyramid.

capture
From Clean Coder by Robert C. Martin

This pyramid looks quite daunting but it really isn’t. The bottom layer is Unit test which are written by  programmers and for programmers. These test should be run constantly as a part of continuous integration. Next is component tests, these tests encapsulate a component. These tests are written by QA and Business with assistance from development. Integration tests test how well the assembly of components work together. System tests are automated tests that are executed against the whole system some tests in this section are throughput and performance tests. Finally Manual Exploratory tests are human made tests to explore the system for unwanted behaviors. In summary all parts of a company should work together and have a good strategy when it comes to testing.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Clean Coder, Chapter 5 & 6

Chapter 5:

Chapter 5 is titled Test-driven Development.  The Concept of test driven development might sound odd at first.  I mean writing tests first? To me it was very weird because I normally dive head first into any problem I am challenged with.  For the most part it has worked out but, TTD sounds like a more logical and strategic way to code.  It would be like knowing the questions to a test before taking it.  Planning your study session with the questions is a significantly easier way to study.  Well it sounds better written out, why didn’t I think of it earlier? Anyway, TDD is writing tests that fail then only writing enough code to make those tests pass.  It can help with not breaking the entire thing by knowing what’s failing and what’s not.  So if you write a new piece of code and all the tests fail, Then you know you messed up.

Chapter 6:

Chapter 6 is titled Practicing.  Well everyone knows that you cannot get better at something without practice.  But, sometimes you have to be told that before it gets in your head.  There is a saying that most know, it goes something like “the master has failed more than the apprentice has even thought of trying.”  This supports the argument of practice makes perfect.  Anyway, The author talks about a martial arts technique Kata and what it means in programming.  This is a set of keystrokes that simulate solving a problem.  This problem you already know the answer to.  Then he details some other types of Kata like Wasa and Randori that involve more people.  The entire chapter helps to enforce the idea that professionals all practice.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Week 4: The Clean Coder

I read chapter 7 & 8 of the clean coder this week.  To sum up chapter 7, it basically talked about how important it is to write automated acceptance tests.  Communication between two parties can be extremely difficult in the workplace.  There are many times where a customer and a developer, or really any two parties might think they completely agree on all the details they discussed, but in reality they might leave having two totally separate ideas.  It is very easy to assume someone understands something when in fact they aren’t on the same page at all.  This chapter showed me that writing these acceptance tests are a great way to solve the problem of miscommunication in the computer science field.  The chapter defines acceptance tests as, “tests written by collaboration of the stakeholders and the programmers in order to define when a requirement is done”.  I really enjoyed reading this chapter.  It brought light to my eye that there is a way to fix the problems of not getting across what will be done clearly and precisely.  I remember in class we talked about “the definition of done”, and this chapter also discussed this.  Your definition of done can be completely different then the person sitting next to you.  It is very important to clarify specifically when discussing what is going to be done so everyone is on the same page.  I remember I had a presentation once and I thought one of the members in my group was going to make slides on a certain topic.  When it came the day to present, we realized that we completely miscommunicated and ended up both doing the same thing.  This chapter reminded me of this specific time.  It’s a good idea to follow this practice in order to prevent these types of things from happening in the workplace.

Chapter 8 discussed how important it is to constantly test your code as a developer.  This chapter touched on 5 main types of testing that should be run as frequently as possible.  1.

  1. Unit Testing
  2. Component
  3. Integration
  4. System
  5. Exploratory

I could not agree with this chapter more.  The deeper I get into the field of computer science and programming, the more I am starting to see the importance in testing.  Although testing can be extremely tedious and boring, it is something that you must do as a professional engineer.  Many developers tend to think that they don’t need to test anything because that’s the QA’s job.  However, this is not true at all.  This chapter talked about the importance of the developers and QAs working together to test EVERYTHING.  An interesting statement that was mentioned in this chapter was, “It should be the goal of the development group that QA find nothing wrong.” I really liked what the author said and I agree.  In order to be a great coder, you need to not only be able to write a good program, but you also need to write good tests so you can catch the problems before the QA, or worse, the customer.

From the blog CS@Worcester – Alex's Comp Sci Blog by alexsblog13 and used with permission of the author. All other rights reserved by the author.

The Clean Coder Chapters 7 and 8

 

This week we were assigned to read chapters 7 and 8 in The Clean Coder. Acceptance testing ensures that the code is working to standards according to the customer’s needs. This is important because sometimes requirements may be ambiguous and up for interpretation. These tests are put in place to set some sort of framework down so developers have something to work around. Sometimes after discussing with the customer, developers may have different ideas than what the customers actually want. Putting these tests in place is necessary because they act as “the perfect requirements document”.

Chapter 8 is about testing. Just because you have a QA department, does not mean you can leave all the errors in your code for them. You should aim for your code to be 100 percent error free when you pass it off the QA. It would be wise to work with QA to create unit tests, component test, integration test, system tests, and exploratory tests. It is important that you use all of these testing strategies to make sure your code stats bug and error free, and it working to standard.

From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.

The Clean Coder Chapters 5 and 6

 

Chapter 5 in The Clean Coder is about Test Driven Development. There are three laws when it comes to Test Driven Development. They are:

1.) you are not allowed to write any production code until you write a failing test.

2.) you are not allowed to write more of a unit test than is sufficient to fail, and not compiling is failing

3.) and you are not allowed to write more production code that is sufficient to pass the currently failing unit test.

Following these steps makes it so that you have to test the code every step of the way. This can avoid all the errors being thrown at you at once if you don’t test till you are done writing your code.

Chapter 6 is about practicing your coding. It is true that it is your job to keep your skills sharp and not your employers. Therefore practicing should be done on your own time. The example of a surgeon not being paid by a patient to practice before going in to the surgery room was made, and it helps put things into perspective. Keeping your skills sharp, and your resume tuned, should be done on your own time.

From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.

Reflection week 3

This week we reviewed what we did last sprint. We completed our peer evaluations, which were all good, but at this point it is hard to tell how our peers are doing because we haven’t done much collaborating. We all did a good job keeping up with the tasks that needed to be completed for this sprint. We also god a overlook on what we were going to complete next sprint, this next sprint was all about setting up AMPATH and OpenMRS and modify some existing code to get it working. Next week i plan to successfully re structure the code and get it working, as well as getting AMPATH and OpenMRS working. This week was kind of slow in terms of work that needed to be completed, so i looked at some more angular stuff.

From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.

The Clean Coder: Chapters 7 & 8

In the 7th chapter “Acceptance testing” author Martin discuss about the communication aspects between programmers and stakeholders. Then he drives into the essentials of having acceptance tests to narrow the communication gap. Martin argues that in reality, the communication of requirements is extremely difficult. Because of which both programmers and stakeholders often falls into various miscommunication traps such as premature precision, estimation anxiety, and late ambiguity. Then Martin suggests a solution: is to write automated acceptance tests. Acceptance tests helps to define when a requirement is ‘done’. Due to cost reason acceptance tests should always be automated. Professional developers should take responsibility for their part in ensuring that acceptance tests are automated.

Furthermore, Martin clearly states acceptance tests not being the same as unit tests. Although they may test the same things, they do so through different mechanisms and pathways. Unit tests validate the system from the developer’s point of view whereas acceptance tests validate the system from the business and QA points of view.

Moreover, the chapter talks about the challenging to write acceptance tests for GUI. Alongside suggests the solution to design the system so that you can treat the GUI as though it were an API.

I personally know how to write unit tests as being a programmer. I don’t have any experience as of now as a stakeholder. From my part I will definitely make sure that the tests are fully automated and easier for non-programmers to understand. I will specify all the details during my testing phase for the stakeholders to ensure that the system they are paying for really does what they need.

The next Chapter “Testing strategies” revolves around the disciplines of Test Driven Development. Author explains about unit, component, integration, system, and manual exploratory tests. The test automation pyramid diagrams summaries the concept of those test. Author argues that unit tests provide as close to 100% coverage as is practical. As good as it is to have a suite of unit and acceptance tests, higher-level tests are needed to ensure that QA finds nothing.

I am not exposed to any other tests rather than unit. I will definitely work together with QA team to ensure the quality of the system.

From the blog CS@Worcester – Software Dev Capstone by osworup007 and used with permission of the author. All other rights reserved by the author.

The Clean Coder Chapter 7 & 8

Chapter 7:

This chapter is mainly based around the idea that communication is key and is necessary for a developer have, not just their ability to develop. It is very difficult to keep up with what you think the business side of developing would want and what they actually want or think you are doing. With that in mind, the programmers can only make what they Think is wanted from them, and so this process is filled with errors. It also talks about how not only developers, but also business have a problem with their premature precision. Both sides, business and developer usually want to know an estimate of what people are going to get and what you are supposed to deliver to give an exact estimate of how long the process should take, but this task is nearly impossible. Also the outcomes of a product usually end up being different from how it was planned on paper simply because it doesn’t always come out how you imagine or plan it to. What helps this ambiguity sometimes is acceptance tests. Acceptance tests are tests written in a collaboration of stakeholders and programmers in order to define when the requirement is done. This all helped me realize and look back at times that ambiguity could have led to some miscommunication in the group which effected a person to think that they were done with their work, when they were not. So using acceptance tests would help by making it all much more clear than before and help define the context of the problem in precision and communicate its context clearly.

Chapter 8:

This chapter teaches about the fact that writing unit and acceptance tests is good but not enough, what you really need is to have good testing strategies. Even though the company you work at might have its own QA group, you should not use them to find your bugs, your goal should be to eliminate any bugs that could be present in your code, before it even gets into QA hands. They should be working together with you and your team to try to make sure the high quality set for the system is actually reached. Now even though your goal is to try as hard as you can that no bugs should slip through, that is plain impossible and that is the whole reason the QA group is there, to help you catch the bugs you missed. I also learned that QA work with business and make automated acceptance tests that establish the true specifications and requirements document for the system. While the business updates and gives their requirements, the QA then turn that information into tests for the developers.  This also showed me that the QA group is there to use testing to see the true behavior of the running system and report it back to the developers and business, not interpret the requirements.

From the blog CS@worcester – CS Blog by Gautam by csblogbyg and used with permission of the author. All other rights reserved by the author.

Week : The Clean Coder, Ch. 7 & 8

Chapters 7 and 8 of The Clean Coder are about testing. Chapter 7 is about acceptance testing and chapter 8 is about testing strategies. Acceptance tests are tests that are written by the developers and end users together. The aim of these tests is to agree upon what it means to be done. The author speaks about defining done. The author “Professional developers have a single definition of done: Done means done.Done means all code written, all tests pass, QA and the stakeholders have accepted. Done.” I personally like this attitude. If a development team is not upfront about what it means to be done it can lead to confusion, an incomplete product, or a missed deadline. When a team member says that the task they were working on is done the other members should be able trust that it is done and does not need to looked over by others. This is a common problem in group assignment in school. A project may be broken up in to individual tasks and on person is responsible for putting the final pieces together and submitting. To often the person responsible for the final submission assembles all the pieces only to find out some of those pieces are really not complete, they then frantically work to finish and submit the project.

In chapter the author makes the statement ” QA should find nothing”. I know, as the author also pointed out, this is an asymptote, there is a reason the company has a QA team. That being said, I like the attitude the statement conveys, developers should take pride in their work and aim to produce good, clean code that is as close to error free as possible. A developer should never say “Don’t worry, QA will catch it.”

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.