2017 in Review: Public Speaking, Amazing Testing Community & Self-Growth

“And, when you want something, all the universe conspires in helping you to achieve it.” –  Paulo Coelho, The Alchemist

This quote sums up 2017 for me pretty well: with hard work, determination and motivation some of my dreams materialized and I met amazing people who were willing to help me reach my dreams as well. I will slice up this blog post to milestone-like sections. 

From unaccepted speaker to accepted-to-every-one-I-applied-to

I kicked off 2017 reflecting on how I failed getting accepted to speak at conferences. I had a few useful lessons after my first abstract got rejected 5 times, and, I felt like I learned them – I had a bubbling new idea of what I should talk about. Something that I actually know best – my own story.

Don’t try to reinvent the topic and present something far away from your work – best stories are your own and there is a lot for people to learn from them

So, I created a new abstract called “Testing Big Data to Predict Your Perfect Fit”. I was surprised that sometimes it takes just a question to get some support from the experts: there were so many people who proof-read the abstract and were open to give feedback (Speak Easy, for example, introduced me to the wonderful Nancy Kelln). Once the abstract was ready, I submitted to 3 conferences.

I got invited to speak at all of them: Testing Cup 2017 in Gdansk, Poland, Quest for Quality 2017 in Dublin, Ireland and EuroSTAR 2017 in Copenhagen, Denmark! The last one being the biggest European testing conference with around 4-5 speaking tracks at the same time.

Before the very first talk I was so nervous that I couldn’t even sleep the night before. Technically I had some difficulties, but once it was over – the feeling was wonderful! I received great feedback, it was so rewarding to have audience members come to you and tell you that you inspired them or just to talk to you about work problems they have. I felt like I broke the ice and that was absolutely right!

Once you start stepping outside your comfort zone and deliver your first international talk at a conference – it gets better and you feel more comfortable

Quest for Quality’s experience I loved the most (thoughts on why it was the conference of the year for me). Theme spoke to me, talks were very interesting and the fellow speakers and audience in general were lovely people. I really wanted to deliver the best I could and it worked – the audience and my talk definitely clicked. I was voted the best talk of Quest For Quality 2017 with a rating of 4.61/5!

EuroSTAR was a great learning opportunity as it was a very big conference and I could meet a lot of people, but I did not feel the same click as at Q4Q conference. I met wonderful people there, heard good stories, but it wasn’t as cozy as smaller conferences.

In general, I loved public speaking – it was a great challenge. It taught me more about myself and enabled me to meet like-minded people. I am definitely thinking of some talks for 2018 now as well.

Give it a go at public speaking – it will help you grow

Meeting the old & new heroes

Participating in multiple conferences, meetups and online communities I got to meet so many amazing people. That is the best thing that happened to me this year.

Get to know the testing community – be it at conference, meetup or just online gathering. There are so many inspiring people with whom you can bond almost instantly

Imagine that you get to meet Michael Bolton who has been your inspiration since you started your testing career, you exchange stories and he looks at you and says “Impressive, you are going to be big”. It leaves you speechless. And there are so many known faces in conferences – having a chance to meet them in real life is unbelievable. Most of those people are so helpful and friendly that it will give you a kick of extra motivation to reach your dreams.

What surprised me more than known heroes were people of whom I hadn’t heard before. There are so many inspiring, wonderful professionals who add up to the experience of conferences or communities.

Looking at photo archives, I see this heart-warming picture from Quest For Quality conference. With 4 out of 6 people around me here I kept in touch and plan to continue doing so – if you ever meet any of these beautiful humans, tell them a warm hi – they are awesome!

20171003_204208-001

Also, online testing community has been such a great discovery – a lot of great people in testing are open, friendly and willing to share experiences!

Thank you to every single person I got to meet in 2017 – I am very grateful for every encounter!

Shift from Omega tester towards QA role at my work

For more than 2 years, I was a lone tester or as James Bach calls them Omega Tester. I worked a lot spreading testing awareness in general, not only building automation checks from scratch or getting to participate in groomings/plannings and collaborating a lot with other departments.

