Monthly Archives: February 2017

Clean Coder Chapters 7 and 8

Chapter 7 Acceptance Testing
Chapter 7 hit home for me in ways unrelated to programming as a lot of stuff seems to be for me lately. It seems no matter the jobs I have done, there seems to be a lot of similarity between them. I am probably only going to hit on a few points that struck me in this chapter. The first was his co-worker wanting him to show him how to script something and Bob ended up writing the whole thing calling himself the tool while his co-worker was the sculptor who had soon lost interest or realized that what he initially wanted to do himself was actually harder than presumed. I find that this has happened to me in the past and I have been on both sides, the sculptor and the tool. I t is pretty cool to me how different areas of expertise seem to have similar issues, just different ways of solving them is all, a different tool set if you like.
His take on premature precision is spot on as well. I like how he put it it, “Business people want to know exactly what they are going to get before they authorize a project. Developers want to know exactly what they are supposed to deliver before they estimate the project. Both sides want a precision that simply cannot be achieved, and are often willing to waste a fortune trying to attain it.” That is beautiful and 100% true. Everything always looks better on paper as he says and once the final product is out there is usually some well I wasn’t really expecting this or that or I thought that it was suppose to be or do this. I do like his take on low precision requirements for estimates as that is exactly what they are estimates and to include error bars with them. I think there should be no surprises when writing up an estimate or planning out work for a customer or boss and that things should be made as clear as possible. It isn’t 100% perfect, but what is?
The Definition of Done is another good one. What exactly is done and how do you define it? I like his answer, “all code written, all tests pass, QA and the stakeholders have accepted. Done.”. That is for sure a good definition of done, but I think that done can be defined in many ways depending upon the project you are working on. It could be all steps are done for an iteration or a portion of said iteration possibly and I believe that each team or work environment should make their own definition of done with the possibility of even modifying it if need be.
I think out of all of the chapters so far this one has given me the most value as I think that a lot of this I will end up putting to practice in some way or another. Automating acceptance tests to save time is crucial and to facilitate communications between both parties and how to eliminate communication errors. It isn’t always going to work in all cases but I think there is a lot to learn here for me.
Chapter 8 Testing Strategies

I am not going to ramble on about every detail here as I think this has been covered and will continue to be covered until it is second nature I would hope anyhow. It seems like TDD is the way these days, at least for some and I agree that it is extremely, if not the most important part of the job. I understand that the code has to be written but if it doesn’t perform like it should then what good is it. I think the parts about QA should find nothing are great and that if they do it should be an extreme surprise. That means you did your job. I think or hope where ever I end up landing a job that they put a good amount of time and effort into testing. I really don’t have much experience in testing as the pyramid is laid out, I have only really done unit testing on a microscale basis, but for sure can see the benefits as you move up the pyramid. I thought the “Bug Hunt” day was a pretty cool way of testing the product as it gives everyone incentive to find bugs and ensure that the software is performing to standards.  

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

The Clean Coder 7 & 8 Week 4

Acceptance testing is discussed in the first part of the reading. This is a broad subject that can be looked at different ways. Some ways this testing can be done is by having someone help you write that tests that doesn’t know how to code the tests. Also when estimating when tests will be complete, it is very hard and should not be given an exact date, but a large time frame. When a test is acceptable it means it is done, fully and completely done.

Different testing strategies are then looked at. The QA team should not find any bugs, but they usually will and are a large part of the testing process. Unit tests are the most broad and cover the most about of code, these tests are mainly for the programmers. Integration tests take component tests and make one big test from them. System tests are automated and we can set them and forget them for the most part, but they cover a very small amount of test in the program as a whole.

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

The Clean Coder (Week 4)

This blog post will consist of chapters 7 and 8.

Chapter 7 talks about how communication and avoiding communication errors between stakeholders and developers is imperative to the success of a project. The author emphasizes that the most effective approach to avoid miscommunication is to write automated acceptance testing.

Personally, I’ve never written tests for a corporation, but I have some experience with writing tests for small projects at my University. The tests that I wrote, were for a project that we had to work individually on, so there was never a time that miscommunication would occur.

Chapter 8 discusses all of the different testing strategies and how the most important goal for a development team is to have the quality assurance team find no bugs when they sift through the vast amounts of code. QA teams are important for a software, because without them, there will be plenty of bugs that weren’t discovered and this will effect the quality of the software dramatically.

 

 

From the blog CS@Worcester – My Blog by justcodeit94 and used with permission of the author. All other rights reserved by the author.

