Saturday, December 19, 2015

Testing with Ansible

IEEE Spectrum has recently posted an article about Yahoo resigning from the QA team. After that maneuver quality of the final product not only didn't degrade but actually improved. Of course, if we delve deeper into the article we will realize that the products got better after continuous delivery introduction (image credit to and the QA team wasn't entirely to blame. However, that's a clear signal to old school testers that programming/scripting skills are now necessary.

Saturday, December 5, 2015

Blog update

Hi there :) 

1. I made a new blog which will focus on testing/quality and IT in general (you are here) 

2. I made new blog where I plan to write all books reviews. 

This solution has a few major advantages for my readers: 
- you can read about which you are interested in, i.e. testing is separated from book reviews 
- you can add me on so you won't even have to open the blogs 
- black letters, white background, and intuitive UI improve user experience 

I hope you like it!

Monday, November 30, 2015

Ideal tester equals 3.141592..

I was reading quite a lot recently about Tester / QA / Software Engineer in Test role in IT. I'd like to continue the discussion which I had started in my previous post - 'Our future as testers'. After publishing this post I came across two very good articles from ThoughtWorks - 'Is QA Dead' and 'QA Role - What Is It Really'. They are definitely worth reading, but I had also found a real gem which you should read ASAP - 'Strategies for Advancing Your Test Career in Today's World'. It's so good that I had even decided not to publish it in my twitter feed. For my blog readers only! 

Different people triggered me to write this post though. It was Janet Gregory and her speech on Agile Automation Days Kraków which took place today. In her presentation, she told us that every tester should be. like Mr. T.

I don't think I can fully agree with this statement though. Of course expert knowledge in one field chosen from Exploratory testing, Security testing, Functional testing (manual or automated), Security Testing, Infrastructure testing (+ DevOps), UX, BA in indeed required to be successful, but there is more of that. This is the second pillar required to lift our careers - social skills. 

Every great tester should collaborate closely with teammates, elicit examples, clarify requirements, ask questions, obtain information, deliver information. Janet pointed out one more thing which is worth mentioning. As testers, we should clearly report how did we do our job, what did we test and what risks did we observe. From my short experience, I can say that most of us (including me) aren't good at that. 

Do you agree that social and technical skills are equally important?

Friday, October 23, 2015

11 Steps to Successfully Manage House Project

I was really busy recently because of my house interior finishing. Somewhere between the seventh phone call and third visit in Ikea, an idea struck me. I got a project manager role similar to our boss's roles in the IT world. As an agile enthusiast, I'd like to share 11 lessons that I learned. 

1. Know what you want. Everything starts with ideas or more formal requirements. Ideally, every single plan you have should be testable (i.e. after it's done you shall be able to clearly answer one simple question: is that what I wanted?). At this point, you don't have to think about how to things. Make sure they're all possible though. 

2. Pick the right people. Recently I read a great blog about how important IT companies recruitment is. After hearing more terrifying stories about workers from my family & colleagues I realized it may be a very important decision. Fortunately, after thorough, I picked right. Look for internally motivated people (see Daniel Pink Drive for details), have 7 Habits of Highly Successive people, and are recommended by someone you trust (if possible). It won't be easy, but it's an investment worth making. 

3. Pay for responsibility, not for things. That's obviously cliche. However, there is a huge difference between hiring multiple teams to do small jobs and one team to do everything. Avoid split responsibility at any cost. Eventually, something will go wrong and you will have to react. Don't waste time looking for culprits. 

4. Do not save on quality. Well, you may say that I'm Quality Assurance Engineer so that's just selfish statement. I believe technical debt has to be paid eventually, so you end up saving nothing. If something exceeds your budget work hard to earn that money. Buying cheap stuff is just a costly workaround. 

5. Focus on the hardest things, do not micromanage. After picking the right people you shouldn't worry about easy/routine tasks. By looking at their hands constantly you'll only make them angry. Spend your entire energy on things that you believe can go wrong (creative/hard stuff) or focus on things you'll do yourself. 

6. Avoid being a proxy. A lot of times you'll end up doing things that involve three parties (you + 2 strangers). Do not waste time speaking to them alone. Arrange conferences or make them call each other. After a few such occasions, I realized why we have standups. Communication is really the key. 

7. Be open to ideas. Someone else may have better ideas. Do not think you are the smartest person in the world :) 

8. Be creative. For some reason, in our society, there is a huge demand for being mediocre, just like everyone else. Do not give up your dreams only because something is extraordinary. Your working team will gladly do even the weirdest things. They can put it into their portfolio. 

9. If you act, act with boldness. That's the statement which you can find in every Robert Greene book. If something is going wrong do not hesitate. Waiting will only make things worse. That's your money, your house (probably for your family). If you react immediately people can't ignore you. Note that the reaction can't be too emotional. Think straight. 

10. Establish a strong posture. Whether you like it or not you are constantly judged by others. In his brilliant Winning Through Intimidation Robert Ringer explains his struggles as an estate broker. He was constantly cheated until he hadn't established something I'll call 'power aura'. Do not naively think you can go to wear shorts and during a t-shirt during business-making without any consequences. 

11. Send weekly reports to the family. What? You had probably asked it. After sending those reports I realized it helped me to keep up with dozens of ongoing problems/tasks/logistics problems. Do it for yourself, and family will enjoy picture updates :)