This year has been pretty generous to me as I got a new team member! So, now, I am shifting more to the QA role in a sense that I can actually ASSESS quality more – I use New Relic to monitor and spot quality issues we may be having. This ability has given me a lot of knowledge about the product, in-depth understanding of the internals and even got me invited to priority meetings with CEO, account manager and the head of engineering. I am becoming more of a quality professional (which I do love a lot) even if I still do a bunch of testing as well, but my new colleague now helps me out with most of the tasks and we can distribute accordingly. I think it was one of the main lessons in my career:

Clear communication, collaboration between teams and being open to everyone has helped me grow and learn a lot about the product

When it comes to testing, I also got to finally play around more with APIs this year and learn more about back-end. That was so fascinating that I would love to learn more about it in 2018.

2017 in Numbers

My personal numbers:

  • Speaker at 3 international conferences
  • Multiple amazing professionals in testing met at conferences/communities
  • QA & Testing department doubled (from 1 person to 2!)

My blog’s numbers:

  • 7 post published
  • 1404 unique visitors – record number since the start of my blogging
  • 2033 views – second in place after 2016 when I did 30 Days of Testing challenge
  • 338 people read the most popular post: Dear tester! Others care about quality, too.

Resolutions in 2018?

After 2017’s challenges with public speaking, I definitely want to speak again at a conference (or a few). I am researching biases right now. I want to do a talk related to our own and other people’s biases. Especially working as testers we get to deal with that a lot! A practical talk of stories and tips (if you have some stories to share on what you faced related to systematic errors and/or dealt with it –  I’d love to hear them!) .

Apart from that, I am aiming to continue occasional blogging and also learn more about APIs!

Advertisements

Dear tester! Others care about quality, too.

Dear tester,

I know that sometimes it feels like people you work with just want to mark the cards in JIRA as Done without proper testing. Sometimes they tell others “…once it passes the QA” or create tasks for you subjected “QA X” like it is being done just because “they have to”. The feeling of annoyance caused by urgency to complete the task immediately without reporting any bugs is inevitable because of the way they tell just to “pass the QA”. I did write of that before on why “pass the QA” makes me cringe, so I can feel your pain really well. Especially, that even after me trying to explain QA vs Testing vs Checking many times in my company and clarifying, the very same wording is still being used. I would like to share with you a story that happened to me which made me think that sometimes we exaggerate a little bit assuming that others do not care of quality as much as we do.

Today one of developers in my company came back with initial implementation and results to “QA”. The task was fairly simple – there is a lot of data generated by an algorithm and we should check it (I’m using here check consciously as it’s not really testing at this point): does it make sense, what patterns of fault we notice, does algo actually work? All of this should evaluate the quality of results produced by this new algorithm.

The wording of this task’s formulation and documentation with the data had QA mentioned around 5 times in various forms and I’m sure you are familiar with most of them: “data to be QAed”, “for the QAing” or my least favorite “pass the QA”. These terms do not feel too good as they are not correctly used and it may feel slightly insulting sometimes that your colleagues may not bother to even understand what you’re doing. However, you cannot teach all people to use the terms and it’s important to let it go sometimes. Remind yourself that we all have biases (and I do have a story on Managing your biases which made me slow down a little bit before judging). I decided not to exaggerate and think from that developer’s point of view: we both know what he wants as a result – the quality should be evaluated even if he is using the wrong terms.

Some colleagues may use the wrong terms and confuse testing/checking/QA, but don’t go and nit-pick on that. Words matter, but not everyone cares either how to name the rose: all you can do as an empathic quality specialist is to show people that you are open to explain to them, but only if they want to. 

This is not why I’m writing to you, though – this colleague of mine may have used the wrong wording, but letting go of that wasn’t the main takeaway I got.

When the colleague created the task description, it lacked one thing: any description of implementation details of algorithm. No documentation was yet created, no code mentioned, only thing provided was the generated data and vague explanation what should be done (compare columns and say if it’s okay or not using some human sense and research on each of options).

