Saturday, December 19, 2015

Testing with Ansible

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

Saturday, December 5, 2015

Blog update

Hi there :)

1. I made 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 have few major advantages for my readers:
- you can read about which you are interested on, 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

Hope you like it!

Follow me on Google+

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 recently. I'd like to continue 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 ThoughWorks - '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 person 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 fields 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. The is 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 one more thing which is worth to mention. As a testers we should clearly report how did we do our job, what did we test and what risk did we observe. From my short experience I can say that most of us (including me) aren't good with 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 seventh phone call and third visit in Ikea an idea struck me. I got project manager role similar to our bosses roles in IT world. As agile enthusiast I'd like to share 11 lessons which 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 its 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 how to things. Make sure they're all possible though.

2. Pick right people. Recently I read great blog about how important for IT companies recruitment is. After hearing more terrifying stories about workers from my family & colleagues I realised it may be very important decision. Fortunately after thorough I picked right. Look for people who are internally motivated (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 investment worth taking.

3. Pay for responsibility, not for things. That's obviously cliche. However there is huge difference between hiring multiple teams to do small jobs and one team to do everything. Avoid splitted 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 costly workaround.

5. Focus on the hardest things, do not micromanage. After picking 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 which involve three parties (you + 2 strangers). Do not waste time speaking to them alone. Arrange conference or make them call each other. After few such occasions I realised why we have standups. Communication is really the key.

7. Be open for 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 huge demand on 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 to 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 reaction can't be too emotional. Think straight.

10. Establish 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 estate broker. He was constantly cheated until he hadn't established something I'll call 'power aura'. Do not naively think you can go wear shorts and during t-shirt during business-making without any consequences.

11. Send weekly reports to family. What? You had probably asked it. After sending those reports I realised 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'. 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 points presented are highly exaggerated (typical media piece these days...), but it's always worth to consider if our job have bright future. So do we, as testers/QAs, have something to worry about?

Let's start with 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 to remember that even with 99,9% unit test coverage and green seleniums bugs may somehow slip on production. Unfortunately in 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 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 manual test at the end of 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. Test pyramid has to look as above (notice that I included 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 specialise in one thing, but keep 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 on System Tester job interview in Motorola. As usual I wanted to prepare as good as possible and by simple googling I made surprising discovery. In the world where almost everything has detailed description 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 mean that you can become 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:
  • 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 analyse what Apple do, so let's check scraps of information we can find online. Before launching iPhone 6 Apple opened testing centre in Cupertino for press. I managed to find absolutely fascinating picture-rich article about iPhone testing (click). Unfortunately those are only hardware tests. If you use Apple products you probably agree that they usability levels are very high. 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 favourite) errors can be especially annoying when we are currently working on the most famous testing task: make all test pass. Let's analyse 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 definitely 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 emphasised 'all costs' because I want to make a point which you may find controversial: 

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

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

Certainly do not run test 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 a 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 important argument against non-stable tests. Writing/maintaining tests with false results will combine you work image in the eyes of others with word 'FAILURE'. Avoid it at all costs.