Monthly Archives: February 2017

The Clean Coder Chapters 7 & 8

Definition of “Done”, Acceptance Testing are both built off of communication. This is key when trying to convey your programming needs to a developer or vice versa. The definition of Done in my opinion and in what the author presented us is a moral of “Done” means many things to many people and it is important to establish your system/meaning of “Done”.

The next big topic was Agreement Testing. From personal experience I know how in a corporate environment the managers may not know exactly what they want until you build what they ask for. Then as the author tries to emphasis that they will always have changes. This is said to be because now they how more information on how it looks and what they can perceive to be most efficient. Also Agreement Tests are NOT Unit Tests…..its explained pretty clear that the access points for execution are expected to be different for a Agreement test. This also is where he went into a useful tangent to point out that the underlying framework for your GUI should be consistent but the GUI layout itself can change fluidly.

Chapter 8 discussed more about testing.Of course I think this author has unrealistic benchmarks yet they are great to strive for. He seems very stern in the words used to state Quality Assurance should find nothing. This is a topic we discussed in depth in our last semester course on integration testing, unit testing, what defines a unit etc.Yet the important point he stresses is that unit tests are for the programmers. The component tests are for the Agreement Test, and the integration testing is for large systems when piecing many components together, and the System test is where the entire program is tested from an outside perspective that is all works as one system.

From the blog CSWSU – Triforce Code| Exploring and Learning by CSWSU – Triforce Code| Exploring and Learning and used with permission of the author. All other rights reserved by the author.

The Clean Coder Ch. 7 and Ch. 8

If you were feeling a void in your heart for some more testing since chapter 5’s lesson on TDD, then chapters 7 and 8 are sure to get that blood pumping organ to swell.  Chapter 7 is called “Acceptance Testing” and focuses on how to determine when a programmer has completed a requirement.  Chapter 8 is called “Testing Strategies” and focuses on the “The Test Automation Pyramid” which I provided below.

Screen Shot 2017-02-14 at 12.23.36 PM.png

In chapter 7, Robert C. Martin gives his “Definition of Done” which is accomplished when “all code is written, all tests pass, QA and the stakeholders have accepted.”  Just today our development team drafted our own Definition of Done.  Ours contains slightly different criteria as we are not engaging in TDD.  Additionally, due to our constraints, do not have the time or resources in order to produce automated acceptance tests as Martin suggests.  He focuses immensely on how integration testing through a continuous integration system is the best form of communication between programmers and stakeholders.

In chapter 8 Martin focuses on test coverage.  He believes that unit tests should cover 100% of a programmer’s code, although he admits that 100% coverage is unrealistic.  He also suggests component tests should cover about 50%, integration tests about 20%, and so forth.  Martin suggested, once again, that he believes that QA should find nothing wrong with the software that they are reviewing.  However, in this and the previous chapters, he explains that QA has the responsibility of writing the acceptance tests in conjunction with the stakeholders.  Therefore, if QA does a good enough job, and programmers ensure that their code passes these tests, then I finally agree with Martin. There exists a slim possibility that programmers can ship code to QA with some confidence that there exists no bugs in the code.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Week 4 (2/7 – 2/13) Clean Coder Ch. 7 & 8

When I decided that I wanted to become a programmer, I thought it would be 99% program code and 1% test code. I thought I could mindlessly write as much code as I wanted and just know if it works or not by running it. I was wrong. Completely wrong. After having more insight into being a software developer, I realize now that testing is so under-rated and overlooked. After reading chapters 7 and 8, this concept is reinforced even more.

If you really think about it, its quite simple. You want your program to work and the only way to know if it correctly works or not is to test it. This is where acceptance testing comes into play to tell you when a requirement is done and that is obviously important because if you don’t know the requirements then how would you even know what to test?

Chapter 8 was somewhat broad since it covers a big array of topics regarding which tests to use depending on which level of the system you are working on but nonetheless it was good review. It’s always good to review testing strategies because at the end of the day, your program is only as good as your tests are. 

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

The Clean Coder Chapters 7 & 8