I really wanted to see implementation details: how else can I assess actual risks? Maybe there are areas and patterns that are design flaws and can be seen before even looking at the data generated. This developer tends to work alone as well, so there isn’t much of code review going on.

When I asked if there is any documentation on this algorithm, this was the response I got from the developer:
“Not yet, this is not ready for production yet. When it passes QA there will be a documentation page with all the changes that have come out of the QA process.”

This wasn’t something that I expected to be honest – I replied that to do the QA process we need to know the implementation details and this shouldn’t be made visible only when the algo goes to production. We shouldn’t check in the dark.

My reply has made this developer write to me personally and the words that were used by them again were a little bit rough I could say. The arguments on why the documentation wasn’t created were that “it is too big overhead” and then eventually “it seems that we disagree on the QA process here: for this task, there is no need for implementation details”. How would you react to this, my dear tester? Developer is claiming that as someone who is hired to test and give quality evaluations you shouldn’t look at implementation details at all.

As someone who recently encountered several design flaws in built products which caused issues and could have been spotted years ago, I felt ridiculed. Of course testers or QA (whatever way people want to call these specialists) should see implementation details. Is this developer really thinking that their design and implementation is perfect that we should look just at the results produced?

Issues can be spotted when getting to know algorithms and implementation: you may spot a logical error which causes certain bugs before you even look at the data obtained from running the algorithm

I stood my ground then, though. I tried to explain that I would love to see the implementation because it will help me to do the “QA processes” faster, more efficient and may display me some of issues before I actually look at the data. I want to be familiar with what it is actually doing.

And, to my surprise, it worked. This very same developer who was fighting that QA does not need any details on implementation shared with me the code they wrote to produce the results. It turns out that they thought I needed detailed documentation, but even code was enough which could easily be provided.

In the end, I realized that I could have given up. I could have closed myself up and exaggerated thinking that it’s only me who cares about proper quality judgement and people just assign tasks blindly without even considering that there may be issues in their logic of implementation. I could have felt hurt by the words used and impressions I got from this person, but in the end, even if we spoke in different terms, we both aim to finalize quality assesment (not to pass the QA, just understand if this implementation is good enough). I stood up for myself trying just to do my job better and I got help even if it took an extra step.

So, dear tester, believe that your colleagues are there to help you – you all want your products to be successful and of great quality. It is not only you, just sometimes others don’t know what you exactly need to do your tasks – open yourself up and ask for it. Only by sharing your needs and communicating you can make others understand your tasks better. 

 

 

 

How “Clean Code” by Robert C. Martin helped me to get my automation tests going

Even if I am a pretty decent bookworm, it took me months to finish “Clean Code”! It definitely was not an easy evening read for me (even though I do know some people who read it overnight) and it was the very first book I have read on programming.

In the first years of my testing career my tasks were limited to setting up my own testing environment and manual testing (very often with manual test scripts). No wonder it started making me feel like a monkey and bored to death!

When I changed my job to being the lone tester in a startup, my time resources became very limited. Manual routine tasks started to hurt a lot, so automated UI tests became a long term plan. Luckily I have wonderful colleagues who gave me a lot of needed support to get going.

In the very start as a very beginner programmer (never done it before except in university basic classes) and a practical person, I just created some automated tests based on examples I found. My main purpose there was to make it work. If it works – then I move on to the next thing I want to automate, google, find a solution, modify and move on.

Then, the fun began. We did want my automated tests to be actually used and scheduled. For this purpose GitHub was chosen to store it and for that I had to start creating pull-requests and get them reviewed by a senior Java developer. It was definitely terrifying. First pull request I made got 30 comments in one review session.

The comments were super useful, but it made me realize so well that to make it work is not enough – we need to make it maintainable, readable not only to me, but others, and scalable for the future. There were so many things I did not know about programming. And there came an advice from the developer for me to read “Clean Code” by Robert C. Martin.

I did read it and I realized how important it is to actually write clean code. It definitely should be a long term goal of everyone.

