December 12, 2018

On the 2018 Romanian Testing Conference

So, last week I had the pleasure of attending the 2018 edition of the Romanian Testing Conference. It was my second visit to Cluj: after having delivered a workshop at the conference last year I was invited to do another workshop for this year’s edition. I told Andrei, one of the organizers, that I would gladly accept if he:

could schedule my workshop for the Thursday (Wednesday and Thursday were pre-conference workshops days, the conference itself was on the Friday), and
would make it at least as good an event -and if possible, better- than last year.

Challenge mutually accepted!

During the time when the CFP was open, I sneakily submitted a proposal for a talk as well, and was quite surprised to see it accepted too. Yay! More work!

I left for Romania on Wednesday and arrived around 7 PM at the hotel Grand Italia, which again was both the place where the speakers had their rooms as well as the venue for the conference itself. I cannot stress how awesome it is to be able to pop in and out of your room before, during and after workshops and talks without having to go to another place. Need a rest? Go to your room. Forgot something? You’ll have retrieved it in minutes. Want to check if there’s anyone up for a chat and/or a drink? Just ride the elevator down.

Again, the organization went to great lengths to make us speakers and workshops hosts as comfortable as they could. Always someone around if you have questions, picking you up from and bringing you back to the airport in dedicated RTC cars (even at stupid o’clock), it is a wonderfully organized event.

Thursday – workshop day
Like last year, I hosted a workshop around API testing and automation. Where I only used REST Assured last year, I decided to give the participants a broader overview of tools by including some exercises with SoapUI, as well as a demo of Parasoft SOAtest, a commercially licensed API testing tool. Also, compared to last year, I threw in more background on the ‘why?’ and the ‘what?’ of API testing.

I had 30 participants (like all other workshops and the conference itself, it was sold out) and after a bumpy start, including a couple of power outages, we were off. Like with all workshops, it took me a little time to gauge the level of experience in the room and to adjust my pace accordingly, but I think I got it right pretty quickly. With several rounds of instructions > exercise > feedback, time was flying by! Breaks were plenty and before I knew it, the working part of the day was over.

We were invited to a wonderful speakers dinner in the hotel restaurant, which provided plenty of time and opportunity to catch up with those other speakers I met before, as well as to meet those that I hadn’t had the privilege to meet yet. After a day of teaching and all the impressions from dinner, I decided to be sensible and make it an early night. Mission failed, because once in my room it still took me hours to fall asleep. My brain just couldn’t shut off..

Friday – conference day
Friday morning came quickly and that meant conference day time! The programme was strong with this one.. So many good talks on the schedule. Yet, like with many conferences, I spent most of the day in the hallway track, preparing for my talk (I wasn’t on until 4 PM) as well as having a chat with speakers and attendees. For me, that’s often at least as valuable as the talks themselves.

Still, I saw three talks: first Angie Jones’ keynote (I met her a month earlier in Utrecht but had never seen her speak before), then Viktor Slavchev’s talk and finally Maria Kedemo’s keynote. All three were very good talks and I learned a lot from them, both in terms of the message they conveyed as well as their presentation style.

This day flew by too and before I knew it, it was time for my own talk. Now, I’m a decent workshop host (or so I’d like to think…) but I am not an experienced speaker, so doing a talk takes a lot out of me, both in terms of the time it takes to prepare as well as the energy I spend during the talk itself. Still, I was pretty pleased with how I did, and the feedback afterwards reflected that. Maybe I just need to do this more often…

After the closing talk, which I skipped in favor of going outside, enjoying the beautiful weather and winding down, the conference was already over. To round it all off, we went out for a bite with some of the speakers before we attended the conference closing party. The organization had one final surprise in tow for me there when they gave me an award for the best workshop of the conference. Seeing the list of amazing workshops that they had on offer this year, I certainly did not expect that!

Since my flight back home left at an ungodly hour the next morning, I decided not to make it too long an evening (not everybody followed my example judging from my Twitter timeline the next morning..). Travels home were uneventful (which I consider a good thing) and suddenly, it was all over again.

My thoughts on this wonderful conference, the organization and the volunteers can be summarized by this tweet, I think:

So, did the organization deliver? Well, I did get to do my workshop on the Thursday, and I had an amazing time again, so yes, I’d say mission accomplished.

Who knows, we’ll be seeing each other there next year?

Bas D

Hi there! I’m Bas, a test automation trainer and consultant always looking for more intelligent ways to use tools to support testing. I’m sharing my experiences and thoughts here, so you can benefit from them too!

You can read more about me on my LinkedIn profile, or contact me at bas@ontestautomation.com. You can also find me on Twitter: a.

https://www.ontestautomation.com/

August 8, 2018

14 Most Common Mistakes A Tester Makes

Did you do any mistake recently?

I did.

But we’re all humans, right? And we’re all likely to make mistakes. Usually people associate making mistakes with punishment which in most of the cases is the immediate action after a mistake is made. And seeing the good part in it is almost impossible, at least while you’re struggling to repair what you did wrong.

Making mistakes can have a positive impact on your professional growth, the only condition is to learn a lesson from the mistakes you’re doing. And during the learning process is almost impossible to avoid making mistakes.

Making mistakes is a lot better than not doing anything. — Billie Joe Armstrong

There is no activity domain in which you’re more likely exposed in making mistakes than in others. Below is a list of mistakes a software tester is exposed to during his/her work lifetime and from which can learn several lessons.

1. Incorrectly evaluate the risks

The job of a tester rely much on identifying and risk mitigation. A good risk analysis can help in identifying what can go wrong with the product you’re testing before it goes to production.

Identifying the areas of concern can massively reduce the costs and time spent afterwards in fixing problems found in later stages of development.

2. Miscommunicate the impact

Miscommunication is always a mistake, even we’re talking about miscommunicate the impact of a bug, the presence of it or any situation that might jeopardise the quality of the product we are testing.

3. Ignore a bug when you see it

Ignoring things like miscommunicate them should never happen. As testers we must address any situation we’re facing — even if we don’t have solutions for these situations or maybe don’t have the bigger picture, it’s better to make them known than to act like the elephant is not in the room.

4. Using the same test data — pesticide paradox

Executing our testing scenarios using the same test date might lead us to the pesticide paradox. Repeating over and over the same test cases with the same test data will no longer find new bugs.

5. Not keeping test cases up to date

If you want your test cases to be useful, keep them up to date. Outdated test cases don’t bring any value into your testing.

6. Criticising developers

A constructive way of giving feedback and a positive communication can make the difference in a tester-developer relation. Try to spot also the good work a developer is doing, not only the bugs or problems found in his/her code. Add positivity into your testing!

7. Making assumptions

As a tester you should never make assumptions! The best way is to ask all the questions you need an answer for, helping you to understand the requirements, what need to be tested, what was implemented or how the application under test is expected to behave.

8. Incorrectly evaluate and measure the effort

Project Manager: “How much would it take you to test this?”

Tester: “Hm, a couple of hours, maybe?!”

Be sure you make a step back and you see the bigger picture before you give estimates.

9. Frequently changing the focus

Emails, meetings, regression testing, test case creation, test case execution, a phone ringing, a person asking something, a patch in production that needs to be tested, another hot fix. I think you all recognise the scenario.

This can have a negative impact on your productivity and quality of your work. I would suggest you to try to find what works best for you and organise your working day accordingly.

10. Copying the acceptance criteria into the test cases

We are sometimes tempted to make this mistake while writing our test cases when we don’t see much value in writing and executing them. Let’s try not just state the obvious from acceptance criteria in our test cases, but also focus on negative testing, edge cases or other scenarios that might make our testing more complete.

11. Incorrectly evaluate the impact of a new functionality/fix

This is translated by one word: regression. It is crucial to understand what other areas are affected by a newly developed functionality or by a code fix.

12. Being scared of using tools

This might happen when you, as tester don’t feel very comfortable with your technical skills. It’s totally fine not to be a super hero in using tools, but I encourage you to be open to any solution that might ease your daily work.

Even you don’t feel comfortable in using tools, you might get help from other testers, developers or maybe online support.

13. Not thinking as the end user

It is better to take the user’s hat and imagine how s/he will use the application you’re testing. It is said that the end user is the best tester which finds more and critical bugs. And we don’t want that, right?