How to start EMR on AWS

NOTES FROM USING SPARK in the HADOOP ECOSYSTEM by Rick Morrow Starting EMR on AWS Objective In this lab, you’ll use Amazon Web Services to set up a 3 node Elastic MapReduce (EMR) cluster which you can then use for … Continue reading →

From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.

The Clean Coder, Chapters 7 & 8 Week 3 (2/14/17)

Chapter 7 of Clean Coders covers pretty much the scenario of both the developer and the business having different expectations or requirements where communication emphasizes clarity on what both sides want and expect to have. Other than that, the chapter also covers the concept of acceptance testing and how the author properly defines the term acceptance testing as “tests written by collaboration of the stakeholders and the programmers in order to define when a requirement is done”. While defining what done actually means, the author states that acceptance tests get the stakeholders, businesses and the programmer all on the same page since they all will know what the behavior of the program is going to be. Other than that the author talk about how the advantages of acceptance testing being automated is an advantage toward cost.

While personally I have never written tests that were automated before or even wrote programs for a business, i can not relate about having clients and working on their projects for them as well as the communication part. To be fair, I am programming in a team at the moment so I may get some kind of experience with that now but I do not know if we will be doing any automated testing.

Chapter 8 of  Clean Coders covers the aspect of having testing strategies. The big tip that the author notes is that the QA team should find nothing wrong when testing the developer’s software, and when they do find something developers may freak out about it. While the QA’s job is to find bugs, the testing strategies used by developers to make sure QA does not find any can include the test automation pyramid. The author takes time to describe this test pyramid as an effective way to test software. The automation pyramid includes (top to bottom) “M exploratory, System Tests, Integration Tests, Component Tests, and Unit Tests.

Personally I think its a challenge if developers have to be absolutely sure they flushed out all the bugs. If they do, then either QA isn’t trying hard enough to find bugs or they are missing some. While I commend there being requirements for developers to take part in to help make their code bug-free, I can highly doubt they can find and terminate all the bugs by themselves. I have not heard of a company that has a QA team that did not find any bugs at all because the developers were too good at debugging it themselves. Then again with the automation pyramid and other testing strategies, I could be wrong but I’m not ready to accept a world where QA people barely need to do anything and are considered non-useful.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

Week 4: Reflections on Learning & Work Products

This past week I have managed to get the openMRS code up and stably running.  I began trying to run this by doing exactly what I did for the tutorial I completed last week.  When I realized that wasn’t work I decided to ask my teammates what they did.  Turns out there was a file called, “Read Me” on the git hub repository.  This file gave in-depth instructions on how exactly to run the code.  This was very helpful and taught me to look for that type of file first when encountering a problem with running unfamiliar code.  I have began to create a new login page at this point in time.  As I started to try to do so I was very confused with how I would do this.  I decided to take a step back and read up on some more Angular 2 stuff, focusing mostly on the structure of how you are supposed to code in this language.  This sprint I plan to successfully create the login page and then go on from there.  I still don’t have too good of an understanding of Angular 2 so I am going to try and understand everything I am doing when making the login page, rather then just doing it so it works but not really understanding what I’m doing.  Last week when I was doing the tour of heroes tutorial I didn’t always pay attention and understand what I was doing.  I was kind of just following the tutorial so it worked, which wasn’t the right way to go about it.  I should have been paying more attention to the things I was typing and not just copying down what it said to.  This week I will take that lesson and focus on learning the language as well as consciously getting the program to work.

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 & 8

Chapter 7 covers the topic of acceptance testing. This kind of testing is usually a collaborative effort between the stakeholders and the developers to define the definition of a requirement being done. By using acceptance tests, you can help avoid what the author refers to as the “premature precision trap.” Basically either the stakeholder or developer or even both is too specific which causes irrelevant requirements. By properly conducting acceptance tests a project becomes clear, precise, and it promotes communication. As a professional developer there are several key responsibilities in the acceptance test process. First, it’s the developer’s job to remove any ambiguity from what the stakeholder is asking for. Second the developer should always express an error bar when determining time tables with a stakeholder to prevent estimation anxiety.  Lastly, the developer’s role is to connect the acceptance tests to the system to make it pass. Not to create the acceptance tests. The author clearly separates acceptance tests from unit tests. An acceptance test doesn’t care about underlying code but more that a system is behaving like it should from the businesses point of view. Furthermore acceptance tests should run several times a day in a continuous integration system and they should always pass. These tests should also always be automated as manual testing is much too costly. In summary, acceptance tests are mandatory for a professional and increase efficiency between stakeholder and developer.