Some very important points mentioned in the book which I loved:

  • Meaningful names: Code has to be readable and understandable to others as well, so use intention-revealing names without disinformation.
  • The single responsibility principle (SRP): there should be only one reason (responsibility) for class or module to change.
  • Tests should be clean: readable! One assert per time if possible and single concept per test.

“Clean Code” is full of useful advice on how to make your code cleaner. It includes some easy tips like the ones I listed above, but it also goes in depth and looks into code examples and tries to make the code cleaner hands-on.

Getting software to work and making software clean are two very different activities.

I think the quote above sums up the main idea of the book. Very often whoever is doing programming forget this very important aspect: clean code can make your life way easier in the long run and even help you to avoid making mistakes (or bugs!).

Months later, I finally finished this book (reading bit by bit) and my automated tests are now scheduled for nightly runs. I am far from being a great programmer, but, due to a lot of useful code reviews and information obtained from “Clean Code”, I have improved my code quality a lot and can make changes way easier than before.

Even if you are a not a full time programmer, but have to do some programming, do not underestimate the power of clean code. It is not only about making it work, it’s about making it work in the long run, too. It will scale, get used and be easy to maintain if you work on writing cleaner code. 

Why phrase “pass the QA” makes me cringe

Today I heard someone say “pass the QA” and in this post I will share why I believe that we should cross out this phrase from all dictionaries where it is included because it is just wrong use of definitions.

Let’s break this phrase into two parts: QA and pass.

What is QA?
I am talking here in a sense of quality assurance. Okay, that sounds clear, however, what is quality assurance?

A lot of people mix up QA and testing on a daily basis. There have been various discussions about it and I mostly lean towards the point of Michael Bolton in his post Testers: Get Out of the Quality Assurance Business. It was an eye opener blog post for me: my first job as a tester even had it in the title “Software Quality Assurance Analyst”. Later on, I turned into QA Engineer. However, I am a tester.

Michael Bolton in that blog post gives so many valid points, it’s like a gold mine. It is one of my favorite ever posts about testing. It basically stresses that as a tester you cannot really assure quality. You just inspect it and help to improve it. You test.

QA is not a person or the department of certain type of professionals. It is a task of everyone in the company to work towards assuring quality. Tester may play a huge part in it, but the actual “action” assurers of quality usually are programmers because they actually are making changes to the quality level. And, let’s not forget the main part:

Assuring quality is an ongoing task/goal of the company.

What does it mean to pass?

In testing passing the test means that the test has passed based on its acceptance criteria.

Test may be built from multiple specific test cases or lead by charters. However, the defined acceptance criteria should be clear.

Passing of tests could be related to the common question in testing: how much is it enough to test? Sometimes the answer is not that obvious. There may be various scenarios, explorations to be made and a common standard should be discussed with product management team on what are the requirements and if edge cases should be addressed for the initial release/iteration.

Why don’t I like the phrase “pass the QA”?

After explaining both parts of this phrase, I can say that for me saying “pass the quality assurance” makes almost no sense.

Quality assuring is an ongoing task, so it is never going to end. You cannot pass the quality assurance as it is, but you can pass the test.

I do understand the intent of this phrase and why it was used: it was meant to say that testing will be completed with no show-stopper issues and will pass the acceptance criteria.

Let’s not underestimate the power of wording. Saying “pass the QA” can definitely be misleading. However, sad news are that this term is quite popular to describe the teams of testers. In this case, let’s spread the awareness of the differences between QA and testing – we all are doing QA in the company, but only testers do testing as their full time job (programmers do a fair deal of testing as well, but it is not their main responsibility usually).

 

 

 

Learnings from “Explore It!” by Elisabeth Hendrickson

Exploratory testing is mentioned quite often in the testing world and I believe that the best book to start learning about it is Explore It! Reduce Risk and Increase Confidence with Exploratory Testing by Elisabeth Hendrickson.

