What I learned in my career so far (part 1)

I am in interesting point in my career. I have recently resigned on my position in company I have been with for 6 years and accepted an offer from another company.

It was very difficult decision, because I like my job, the people and the team. And I am also one of those people who get very personally attached to their work - the product is "my product". However, I felt like I have to do it. I have learned some very valuable lessons here, but I felt that if I want to continue growing, changing jobs would be a good step. I also didn't want to not give new experiences and potentials a chance just because I am comfortable in my job right now. I decided to take the leap and see. As I am transferring to my new job right now, it gave me some time to reflect on the past 6 years. I will try to list some of them here.

QA guardians won't save it

When I started, I was in organization where there was a big, organization-wide QA / Development structure. QA turnover was normal practice and the software was ridden with bugs. So naturally, I started to feel like the guardian and gatekeeper of quality.

Nowadays, I understand that quality comes from writing the software, not testing it, and the role of a tester is to be present and help prevent problems throughout the development. I learned to work closely with programmers and we developed mutual trust. We leaned together to think about testing first, then coding. I actually do more coaching than testing these days, yet I still feel I contribute to the quality more. The programmers I work with do a lot of testing, and I fully trust them to do a good job. They feel the same amount of responsibility for quality that I feel.

Testing is a craft, requires skill and experience and continuous learning 

I used to think testing is about talent. You either have this special gift to stumble across those bugs, or you don't.

As with many crafts and arts, testing is largely about experience. As a craftsmen, you have to practice and exercise your skills, but also vary your work in order to keep improving - try new things, experiment. Don't do the same thing over and over again, because that is the way you always did it, and it always worked.

Btw, testing is not inferior to programming, nor it is less demanding

Formal test management is mostly a huge waste

There were times on this project where we could not cope with the amount of testing during development combined with all the need for regression testing and hardening before the release. At one point, we thought to solve this by better and more rigid test management. Any guesses what happened? It was such a pain that we of course abandoned it pretty quickly.

Now what we do is exploratory testing, charters, heuristics - lean stuff. I also believe in using techniques such as ATDD and BDD, which provide you with living documentation of the most important business use cases that you product must satisfy (and they are automated, how nice).

Don't automate for sake of automation

I am always terrified when I see a company goal of 100% test automation. What a stupid idea. I learned this lesson the hard way. Never automate to achieve automated test coverage.

I already mentioned I believe in use of ATDD and BDD. That is because those practices do much more than automate tests. They provide executable examples of the most important business logic of the product.

Good team is more than star individuals

A team of good, if average, people who work together and communicate will do much better work than one coding or testing super star who works alone. Good communication in the team is absolutely crucial, as is trust.

Testers need to understand the technology and domain

At some point in my career, I may have though of my work as "whatever you will give me, I will test." The problem with that is it leads to a belief, that testers just execute tests. Over the years I learned that is no way enough. 

As a tester, I need to have deep domain knowledge of the product I work with if I hope to uncover anything more than the surface annoyance. Along with that, I also need very good knowledge of the environment where the software exists or potentially could exist.

As a tester, I also I need a very good knowledge of the technologies the product consists of, or interacts with. This includes the programming languages the product is written in. I do believe testers benefit form knowing how to code. Especially, knowing how to code in the language their product is written in.

Testers need to have full access

Testers should always have access to the source code, all development environment and resources, build machines and so on. Testers should always be able to get latest code changes, build it, run it and test the product - at any given time. Having this available allows testers to provide feedback very early, early enough to influence the ongoing development and prevent many problems.

I called this post "part 1". That is because as I embark on the my new journey I expect to evolve and and learn more, or change my opinions.

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.