14. Not asking developer’s help

Sometimes we are afraid of being judged or afraid of looking stupid which leads us in trying to find solutions to our problems by our own. It is not a bad thing to be a problem solver. This is not the best practice though when you invest time in doing it instead of asking a developer what you’re trying to figure out.

I encourage you to have a good relation with the developers you’re working and maintain a positive communication. There should be no me vs. you, tester vs. developer kind of situations.

Conclusion

If you found yourself in most of the above situations, I can feel your pain, I went though all of them too through my career. Definitely is desirable to avoid all these mistakes when possible, but when they happen, don’t punish yourself too much. Is good to make mistakes and learn good things from them. Turn your mistakes in valuable life lessons!

Mihaela Sfat

Enthusiast software tester, documentary lover, crazy cat lady, big fan of user experience. Her super power is to watch tennis matches all day long.

http://blog.testing-land.com/

June 7, 2018

biases in software testing

When I saw this image on the internet, I immediately related it to software testing and the times when testers fall for these. In this article, let me try to relate few of the biases with respect to software testing.

“20 Cognitive Biases That Screw Up Your Decisions”

Source:
https://www.businessinsider.in/20-cognitive-biases-that-screw-up-your-
decisions/articleshow/48687485.cms

a. Blind-spot bias: Failing to recognise your own cognitive biases.
Are you biased towards a particular testing technique or a test tool even if it is slowing you down in your mission? Think about the test data you prepare. Do you have a pattern that you unknowingly follow? Do you have a preference for a particular approach in testing even though it is a counter? I slowly realised that I seem to have a sweet spot for mind maps and spend a lot of time on them before realising that an alternative to mind maps would save me a lot of time.

b. Clustering illusion: Tendency to see patterns in random events.
This bias is an interesting one. We testers are discouraged from ignoring random events. We dig deep into our bug investigation skills to find out the pattern in seemingly random events. One of the must-read for investigating intermittent bugs is here: http://www.satisfice.com/blog/archives/34

So, what do you do? Do you seek patterns in random events or ignore the random events? Catch 22 situations with respect to this bias? What are your thoughts?

c. Outcome bias: Judging a decision based on the outcome.
If testers were judged based on the number of defects and not on how they arrived at the defect, would this fall under outcome bias? Think about it. Many times, we judge a decision based on the outcome – someone found a security bug, we announce that the application needs more security testing or the tester is a good security tester. Do we even ask the approach to the discovery of the bug? Was it accidental or there was a plan followed whose end result is the bug? How many times have we taken seemingly big decisions based on a statement or an event without understanding the background?

d. Pro-innovation bias: Proponent of innovation overvalues its usefulness and undervalues its limitations
What is the first thing that came to your mind when you read the above line? For me, it is the automation hype that companies and teams give. Automation, when understood and delivered, has given good results. At the same time, we all have experienced the numerous times when someone sold us the usefulness and we were sucked into believing them. Only when we started working on the project, we realised that the limitations were more than the usefulness.

e. Selective perception: Allowing our expectations to influence how we perceive the world
We work with certain developers and over time, we start expecting a certain kind of bugs only from them. Even if there is a bug right in front of us, we got fooled and ignore those bugs as we never expected such a bug from the developers based on our experience (and expectations). We would in fact not even consider such bugs when we are preparing our test strategy!

We software testers are required to be aware of the biases and highlight them in the project. People trust us to give an unbiased opinion. It will be counterproductive if we ourselves are so biased like the ones I highlighted above. What other biases have you seen yourself get into?

While you think, here is a list of some more biases:
http://www.visualcapitalist.com/every-single-cognitive-bias/

Ajay Balamurugadas

A graduate of Problem Solving Leadership, BBST Courses by AST, Rapid Software Testing, Rapid Testing Intensive workshop, Lean Software Testing Workshop, Ajay Balamurugadas doesn’t hesitate to spend on his learning. Starting his career as a software tester, he continues to be a hands-on software tester along with training new testers, meeting testers in person, presenting at conferences, conducting workshops and sharing his thoughts through his blog and tweets.

http://testwithajay.com/