This book is pretty short (186 pages), written in a wonderfully smooth and easy to read style, and, it is full of practical tips and tricks for testers. I felt that a lot of things I’ve read in the book I always wanted to express myself, but never found the right words.

Elisabeth starts with foundations about exploring and why it is important. What I liked a lot in the first part of the book was the definition of testing which allowed me to finally know how to clearly answer what’s the difference between testing and checking:

Testing = Checking + Exploring

You’re not done testing until you’ve checked that the software meets expextations and you’ve explored whether there are additional risks.

Very often some colleagues may not understand that testing is more than checking the requirements – there are many silent risks which may cause problems and to find them we need to explore. I also loved Elisabeth’s example of a net: you can imagine software covered in a net and the better coverage there is of the checks, the finer the weave is. However, checks may not cover some spots, so we must explore to find areas where we should improve the net weave.

After some foundations, this book provides many practical tips on how to explore. It teaches you how not to get overwhelmed with the areas to explore, how to create charters and lists many helpful methods for exploration. They are explained in a clear manner and their summary is added in an Appendix 2 of the book. You may have heard of same author’s Test Heuristics Cheat Sheet which is pretty similar to the one in the book.

One more thing that I found especially useful and right on point was the last part of the book called “Putting It in Context”. Not only does it have a lot of useful information on testing itself, but also Elisabeth includes several valuable tips on the communication part of the tester’s job (and.. I love this topic!).

What struck me the most was that very often testers end up “creating” new requirements which may cause some tension in a team. This is very common in a life of a tester as the more you use the product – the more areas you uncover and some of them may not have their requirements specified. In this situation, programmers may get a bit hurt that the tester is coming up with never mentioned scenarios. Here Elisabeth gives a great tip for testers: try to get into requirements meetings. Testers must be present when the requirements are being created together with a programmer and a product manager. In this way, risks can be discussed and clarified together avoiding silent requirements popping up in the late stages of the product which may expand the scope. And, Elisabeth gives a brilliant tip on how to get into those meetings:

Bring cookies. The other people involved are less likely to kick you out of the meeting if you come bearing chocolate.

In conclusion, “Explore It!” was a pleasure to read. It is a very helpful book on how to express yourself better and how to do that sometimes overwhelming job of a tester more systematically. I feel like I have gained confidence as a tester after reading this great book. Nevertheless, I recommended it to some of my non-tester colleagues as I am sure that it gives a good and easy to understand insight to testing.

 

 

Testing challenge was amazing! – Day 31 of 30 Days of Testing

When I decided to join 30 Days of Testing challenge, I did not have much expectations. Now, after a month of sticking to it honestly and sincerely every single day, I can admit that I have learned a lot and met some wonderful people on the way!

Here is the list of all challenges with links to the posts I wrote about them:

  1. BUY ONE TESTING RELATED BOOK AND READ IT BY DAY 30:
    Bought and read “Explore It!” by Elisabeth Hendrickson
  2. TAKE A PHOTO OF SOMETHING YOU ARE DOING AT WORK:
    What I’m doing at work
  3. LISTEN TO A TESTING PODCAST:
    Testcast Podcast “Testing is Dead”
  4. SHARE A TESTING BLOG POST WITH A NON-TESTER:

  5. READ AND COMMENT ON ONE BLOG POST:

  6. PERFORM A CRAZY TEST:

  7. FIND AN ACCESSIBILITY BUG:

  8. DOWNLOAD A MOBILE APP, FIND 5 BUGS AND SEND THE FEEDBACK TO THE CREATOR:

  9. CREATE A MINDMAP:

  10. FIND AN EVENT TO ATTEND (ONLINE OR FACE TO FACE):

  11. TAKE A PICTURE OF YOUR TEAM:

  12. DOODLE A PROBLEM:

  13. FIND A USER EXPERIENCE PROBLEM:

  14. STEP OUTSIDE OF YOUR COMFORT ZONE:

  15. FIND A PROBLEM WITH AN E-COMMERCE WEBSITE:

  16. GO TO A NON-TESTING EVENT:

  17. FIND AND SHARE A QUOTE THAT INSPIRES YOU:

  18. FIND A BROKEN LINK. AND REPORT IT:

  19. FIND AND USE A NEW TOOL:

  20. FIND A GOOD PLACE TO PERFORM SOME SECURITY TESTS:

  21. PAIR TEST WITH SOMEONE:

  22. SHARE YOUR FAVOURITE TESTING TOOL:

  23. HELP SOMEONE TEST BETTER:

  24. CONNECT WITH A TESTER WHO YOU HAVEN’T PREVIOUSLY CONNECTED WITH:

  25. CONTRIBUTE TO A TESTING DISCUSSION:

  26. INVITE A NON-TESTER TO A TEST EVENT:

  27. SAY SOMETHING NICE ABOUT THE THING YOU JUST TESTED:

  28. SUMMARISE AN ISSUE IN 140 CHARACTERS OR LESS:

  29. FIND AN OUT BY ONE ERROR:
    Off-by-one error hunt

  30. GIVE SOMEONE POSITIVE FEEDBACK:
    Give someone positive feedback

     

     