Thursday, October 8, 2015

Our future as testers

I got inspired to write this post after watching a youtube video 'Humans need not apply'. The author of this rather one-sided video presents many arguments which should convince us that our jobs would soon be taken by robots and automatons. Of course, the points presented are highly exaggerated (typical media piece these days...), but it's always worth considering if our job has a bright future. So do we, as testers/QAs, have something to worry about? 

Let's start with a simple question: why do companies employ a tester? They do it because it's much cheaper to detect and fix bugs found early. They don't really care about quality. They care about customer perceived value. It's worth remembering that even with 99,9% unit test coverage and green seleniums bugs may somehow slip on production. Unfortunately in the social media era, one celebrity tweet with our production bug (btw. Edward Snowden has already 1,41M followers) may quickly ruin us. So in my opinion testers will be needed (+desired +looked for) as long as the cost of production bugs will grow. And I doubt this trend would stop soon. 

On the other hand in our highly competitive society companies need to release new features very quickly. Big teams of testers don't really fit in agile methodologies. Even assuming 3-week sprints new functionalities are usually ready for the manual test at the end of the third week. In such a short time one person is more effective than a team. That's why every tester should focus on programming skills, the transformation to lower-level tests (unit, integration) is necessary. There is no alternative. The test pyramid has to look as above (notice that I included a manual test on top - I still believe its the best form of testing). 

Along with programming, there are other desired testers skills: scripting, UX/UI knowledge, DevOps knowledge, business domain knowledge... I recommend you to specialize in one thing, but keep a close eye on the other. Don't ignore them, because there are people who wouldn't. You don't want to be recruited by your past subordinate. Do you?

Friday, September 25, 2015

System Testing

More than two years ago I was invited to a System Tester job interview in Motorola. As usual, I wanted to prepare as well as possible and by simple googling, I made a surprising discovery. In the world where almost everything has detailed descriptions available for free, there is serious lack of reliable resources about 'system testing'. For example, on Amazon, there is only one sensible hit -> check it. Trust me, by implementing processes described in this book you will end up broken. This means that you can become a bestselling author. Just write a professional and concise book about system testing with lots of practical examples. 

According to ISTQB glossary, system testing is the process of testing an integrated system to verify that it meets specified requirements. That's too general description. In my opinion: 

System testing in the time & budget-limited process which ensures that: 
  • the system meets specified requirements 
  • all system elements integrate correctly making unity 
  • '*ility' levels satisfy all stakeholders 
  • customers can safely use a system 
It's fashionable to analyze what Apple does, so let's check scraps of information we can find online. Before launching iPhone 6 Apple opened the testing center in Cupertino for the press. I managed to find an absolutely fascinating picture-rich article about iPhone testing (click). Unfortunately, those are only hardware tests. If you use Apple products you probably agree that the usability levels are very high. It looks like they hire Human Factor Engineers (click). However, this looks the most interesting (click) - is it iPhone System Tester? Those are job requirements: 
  • Testing of mobile devices and cellular technologies (GSM/GPRS/CDMA/LTE/etc) 
  • Scripting skills in any of the following: Python, Perl, Shell, or JavaScript 
  • Good understanding of SQA methodologies & practices 
  • Comfortable with working on hardware and in supporting engineering in debugging and reproducing user case scenario 
  • Demonstrated ability to own a complete functional area of an application or product 
  • Thrive in a collaborative environment and can clearly communicate while confidently driving multiple projects across many teams 
  • Obsessively passionate and inquisitive, and seek to solve everyday problems in innovative ways 
  • Laser-focused on the smallest details that are meaningful to our customers 
Hopefully one day a brilliant writer will answer millions of system testing questions - how to test a pacemaker? How to test a space shuttle? When to start integration? When to start performance testing? Which test types to rely on? And so it goes!

Wednesday, September 2, 2015

Selenium maintenance hell

So often we find ourselves scratching our heads thinking 'Why did it fail? It works perfectly well locally...'. Timeout or 'Session ID is null' (my favorite) errors can be especially annoying when we are currently working on the most famous testing task: make all test pass. Let's analyze together how to fix this unhealthy situation. 

First of all, we need to redefine our task with management. Why so? Having dummy test methods is not what we want to achieve (and not what managers expect from us). Our real task can be defined as: 

Make your tests cover as many functionalities as possible, but avoid false results at all costs. 

I emphasized 'all costs' because I want to make a point which you may find controversial: 

Even the most important tests should be excluded from the automated suite if they are unstable. After exclusion we need to: 

a) prioritize test-fixing task (according to test importance/coverage) 
b) perform the manual test until automated one isn't stable 

Certainly do not run tests locally (and do not force programmers to do that...). This approach leads to nowhere. 

I know we shouldn't, but what if we depend on other services, DBs, factors? Automated test dependencies should be verified before test execution, and if such one exists test should be ignored. 

There is one thing which we often forget about. As QAs/testers we are responsible for building trust in automated tests throughout team/company. False test results are the single most important factor which reduces (or even destroys) this trust. 

Even from the most selfish perspective, there is an important argument against non-stable tests. Writing/maintaining tests with false results will combine your work image in the eyes of others with the word 'FAILURE'. Avoid it at all costs.