Must programmers know how to Test?

I was never asked before if a programmer should know how to test. The underlying assumption is that programmers know hoe to test their own work, and therefore are skilled at testing. Problem is that they are not. And the sad thing is that so far they have managed to get away with it. I’ve been a professional programmer(that is writing code for a living) for more than 10 years, in all the places I’ve worked my managers did ask me if I tested my work. And my answer was always “of course”.  But never was I actually challenged on that. No matter how many bugs were found in my code, no matter how much empirical proof there was that I did a bad job at testing. None of my technical managers ever told me, “please take this work back and test it again, and this time for real”, ever. And never have I seen it happen to any of the other programmer I worked with. I did get work back from time to time with claims that some of the functionality was missing, I did get a lot of bugs to fix. At times it was so bad that my “testing” activity usually only included making sure it compiled executed and didn’t crash on my machine. and that what I called testing.

Programmer who Cant test will become obsolete

As automation gains more hold in our industry people start to expect much more from testing at the unit level. In my last work place doing test reviews was part of our on going process, in fact we probably invested more time in reviewing test code than actual production code. For us it was extremely important to make sure that written code was properly tested (verified) at the unit test level. I expect this is very common to all software teams doing TDD. And while I’m sure many of us just wait  for this weird TDD notion to go away. its my strong believe that it wont. on the contrary latest surveys suggest that as agile is gaining in our industry the necessary engineering practices are also

Programmer – catch up on your testing skills

if you as a programmer want to stay relevant in future markets, you should really start increasing their testing skills. Yes there is still time before testing skill will be listed as one of the mandatory skills in job posting. The growing need for writing automation at all levels, gives a definite advantage (at least in my book) to programmer that has some sort of formal knowledge or experience in testing. (and yes I will need to see some actual proof and will verify such claims during interviews). No I don’t think a programmer should be a professional tester as well (although that might help), but basic concepts of QA, properly designing test suites and understanding that there are more than just unit testing is something I would expect every self respecting programmer to know. In  my limited experience I have found that programmers that posses this knowledge and skills are just better programmers.
And if you want to know how to start here’s something you can try: STARTING TDD – ONE DAY EXPERIMENT

Bottom line

As a programmer you should want to know how to properly test your work(at least at the unit level) ,in order to decrease the time you will be looking for a new job

Read more »

Posted in: Agile practices,ATDD,Random Thoughts,TDD

On Various Testing Levels

One of my very first few posts (dates end of 2008) dealt with the premise that One test level is not enough to reach a good qulity product. Then I argued on one hand that Integration tests are not enough, but on the other Unit tests are not enough as well. Only the Power of combining both approaches will truly help make your product successful.

Has anything changed since then?

Since then I had the chance to meet  a lot of great people who taught me a lot about Quality and specifically about testing. I had the chance to meet people like Lisa Crispin which exposed me to the Agile Testing Quadrants, Michael Bolton who taught me the difference between tests and checks and Elisabeth Hendrickson who really showed me that being a good tester takes a lot more than what I imagined.These people also helped me in refining and improving my understanding.
However I still think that relying on a single level of testing will not be an effective strategy.

Checked, Accepted and Explored

I think that I first heard this from Elisabeth Hendrickson:

Every feature (story) developed should be at least “Checked” “Accepted” and explored. Otherwise it is not Done

Checked

For most I use the unit test level to do this. Checked for me means that the code is doing what I think it does. Basically that it will exhibit no unexpected logical error and that the thing I intended it to do when I coded it is indeed what it does.

Accepted

For this I usually try to get as close as I can to E2E. Excluding the GUI. Accepted for me means that the system behave in a useful way. that is the user (or other person) that “ordered” the feature is indeed satisfied that the system behave in what he accept as a good way.

Explored

For this I use manual testing. Explored means that there was a person involved that played around with the system and tried to judge the general quality of the solution. usually there are specific question to answer in this phase, but sometimes this takes the form of free style testing. the goal of this stage is to use the brain power of a tester to see what else can be improved and whether or not the solution is indeed satisfactory.

Is that ALL?

Definitely not!
This is the bare minimum. In many contexts this is not enough. sometimes the system is just too big and needs testing at other levels, there are definitely the non functional requirements that need to be addressed and much more.
However this is a very good place to start. In some projects you can definitely achieve good enough results with only this. And if not, starting with here will give you a strong foundation to base the rest of your test efforts on.

The Twist

But what if were not in an agile context? Well the principles stay the same. I believe that using these 3 simple aspects even when you are not developing an end to end feature will do you good. Even when you are working in an team focusing on a horizontal layer of the product its just a matter of aligning your definition of what is the system under test. Each piece of functionality you deliver still needs to be checked accepted and explored. Its just that the accepted part takes a twist.
Since you are now working on part of the system, most likely your “customer” is not an end user but a fellow developer that needs to either integrate with you work or simply use it. However if you treat him like your customer he can still define his acceptance criteria. Most likely the resulting tests will be at the component (or subsystem) level and will not encompass the entire system. but either way the thing that you deliver will be checked, accepted and explored.

Read more »

Posted in: ATDD,AUT,Development Practices,Engineering Practices,Integration Tests,Unit Tests

Israel Dot NET Developers User Group (IDNDUG)

Next week I’ll be talking at the IDNDUG group meeting about test automation. its going to be quite a long session (about 2 – 2.5 hours) and I will try cover several aspects of test first approaches as they developed over the past few years.
While the session will not be completely technical and will I include some general background, I do intend to dive a little deeper then your regular “Introduction is TDD” session. so if you are planning to come do bring your laptop, we might find some use for it.
for more details and for registration go here

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: ATDD,AUT,Events,TDD

TDD for Legacy Systems

We know test automation is crucial probably even mandatory, and TDD is a great practice to use, but lets face it our existing system is not test friendly to say the least.
so now what?
TDD for Legacy system is  my way to help people tackle this problem. During this two day training we will learn how to cope with existing systems. We will go over the basics of Test First methodologies and learn how to turn a system from a big  chunk of legacy code, into something that is covered by a suite of automated tests. we will discuss issues of setting up a continuous integration server, different type of testing that can be applied, how to tackle existing system design and how to slowly but surely improve our code base while writing automated tests for the existing code.
the training will assume no previous knowledge of test automation, however it is  hands on and does require previous experience in programming (at least one year on a real live system).
if you are interested and want to learn more details about the course syllabus and content can be found here
and of course you can just register here
so don’t wait up, take you r first step and come learn about modern software development.

Read more »

Posted in: ATDD,Course,TDD

Agile Testing Days - ATDD

I went to Berlin for the Agile Testing Days Conference. I’ve join Elisabteth Hendrikson tutorial about ATDD, while is full day tutorial about the basic concepts and technique of doing ATDD. fro me this is a great opportunity to augment my knowledge about best practices tools and idea of how to improve my ATDD skills.

In the first part what really stood out for me is the time we spent about the various silos existing in a typical development environment. Specifically what i liked best is the emphasis Elisabeth puts about the need to break up those silos focusing on only establishing a clear separation between the role of deciding the “What” and the role of building the “How”. she quoted Tobias Mayer which defines in this post these roles as “The What voice” and “The How Tribe”

Read more »

Posted in: ATDD,Conferences