Give someone positive feedback – Day 30 of 30 Days of Testing

GIVE SOMEONE POSITIVE FEEDBACK

I couldn’t imagine of a better way to end an amazing journey of 30 Days of Testing. After all days filled with various testing tasks the final touch is personal, positive and related to people around us.

One of previous challenges was rather work-based- to say something nice about product you tested. It is closely related to today’s challenge as you may say it to a developer who made the product, but today it’s time to say something personal!

In my company, every three months we have personal feedback sessions with our CTO and VP of Engineering. Not only that we get feedback about ourselves, but also we are encouraged to express feedback about everyone in the team (including the people who are in the room). Usually, even if there are some things to improve, positive feedback is a big driving force which calms you down and makes you realize that people value you.

However, I never said positive feedback on purpose to someone personally, so today I chose a programmer who I greatly value, but maybe do not express that enough, and wrote that to him.

The experience was pretty rewarding! I had some struggles to formulate the words and it took a while to click  “Send”, but I feel that he really deserved it and hope that it will make his day. It would make mine.

In the end, I believe that it would be nice to give (and receive!) positive feedback real-time, not on challenges or feedback sessions, but when you feel like it.

 

Off-by-one error hunt – Day 29 of 30 Days of Testing

FIND AN OUT BY ONE ERROR

I did not know where to start with this challenge: what is an out by one error?

After some googling, I decided to stick to off-by-one error and its definition from Wikipedia:
An off-by-one error is a logic error involving the discrete equivalent of a boundary condition. It often occurs in computer programming when an iterative loop iterates one time too many or too few. This problem could arise when a programmer makes mistakes such as using “is less than or equal to” where “is less than” should have been used in a comparison or fails to take into account that a sequence starts at zero rather than one (as with array indices in many languages).

I did discuss this with some friends and they confirmed that it must be the same as “an out by one error”. They gave some more practical examples as well:

  • an array has 10 elements and you want the fifth one, so you do arr[5], but since arrays might be indexed from 0, the fifth element is arr[4] and you’re off-by-one;
  • Vitruvius fencepost error: if you build a straight fence 30 meters long with posts spaced 3 meters apart, how many posts do you need? You may think that you need 10, but to make 10 sections, you need 11 posts.

I am super grateful for wonderful friends as one of them doubting that I will be able to find any of these errors as they are quite easy to check and rare in production, created my own broken counter! If you write a number to which this little program should count – it will start counting with 0 (intentional programmer’s error):
counter

I did not want to give up this easily, so I invested some time checking other sites.I was thinking of where any kind of counting would be done, and, ended up checking e-commerce sites: their searches and price filtering (searching for < instead of =<).

I went to Vero Moda’s Day Dresses category. I decided to check if price filters are working as they say: if there is a price filter “10-20” I expect that it would include both 10 and 20. So, I checked first 10-20 filter and filtered results by High to Low price:
until20
As you can see, there are no 20 pounds dresses. I may guess here that there is less than 20 filter (which user doesn’t know), not less or equal as you may assume. However, maybe site simply does not have dresses which are worth 20 pounds? So, I checked filter 20-30 and filtered prices from low to high to see if there are 20 pounds dresses:

30

And it turns out that there are dresses which are worth 20 pounds. This means that I found an off-by-one error:

In Vero Moda’s price range filter, upper bound is not included: it is < instead of =<.

This is definitely not a huge mistake, but may cost a lot: if user’s budget is up to 20 pounds after filtering to 10-20 price range she may not find what she wants, thus she may end up not buying anything. Maybe some of the dresses which were costing equally 20 dollars would have been most attractive to the user, but there was no chance to see them with the filter on.

30 Days of Testing is moving towards the end and I am so grateful that I need to google some of the definitions because I did encounter off-by-one errors before (especially with strict bounds), but never knew the exact name. Now I do and it feels great to have a term which describes a specific type of a problem!

Summarizing an issue in 130 (originally 89) characters – Day 28 of 30 Days of Testing

SUMMARISE AN ISSUE IN 140 CHARACTERS OR LESS

Most of testers have to do this every day: we don’t write tweets about bugs, but the title of it definitely has a character limit and should be as short as possible.

My issue summary is a real-life example I’ve encountered today. I wanted to buy train tickets in Lithuania. I went to the site for buying train tickets.

The very main page has a very basic UI for buying tickets: one way, round trip radio buttons; two selects for the cities you are traveling between, passengers number field and Search button.

I am not traveling alone, so I wanted to change passengers number to 2. This is where I encountered a problem that even if I changed it in opened selector – number of passengers did not change. So here is a short summary of this bug:

User cannot select more than 1 passenger buying an online ticket with Lithuanian Railways

Here you go. 89 characters summarizing the problem! And, well, I must include a screenshot to depict that there is no change in Passengers field after selecting more passengers:

traukinys

Update: my issue summary just expanded! And, issue turned out to be the UX issue. Prashant just pointed out that there actually is Save Changes button! I did not see it because my computer’s screen resolution is smaller. Looking at the same site with bigger resolution site looks like this:
Screen Shot 2016-07-28 at 9.43.17 AM
Save the changes actually does work and changes passenger number. So, second shot to my issue summary:

User with resolution height less than 666, cannot see “Save the changes” button which prevents them from changing passenger number

Screen Shot 2016-07-28 at 9.49.06 AM

Now the character count is 130, but still challenge completed. 😉

Say nice things about what you test – Day 27 of 30 Days of Testing

SAY SOMETHING NICE ABOUT THE THING YOU JUST TESTED

Usually testers are the ones who report the bad news. This is a professional behavior in a way: we need to spot mistakes and let the team know about it as soon as possible so they would get fixed. The positive feedback often is left unspoken because we are concentrated on finding the negatives.

Being the lone tester, I work very closely with people whose work I have to test. Be it a product manager or a developer – I ask them questions, we collaborate and clarify the requirements and implementation. This allows me to feel closer to the team and as well get happy when something reaches final implementation. Sometimes when my verification is done I express positivity about what I tested: usually it is rather a “well done!” comment in JIRA, but there are also cases when we discuss the new feature’s “superpower” together with the programmer.

In general, my long-term aspiration is to soothe the pain of bad news with acts of appreciation and interest, so I try to say nice things about what I tested. Nevertheless, today I tried to do that even more!

I talked about the new feature with the programmer who has been working on it for a few months now. I really do believe that it’s a great investment in the long-run and I have noticed an amazing improvement in quality of his work. It was great to test a stable and pretty version of the product with no surprises except from a few cosmetic UI issues. As the result of this conversation, mood was lifted for both sides and the programmer shared his own nice thoughts about the same feature.

The greatest part of saying nice things about what you tested is that the programmer will get appreciation and even may explain more about the internals of the feature which helps you to test better.

Positivity is a win-win situation: helps to build a strong team with members who respect each other, share not only their problems, but wins as well.