Most of chapter 7  and 8 were things I had already learned from the previous testing class that I had taken. He goes over that unit tests are different than acceptance test, always try to make automated tests because they are cheaper, and all the different types of testing their are and what each one of them covers in the system.
The main thing that I took away from this chapter was that you, as a developer, should make sure that clear communication is established between your team and the stakeholders that you’re working with. Primarily you don’t ever want to assume that the other party knows what you are talking about, or that you are on the same page.  These assumptions can, and usually will, lead to huge messes down the line that may result in your team having to fix the entire design of an application that you were building because you misunderstood critical information that the client was ambiguous on. So, moral of the chapter, never be afraid to ask question and bring in people that may help to clarify the story that the client gives you.
I did also find the small section on testing GUIs interesting. Martin points out that you should not test the GUI itself, but the under lying structure by designing they system to treat it like an API. This makes perfect sense when you think about it because a GUI will always be changing to whatever the clients preference is.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

Capstone Week 3

This week in capstone, we dig deeper in the OpenMRS project.

The steps we did this week

  1. Forked the openMRS git repo
  2. Got ng2-amrs to build and run
  3. Installed ng2-amrs standalone back end
  4. Looked over how the ng2-amrs authentication system worked

People initially had issues with setting up the system. This was actually an issue with multiple OS. People where using OS bash, Node.JS terminal, Bash on W10, and Git Bash. People were confused on what to use at first and we had to clear that situation up and also the different IDE people were using.

We tried to get an understanding of how the entire system works. Initially we set up the front end of the system but was confused on how we get the login system to work (the back end system). It wasn’t until some noticed that there is a standalone that is needed for the back end system that we realize that is actually where we auth.

Although we got everything to work in the end, the steps could’ve been made smoother if everyone was using the same OS and IDE so there’s no differentiating the set up process. Obviously this is much harder to do in a school environment, but having to trouble many different IDE and OS set up can be very stressful especially if a much more complicated project comes up.

Also people speaking up in a team environment is also key, not realizing we needed a back end, we fumbled around confused on how they got auth to work. Until one person spoke up about the back end and then we got confirmations from outside the team on how the entire thing worked.

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

Cleaner Code Chapter 7-8

In Chapter 7 of Clean Coder, the book talked about communication and situations such as premature precision and specifying interface. In my opinion, the most important thing is communication bar none. I have faced situations like described in the book where Business side wanted exactly this but it wasn’t possible due to technical issues. There were also cases where there are multiple departments that want different things, where you end up having conflicting reports on what to do.

Many time in those experience, you end up either doing extra work that was not necessary at best, and at worst missing a key feature that the client really wants. You end up wasting time on features not needed and then crunching before the deadline to get what is needed done. It is imperative to get the full communication down and get everyone on board. The acceptance test, or QA is important here since it serve as an end goal and checklist to get the details and specifications right.

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

The Clean Coder: Chapter 7 & 8

This week in the Clean Coder I read chapters 7 and 8. These chapters covered a lot about testing. Acceptance testing and testing strategies to be specific. One of the more interesting topics that was talked about was estimates. This is an interesting topic to me because a few months back I listened to an interesting podcast on the same exact topic. Now Uncle Bob didn’t go into as much details here as did Steve McConnell on the podcast but he made the most important point:

Professional developers understand that estimates can, and should, be made
based on low precision requirements, and recognize that those estimates are
estimates.

The later-half of that quote is the important part. The statement that estimates are estimates is important. A lot of the time estimates are taken as absolute fact in industry and unfortunately this has become poor practice. Once we remember that estimates are estimates then we start taking uncertainty back into account and everyone is happier for it.

In chapter 8 Uncle Bob began talking about testing strategies. The first point he decided to hit was actually a reiteration of something he said in an earlier chapter, “QA Should Find Nothing”. My understanding initially is that as a developer you should make sure QA has NO role. However, this is not the case. The issue here was my view on the role of the QA engineers. I assumed that their job was to catch the bugs I missed. This is wrong. According to Uncle Bob their role should consist of creating automated acceptance tests and characterizing the true  behavior of an application.

The rest of chapter 8 continues to talk about the different types or stages of automated testing. These are things like; unit testing, component testing, integration testing, system testing and exploratory testing. These are all things I’ve talked about in previous blog posts so I won’t spend too much time talking about them. I do however, want to note one thing Uncle Bob mentioned,

Unit tests provide as close to 100% coverage as is practical. Generally this
number should be somewhere in the 90s. And it should be true coverage as
opposed to false tests that execute code without asserting its behavior.

It’s interesting that when he talks about code coverage he makes it a point to say that our tests should assert something about >90% of the code we’ve written.

That’s all for this week. I look forward to the next week’s chapters which talk about Management and go into more depth about Estimations!!

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

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.

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.

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.