Who wants to be a tester?

Recently, I read a couple of posts with similar themes and a lot of them along the lines of "testers are failed programmers" discussion. Here is one of them that stuck the most - 5 Things a Beginner Developer (and Tester) Should Know About Software Testing by Bhumika Mehta.

First part of the post talks about some common reasons people don't want to become testers, or why they think testing is lesser to programming. It didn't surprise me, yet I was bit upset by it. Then I thought about how I got into software testing, and I realized something shocking thing:

I may be a failed programmer!

I admit, it's a little oversimplified statement. When I joined my first job, I didn't really know much about what position I was interviewed for. I just wanted to work in IT. I had no idea what I want to do but I knew I would enjoy programming. I had some very basic programming experience (if you can even consider collage programming any kind of programming experience, since I didn't really study programming).

I went through 2 months of training including some programming (specific to mainframe for this particular job). The training program included a series of tests, and a final test. I did pretty good in all of them. After I passed the training, I was finally assigned to a team - as a Quality Assurance.

I was really sad.

Why?

I did well in the training, didn't I?

So I will be pointing out errors in somebody's work? I will be telling them they did it wrong and their code is bad? How will they take it? How will I take it?

Surely everyone will hate me. I would really rather be a programmer.

Looking back, I am really glad I didn't qualify for a programmer back then. Not being one opened many opportunities for me which I could have missed if I just concentrated on writing code.

I didn't want to be the hated person, the failed programmer, the lesser of the roles. So I was doing all that I could to prove my usefulness. I concentrated on being useful and helpful team member rather than pain in the butt.

I learned how to look at things differently, see things programmers could not see, understand things in context, ask the good questions, understand the domain, communicate with stakeholders, and also, communicate with programmers in a way that the information I obtained through testing was useful to them rather than annoying. I have to admit, I was probably over compensating for feeling lesser.

I would have probably become a very average (if not worse) programmer. I am confident I became better tester and I bring more value as a tester today.

So what is the take away from this ramble? Don't let anyone tell you that testers are a failure, and even if you did come the the profession the way I did, don't let it discourage you.

It is sad that even now I see tester being treated as lesser, but even worse is when I see testers treating themselves as lesser kind. Of course testers often don't have that much coding knowledge (some have none). Their value is elsewhere - it may be in areas where very strong programmers don't excel, and that's why it's good to have them on board.


BTW, when someone asks me what I do, I answer that I am a software developer. Because I am, and all of you, testers, are as well.

Quality is Shared Responsibility

I'd like to share my thoughts on why I don't like to use the term QA as a role and the gatekeeper of quality and why I believe everyone is a developer in agile software development.

Where does quality come from?

Back when I started as a QA engineer around 2008, the agile movement was just starting to take root and people believed that testing performed by QA engineers assures, or even increases quality of the software.

Not really.

Quality is created by people who write the software, not by testing. Testing can provide information to assess quality and allow decisions and actions to be taken to reduce risks and increase quality. But it doesn't create it. Since the only way to have good software is to write good software, so quality is in the hands of the developers.

One of the problems with having dedicated QA is that it creates environment in which responsibility for quality is taken away form people who write the software and transferred to someone else. 

Whole team to the rescue

Quality needs to be built in, you can't add it externally. The developers are the only ones who can do that, so they should be responsible for the quality, right?

Yes.

Does it mean that developers, aside form writing all the code, also need to test it all? 

Of course not.

In a truly cross functional team, everybody is a developer, and everybody is also a tester. While they all share the same responsibility for quality, each team member uses their unique skills to bring value to the team.

Let me clarify that a bit. When I say everybody is a developer, I mean that everybody uses their skills to develop the software, whether it means writing code, communicating with customers, testing user interface, or doing exploratory testing and feeding information back to the code. They all contribute to development of the product, so they are all developers. And of course they all test the product too, how else would they know if it works.


Do you agree? Do you disagree? 
Please give me feedback.

Thank You.

What I Have Discovered on ATD2014

I just returned form Agile Testing Days 2014 and I am full of emotions. It's been awesome. And exhausting. There were many great experiences. Here are 10 of my most important takeaways this year.

1. Fail fast and often
Use failure to learn quickly, build T-shaped skills ... and steal, pillage and plunder knowledge wherever you can (as Alan Richardson's nicely said in his keynote).


2. Visualize everything
Super important topic throughout the conference.

Shachar Schiff's keynote highlighted the brain's natural wiring towards processing visual information (60k faster o_O).

Janet Gregory gave us a nice example of visualizing technical debt as a pirate ship during one of the Lean Coffee sessions.

Oana Juncu lead Demo-Driven Development workshop, which is another interesting and very visual technique.


3. Lean coffee with lean people
Once again, I loved it. The morning Lean Coffee sessions have the best concentration of great people.


4. Acceptance Testing is poetry
I attended David Evans's Specification By Example workshop, which gave me renewed perspective on importance of communication around acceptance tests and how poor communication leads to bad products. On the workshop, we had chance to fail fast and learn because our product failed 100% of acceptance tests.

I learned to avoid "magic" in the examples. Also to use different examples to illustrate different behavior on specific examples to highlight important facts.

Later I attended George Dinwiddie's session called A Poet’s Guide To Automated Testing. This was one of the highlights for me in terms of takeaways. I learned about the importance of expressibility of language used for automated acceptance tests.

Don't create epics, they are too difficult to understand. Make it as clean and expressive as possible, be picky if you must. Include all details that matter, but none that don't matter. Don't use "I" - what is that the system should do when a concrete user uses it? Define your roles. Highlight the cause and effect ...


5. There are no Testers (there are only developers)
I know for long time now that developers and testers benefit most working together as a team. Now I am even more convinced the distinction between tester and developer should not exist. It does not make sense. Don't we all develop the product, using different alignment of our T skills range?


6. No longer in a box
I reject the name QA for long time. Rejected it before Alan Richardson's keynote. Many others have too, judging by the strong audience response.

So I labeled myself a Tester, for the sake of playing a role.

Now that I have been writing production code ... how do I label myself now?

Antony Marcano's keynote was very inspiring one.

No labels, it's what I do that defines me.


7. Building a car was awsome
I attended two sprints of the extreme manufacturing event. Our scrum team picked a story about building a part of the car for which the schematics were lost, and it turned out to be impossible to build. But that doesn't matter, we failed but we learned form it. The first sprint was unbelievably hard. That made it easier to see how the second one improved.

Also, Joe Justice's keynote was simply inspiring. And of course awesome.


8. The Antimatter Principle
Attend to folks needs to improve the world.


9. Where is my LEGO box?
I didn't attend any of the LEGO sessions. But I do want to find and bring my own LEGO box back!

Also, I loved the idea of having LEGO avatar. I will create one for myself.


10. I have stuff to share
It's been very delightful for me to see that on few occasions, people thought conversation with me was useful.

So, see you next year!

Hello, my name is Monika

I am a regular person, a tester by profession, currently working in a big international software company. I like my job, and I am passionate about it.

I want to start a blog for some time. But why? There are hundreds or rather thousands of testing blogs on the Internet. Why start a new one? What makes mine special, worth writing, and worth reading? It's simple ...

I care about my professional and personal growth. Joining as a junior tester 6 years ago, I have been steadily growing within my company, but I have reached point in my career as a tester where I realized that if I want to grow, I have to venture out in the testing world and explore on my own. And if I want to help my team to grow, I must start bringing my discoveries back to my team. I realized I cannot be a lone tester hoping to figure out all the testing wisdom on my own, but I need to seek for guidance and wisdom in the community. And to sustain my growth, I have to become part of the community, at at some point, also give back to the community.

Hereby, I set the following goals for myself:

Expand my knowledge by exploring the testing world
Become active member and promote myself within testing community
Share useful information with the testing community

I am hoping a blog will help me me achieve these goals, and maybe at some point will also become valuable for people like me.

So what have I done so far? Obviously I started a blog :). I also registered a Twitter account after my visit at Agile Testing Days 2013 (a year ago). I only started tweeting this month though! I never could get a good hang of social sites, so for me this is quite a challenge. You can reach me @monikaprotivova.

I wanted to say don't care if anyone reads my blog, but that would be an ugly lie. I do care a lot! I want it to become trusted and respected source of good information, one day.

So if you do stumble upon my blog, please give me feedback, I'd really appreciate it.

~Moni

Drifting In Space: what's behing the name?

Drifting is a directional movement, which can be both controlled and uncontrolled. This thought relaxes me.

Because space is wast, open, and unexplored and I am sure it is full surprises, dangers and awesome discoveries. This thought excites me.