Riding the TDD/BDD Process – Part I

For a long time, I have been reading about TDD, learning various test automation techniques but as an architect, I had very few chances to actually work in a TDD project. So when I recently got a request to help a team, who is going to ride a TDD process in their project, to understand how Microsoft’s technology stack supports TDD, I am far more eager to jump in and see how it goes along with them. On another project where the team had absolutely no experience with test automation, I recently spoke about various benefits of test automation. So here I am between a team with no test automation and a team starting their TDD journey. So in this post and if required few more posts, I am planning to document what I know and what I am going to find out along the way.

Why of Test Automation

Let’s start with Why. Today in most of the IT services companies developers say that they are doing unit testing. However most of this unit testing is casual and gut feeling based. Developers believe that their code will not break and that includes me as well. The rigor many times is limited to initial testing. Once that phase is over, they probably test only for the changes. So the first reaction when the tester logs a bug is of disbelief. Then they say it is not their fault, the requirement is not like that and finally after triage they succumb and accept the bug. However somewhere in their mind, they are cursing the testers, frustrated that they have missed the timelines, have to work late hours etc.

When I talk to project teams and tell them that in today’s time there is literally no distinction as a developer and a tester. Each developer must know testing fundamentals and each tester must know enough of development that they can automate test cases, the first reaction is of shock that this is absolutely impractical. A developer doing testing is kind of degradation

However, come to think of this. If you understand that testing the code is required and someone is going to do it, why that other person is not yourself.

Why should you let someone else humiliate by throwing trivial bugs at you and make mockery of your skills?

The benefits of the developer doing unit test automation are enormous. It adds some effort on the development front but it pays every time you make change to your code. I recently came across a small book on unit testing published by Syncfusion called Unit Testing Succintly. The author gives a very detailed analysis of what code should be called as unit and gives examples of the code which cannot be called as unit vis-a-vis same code when refactored turns into small units.So once you divide the code into these small units, you automatically improve the code quality because you can easily follow two principles of coding, DRY (Don’t Repeat Yourself) and SR (Single Responsibility)

The immediate benefit of automated unit testing is improvement in code quality

The other challenge with manual testing is you tend to test less. Less tests and even lesser regression. I really do not want to go why what the quality documents say but the reality is that developers are lazy and manual testing records are really do not backed by strong evidence they are merely trust. There is very limited traceability. This for some people is good because they do not like accountability. The amount of work involved in manual testing and specially regression is why one should really look at test automation. I often see in projects that developers are behind writing least code possible. They spend good amount of time on that. But then they do not consider time required to fix the bugs.

If doing more in less code is sign of intelligence, then spending lesser amount of time on actual testing and regression is also sign of intelligence. Test automation saves you from that ordeal.

Next comes peace of mind. No one likes to spend extra hours in office. A good coverage through test automation gives you confidence that your code is working well.One simple rule for improving test coverage is to add a test case or test data in existing test as soon as you find a bug. This also helps in taking up requirement or design changes. When you change the code, the tests automatically tell you what is broken, so you can either tweek the tests to match the requirement change or fix the code where broken.

The reduced time to identify a bug and increasing resilience of your code is one more reason why you should do automation.

Most often seasoned developers loose their appetite to learn something different other than new improvements in the technologies they work on. In many IT service companies there are two career progression paths. One leading to higher technical roles and other into managing people. Those who believe that their natural progression is in management tend not to learn programming beyond a limit. I have even met folks who told me that they have been developers for 4-5 years now they don’t want to code and they will only review the code. My question is if you are so eager to get into management and learn about it, ready to give PMP exam for that, why not spend a little time on learning testing and implementing it on your code? You learn coding because you want to lead team of developers, will you not be leading testers as well?

Learning test automation will give you an edge even if you plan to go into management. If you are planning to get into higher technical roles it anyway is going to teach you how a good code looks like.

In scenarios like developing for desktop (Windows or Mac) or public facing web sites there is another challenge. When the product is going into hands of general public you are really not in control of what combination of OS version (Major, Service Packs), Browser, runtimes like JVM or .Net they are having. The combination of these you need to test your product on even after rationalization is quite large.

The problem of running and testing your code on all combinations of environments can only be solved by automation including UI automation.

I will stop here as I believe the major reasons here are covered. We will move to when in Part II of the series.

  • Riding the TDD/BDD process – Part II (coming soon)
  • Riding the TDD/BDD process – Part III (coming soon)

Microsoft Surface available for pre order now

Microsoft has announced its pricing for its Surface tablets. 32GB comes at $500 & 64GB comes at $600 and if you want a black touch keyboard with it, add $100 more. The prices are very much comparable with top-level tablets in the market. What you get more is Standard USB socket & HD Video out, stylus, Office RT which comes bundled,

Most Critical Feature

What is critical for me is that the device is MULTI-USER. So my family can use it w/o messing up with my critical data. I find that as an issue when I hand over my iPad to my 5-year-old son. There are few games which allow in-app purchases as well and if things go wrong, you may end up paying for stuff you don’t want. Or the child may launch your mail application and accidentally delete your mails.

The keyboard is a nice & easy addition but I also type in Devnagari script a lot (Marathi & Hindi) for which I find on-screen keyboard very easy and intuitive. I am not sure if the Surface keyboard can display actual characters depending on the keyboard layout.

Model Comparison

Surface has two models to compare. Comparing the specs of RT and Pro versions and being a desktop user for so many years, Pro is definitely compelling as it has both desktop and touch mode. Also on hardware and screen resolution front, it is better. Continue reading “Microsoft Surface available for pre order now”

Big Data will make many sci-fi stories come true

I was reading few links shared by my colleague on the upcoming book “Human Face of Big Data”. While reading these articles I started realizing that where this is heading. Today there are systems which are getting build to analyze human behavior of all sorts. The primary driving factor today is social networking and leveraging this for advertisements and generating funds. However systems are coming in healthcare that analyze basic human behavior to understand warnings of illness, health risks like heart attack or its recurrence. As the technologies are getting built what the computers are learning is how to process unstructured data.

Today a human brain is much better and faster in many ways is because it processes unstructured data of all kinds. Even when you are on a foreign land, you start collecting information and process it. It takes some time to settle down however, the basic programming of the brain is not required to be changed. As we are now developing techniques to get meaningful information out of Big Data, the next obvious step would be to write a generic logic that can process any sort of data and furthermore, get audio, visual, textual, geo-spatial data and process all together by linking all of them in real time.
Continue reading “Big Data will make many sci-fi stories come true”