After reading chapter 7 there’s some important points to remember. However, seeing as I’m not working with stakeholders in a working environment yet there’s not too much from this chapter I can directly apply to my programming right now. I thought one important point was to always estimate with a margin of error. By giving an exact completion date you don’t leave room for setbacks that are bound to happen. Also I will have to remember that it is not the developer’s role to write these acceptance tests. If I come across a test that doesn’t make sense instead of trying to re-write or discard the test, it’s best practice to negotiate with the author for a better test. Moving forward I will keep acceptance tests in mind however it will be some time before I can directly apply the lessons from this chapter.

Chapter 8 covers the topic of testing strategies. The goal of any testing strategy should be that QA finds nothing when they examine a program. In order to come as close to this as possible the developers and QA members need to work closely and follow a hierarchy of tests. By following the Test Automation Pyramid the author lays out, development teams can achieve this goal. The bottom layer consists of unit tests. These test the low level specifications and underlying code. Next are the component tests. These are “happy path” tests written by QA and business with help from the developers. Businesses should be able to interpret and understand these tests. Next are the integration tests. These test the communication of component groups and make sure they communicate properly. Next are the systems tests. These execute against the entire integrated system and make sure the full assembly of components is connected. Lastly the top of the pyramid consists of manual exploratory tests. This involves human testing to seek out odd behavior and ensure normal behavior of the system. This kind of testing is unscripted. By following a hierarchy of tests like this, professional development teams are following best practice of Test Driven Development.

After reading chapter 8 I understand the concept of the testing hierarchy but some specific examples at each level would have been nice. The concepts in this chapter will be better applied when I am on an actual development team. It will be interesting to see if my team uses a similar testing strategy. I think the author places a lot of faith in development teams that they will have the communication and discipline to follow this pyramid forcefully. In a smaller company it may not be so easy to break down these testing levels into such clear guidelines. I do think it’s important to remember the manual exploratory testing. While the computer can tell you everything is working properly you never know for sure until you’ve actually tested and observed the system as a user. In summary, I will keep testing strategies in mind as a professional developer and am eager to see what strategies are truly being implemented in the field.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

The Clean Coder, Chapter 7 & 8 (Week 4)

Chapter 7 of the book is about the importance of communication and how to avoid communication errors between stakeholders and developers. According to the author the only way to effectively eliminate communication errors is to write automated acceptance tests.

Chapter 8 of the clean coder book is about testing strategies. According to the author, the goal of the development team is that the QA team finds no bugs. The development team should react with horror(it should not be something they expect) every time QA finds a bug and must take steps to prevent them in the future.

I think the whole point of this strategy is to force the development team to write clean code rather than write bad code and push them to QA, which will ultimately cost time and money since the development team will have to fix the bugs once QA finds them.

The rest of the chapter is unit tests, component tests, integration tests, system tests, manual tests and exploratory tests. Things we learnt in CS443.

Both of these chapters discuss scenarios which I have not yet faced; so I can’t give any opinions or past experiences.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

The Clean Coder 5 & 6 Week 3

The first part of the reading was about a topic I am well aware of by now. Test Driven Development is discussed and why we should all be using it. I have used TDD many times when coding and the benefits are clear, it may seem like you are doing more work than you should be, but at the end of the day you know your code is clean and almost bug free. It goes on to say that TDD should no longer be argued about using, it should be used without argument. There are no downsides that are large enough to prevent a programmer from using a TDD approach.

The second half of the reading was pretty straight forward, you should always be practicing. It doesn’t matter how long you’ve been programming you can always improve, you can practice to write code faster, learn a new language, write certain algorithms with ease. When it comes to TDD, just knowing exactly where the keys are to write your test can help reduce programming time dramatically. Most if not all practice should be done on your own time, so you become a more valuable employee over time.

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

Week 3: Reflection

This blog will be a little different this week, as a class we have switch to writing a reflection blog at the end of each Scrum sprint instead of every week. Our first sprint ended last Thursday and we held the sprint review. The overall sprint went well and there was good participation. It was a little different as each task on the backlog was to be completed by each member for themselves. We have though found a way using Trello to handle the tasks that must be completed be all members. We start off with the task in the sprint backlog with all members added to it. When the first person starts the task the copy the task to doing, add their name to the new task, and remove their name from the to sprint backlog card. Each additional member updates what cards they are members of as they work. Once the last person has removed their name from a card it is removed. This process is the same for going from doing to done.

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