5 Tips on How to Make Yourself Respected as a Tester in a Company

A lot of times testers feel like they are not valued enough or that their efforts are not visible. Good quality usually is an expected outcome so it is hard to show that the role of a tester is actually very helpful and added up to quality improvements.

Possibly the most challenging work environment I had as a tester was becoming the first full time tester in a startup. There was no testing awareness prior to my role. It took time and effort to prove my value, but in the end, when I was changing jobs, some people openly admitted that they felt that I was one of the most valuable people within the company. So, what tips would I have to reach this state and become actually respected and very valued working as a tester?

  1. Open up to learnings and collaborations

    Take every chance to collaborate with other team members. It does not matter what their role is – it is extremely beneficial to collaborate and learn from others. Be it a developer, sales person or manager. Be proactive in this – tell colleagues that you’d love to learn more and maybe just shadow then for a while. It can add up a lot to your domain knowledge as well as interpersonal relationships with team members. Sometimes a programmer may even think of you when they are working on a new feature and ask you for your input for unit tests, for example.

  2. Be transparent about what you work on and ask for feedback

    If you have daily standups, then during them share the summary of your findings: it has to be concrete and informative. Try to be specific and mention what areas were tested, what was overall quality, if there was a big issue found – feel free to share it. If your organisation does not have standups, try to communicate this information in other channels – be it weekly discussion, plannings or just certain quality reports. Why not to make a quality newsletter? Keep people updated. Also, if you need any help or think that testability was causing some issues – let the team know. Sometimes all the team needs is to know about the pain points in order to help you solve them. Another tip is to arrange regular learning sharing meetings or show-and-tell sessions on what you created – maybe you learned some tricks in test automation or found an interesting bug which had to have a lot of investigation. Let the team know.

  3. Promote pair testing

    Do some sessions with developers, managers, product team members or even sales people. It will help them to see your role differently as well as possibly uncover unexpected bugs. Every person has a different set of experience and their usage of the product may be different. A lot of times developers may even sense what parts of the product are buggy, while product or sales people know what is actually important and where to put extra attention when testing.

  4. Use analytics to prioritize and drive your testing

    Testing in production is more and more of a thing. It is very important for us as testers to get to know our users. A lot of times we cannot really cover all the test scenarios either, especially in the times of big data and microservices. If possible, get to know the monitoring systems – what is being monitored in production? Can you see what features are mainly used by users? What browsers are your users using? All this data can help you to identify what actually matters. You can then prioritize your testing based on learnings and even include impact numbers to JIRA tickets. For example, you could quantify how important the issue is on IE8 by looking at the analytics numbers for users. Same could be done for functionality related problems. If issue you reported is on IE11 and most of users are using it – it adds extra weight. In the long run, business teams will really respect your input as you will be able to provide quality insights based on actual KPIs (if they are related to user experiences). Ability to do testing driven by user data can help you to provide very well respect insights on quality which could be useful even to the CEO.

  5. Involve yourself in support and customer feedback analysis

    If there is feedback functionality or support team for your product, try to get involved there. This will help you to get to know the user and their pain points. Analysing the issues you will learn more about the product and also get asked to join further investigations. This way you will be learning a lot of valuable information about the actual users which will be really appreciated by anyone in the team.

These 5 points really help raise testing awareness and help transmit the value of testing to the company. In the end, we all are working for the same goal of having a high quality product and as testers we promote this mindset.

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. 

 

 

 

Quest for Quality 2017: Best conference experience of the year

Early this year, I stumbled upon Quest for Quality conference’s website. I was browsing conferences about testing trying to find a place where I could apply to speak at with my newly written abstract. As very often it goes with first impressions, I liked the design of their website and the general impression this conference had: dev-ops and testing are such a great match which I appreciate a lot in my daily work. To fast-forward a little bit: I was invited to be a speaker at Q4Q2017 in Dublin, Ireland and can honestly say it has been one of the best conference experiences I have ever had. 

At this conference, I was both an attendee and a speaker. First of all, I believe one of the greatest benefits of being a speaker at conferences in general is a chance to meet fellow speakers as well as amazing attendees who are interested in your story. It definitely is an ice-breaker for introvert speakers. In Q4Q2017 there was plenty of that thanks to the great organizers who helped speakers to get to know each other in a really cozy and sincere speakers/sponsors dinner before the actual conference. We bonded instantly and it gave a certain confidence boost to know fellow speakers, support them and get their support as well. During the conference, we got to talk to each other more and I believe that we got some great long-lasting connections.

As an attendee, I was impressed that Quest for Quality had such amazing speakers and I loved the selection of topics. All the topics were linked to the challenges of Quality Asssurance and digital transformation in this fast-paced IT world. I will mention a few of the talks and key learnings from them.

The conference was opened with an introduction from Nikola Šopar who is the Director of QA Services, Comtrade Digital Services – the company which has organized the event. I could relate to his talk a lot and I think it laid a great start for all of the speakers. Nikola talked about the change we are facing: the pace is really fast in platform economy and with that the concept of quality is changing, too. In the upcoming two days – that was actually the main theme for the conference: change and adapting to it.

Andreas Grabner from Dynatrace delivered a keynote “How DevOps is done by Top Performers” which I found extremely interesting. The current motto unfortunately is “deliver crap faster” and this should change. Andreas told a lot of interesting stories about how dev-ops and quality interact and the continuous user feedback driven innovation including Facebook, Etsy, Dynatrace, Verizon and SOFICO. I loved to learn how companies made delivery not only faster, but better quality, too. Monitoring can help a lot in those cases to avoid false positives and get extra information from automated checks. Also, what I loved in this talk was this:

Maik Nogens with “How the XING Team Created a Successful Content Platform from Scratch” had a lot of great concepts to share that everyone should be familiar with in testing. Maik’s story was full of great lessons, so I’m just going include a couple of photos from it:

Talking about wonderful new friends – I got a chance to meet Maja Schreiner who is going to be my roommate during EuroSTAR 2017 conference! After talking for a while it turned out we are both going there and would be willing to split the costs. Funny coincidence and I’m so grateful for that! By the way, Maja wrote a really great blog post about this year’s Quest for Quality in her blog so check it out! Maja delivered a talk “Continuous Delivery Using Crowdsourced Testing” about how her company involved crowdsourced testing into their workflow. I think crowdsourced testing is a really hot topic nowadays and it was great to get some myths about it busted.

On the second day, a great start of the conference was the keynote by Finn Lorbeer from ThoughtWorks called “Building a High Quality Product”. It was my favorite talk because I could relate so much to it. Finn gave great examples and a lot of food (or to be more precise – muffins) for thought.

Another great talk was by Amela Teftedarija and Darko Nikolić who presented “Think Globally, Act Locally – Build Stronger Distributed Agile Teams”. Most of us have experience working in distributed teams and there definitely are some challenges with that. Amela and Darko gave a lot of great tips to build amazing distributed teams and be more considerate towards yours team members.

Lastly, on the second day I also got to present my talk “Testing Big Data to Predict Your Perfect Fit” and it was a blast! I was fighting with a little cold, but having mini jars of honey in the conference venue and helpful staff was definitely a big advantage! Audience was great – I got a lot of interesting questions after the talk and I felt so honored and happy to be a part of this conference.

In conclusion, I highly recommend Quest for Quality conference – you will come back changed and what is most important – the people there are simply magical! Big thanks to name just a few: the best organizers team with Evelina & Nikola in front, wonderful attendees and the best fellow speakers Maja, Maik, Finn, Neven and Amela! Good luck to all of you and see you next time.

With closing smiles and great memories: me & Amela after the wonderful Quest for Quality 2017 experience:
DSC_0041

 

 

 

Managing your biases

Looking back to the very start of my career I see a rollercoaster ride of the confidence levels of my professional knowledge: first I didn’t know anything and felt like a student, then I felt like I know a lot about the product, then I doubted if I know anything when an issue hit the fan, after learning mistakes I again thought I have enough of knowledge… and, well, now it’s slightly different than “I don’t know anything”: I am proudly admitting that despite whatever knowledge I have about the product and testing,  I can be a fool and biased, and learning how to manage my biases has helped me to learn more and more every single day.

The more experience I get in testing, the more I realize that there is always a bit of information that I may not know and this can affect my judgement. And the person whose opinion on quality I may discard can be actually helping me to expand my view on quality.

We all have different background colleagues – I do, too. They may not have the knowledge that we have, but this shouldn’t block us to hearing them out and seeing that maybe this is pointing to something important.

Some time ago a colleague of mine who we can name Lambda would a little bit annoy me coming to me with issues which didn’t seem to be worth a lot of attention. Lambda would be deeply concerned, but a lot of times even if I did investigate the issues presented – I would still hold some inner blockages towards the issues reported because I felt like we have bigger fish to fry than investigate those problems.

Once Lambda again ran to me to talk about a certain issue. This time I was certain that this issue is important, but I felt like we cannot do much about it and we cannot tell why this issue is there. Lambda insisted that we should sit down together and investigate. I was hesitating because my inner biases were telling me “we cannot do much about it, Lambda is not a tester”, but still tried to help Lambda. After some time, Lambda got a genius idea on why the issue was happening. I was dumbfounded. I did not see this person as a viable information source, I felt like I may know better and yet.. I was utterly wrong.

This little story was just one of many – with time I am learning to listen more and more. Before when I would get e-mails about issues from various people – I would be rather skeptical. Now I am intrigued. I love investigations, I try not to block the issues that other people find important – it is a great room to grow myself as a tester.

There are so many points related to this topic: the way we test, the way we make conclusions, the way we listen. I have touched only the tip of the iceberg here, however, from my mere experience in testing, advice to my younger self:

Shut up and listen to others more, dig deep to the issues reported even if you want to quickly comment that “it works this way” – you may find something that you did not expect at all. There are dark areas in your product even if you could not notice them. Communicating to people you can learn many new things and information is key in testing. Your knowledge will expand constantly.

Issue investigations have been my favorite part about testing and I must say that improving listening skills and hearing out other people has helped me big time to be better at that. I cannot give a lousy answer to a person from a different background – I have to prepare a detailed answer which doesn’t leave question marks even if person is not too technical. And, sometimes, I definitely can be a fool with my ideas about how it’s working – others may be correct even if I don’t believe it because I feel like I know better.

Managing inner biases and all the blockages that we have is quite a challenge. However, looking back, I think all the mistakes I’ve encountered/done in testing have helped me to slow down and listen. Not only in professional life, but in personal, too – give people a chance, they may actually know better than you.

 

London Tester Gathering Workshops 2017 Impressions

When Ministry of Testing announced a competition to win tickets to London Tester Gathering Workshops, I submitted my entry and didn’t think I’d actually win it. However, social media is the thing nowadays and I must say enormous thanks to 10 testers who entered competition via my lucky URL and made the chances of me winning higher! I cannot express enough on how grateful I am for getting this ticket – workshops for me are the most valuable method of learning. LTGW2017 was a blast!

London Tester Gathering Workshops lasted two days and each of the days had half-day workshop sessions which were fueled with interactive participation. Also, there were 2 workshops happening at once so you always could find a good alternative. Variety of topics didn’t make the choice easy, though! I wish I could have attended them all!

First day of conference (June 29th) I kicked off my day going to Security in the Cloud workshop facilitated by Abby Bangser & James Green. Nowadays a lot of companies are moving their infrastructure to the cloud (my company is not an exception) Amazon Web Services (AWS) are bigger than ever and security is one of the key elements that need to be taken care of.

Abby and James gave a great introduction to Amazon AWS and even helped us to understand Software/Platform/Infrastructure concepts better. Here is one of my favorite slides:
Screen Shot 2017-07-11 at 6.05.08 PM.png

After a small theory part, we actually did hands-on exercises trying to utilize Amazon AWS website, finding security issues in the cloud and discussed on how to avoid these.

3 key take-aways I got from Security in the Cloud:

  1. Cloud services are flexible and make you feel that a lot of infrastructure related tasks are not your problem anymore, but come with some risks and this means that for testers AWS can be just another domain for testing
  2. Make sure that only the wanted files are available to the public (or certain group of people) and nothing else (for example, the whole bucket may be available)
  3. Even logging of processes can unravel restricted information to someone who doesn’t have authorization and they could misuse their rights

Second part of the day I spent in the workshop An Introduction to Complexity and Cynefin for Software Testers with Martin Hynie & Ben Kelly.

I have heard about Cynefin (/ˈkʌnᵻvɪn/ kun-EV-in) before just as a buzzword. I did not know what it exactly is and how it is used, so I decided to finally learn by attending this workshop. And, well… I ended up taking more pages of notes for this workshop than any other.

With a few group exercises Martin and Ben were challenging our known decision & sense making patterns and made us realize that we naturally lean towards putting everything in boxes, but it is more important to get more information, stay open and actually reconsider categorizations we made. A lot of information that we got can be used not only in our careers, but even in personal life. Cynefin is not really a decision-making framework, but sense making.

3 key take-aways from An Introduction to Complexity and Cynefin for Software Testers:

  1. We tend to make premature decisions based on our known approaches and Cynefin could help to make us think about the actual problems, ask questions and challenge our believes by rethinking, breaking issues into parts rather than categorizing
  2. The better you become at something – the more you tend to think that it is obvious. This has no second guessing and may lead to disaster
  3. Questions are indicators: there may be a need to expand discussions. Concerns are very important

Another LTGW day had 2 more workshops and I started my day with Telling the Testing Story – Storytelling for Testers facilitated by Huib Schoots.

In this workshop, we learned way more about storytelling and its importance in every single area of life. Storytelling is rather a tribal thing and we tend to lean towards the people who tell good stories.

Also, we got some hands-on practise in presenting our group flipchart creations and I really felt like the team I was in was sort of a dream team – we didn’t know each other at all before the event and at Huib’s workshop we were made to collaborate, it worked out so well and we loved working with each other. Greetings to the wonderful Malonie, Galina & Andrew! And here is one of our group work creations:

3 key take-aways from Telling the Testing Story – Storytelling for Testers:

  1. Storytelling is a very useful skill to have especially as a tester: it is important to communicate well and manage to convince people
  2. Even your job interviews can go way smoother if you prepare stories on what the company wants and how you have done that
  3. Culture at companies is a collections of stories told

For the grand finale workshop, I went to Traffic, Verbs, Testing, and T-Shirts with Sharath Byregowda & Tony Bruce.

We learned more about REST APIs and how to test them. The very fun part was actually playing a game with t-shirts and forming 3 groups (clients, verbs and servers) in order to understand how the requests work on HTTP: clients would provide stickies with URL to the verbs who then ran to the servers to get the response.

I got to be a POST request and carried back all kinds of API codes returned in various situations.

IMG_1676

Later on we got to play around with a certain website and use curl to do some API testing.

3 key take-aways from Traffic, Verbs, Testing, and T-Shirts:

  1. Sometimes even if the returned code is 200, but body still may be wrong
  2. http://www.any-api.com has many API documentations
  3. Curl can be used for API checks and it is actually very interesting to play around with it in order to test REST APIs!

In conclusion, each workshop was full of content worth sharing and was very useful. I heard a lot of interesting information that I can apply at my work, met amazing fellow testers and gained so much of motivation to read about many concepts I haven’t thought of before.

 

 

 

Impressions of “How to Break Web Software” by Mike Andrews and James A. Whittaker

Everyday testing for me involves Web Software, to be precise, I mainly test a Web Service. At work we have a company book shelf and there were no surprises to encounter  “How to Break Web Software: Functional and Security Testing of Web Applications and Web Services” by Mike Andrews and James A. Whittaker. As it was the only testing related book in the shelf at that point – I decided to read it.

This book was written in 2006 so you can imagine that a lot has changed since! Web Software is bigger than ever. Even a regular website may use multiple web services. I did smirk a lot on some of the terms like Web Bugs (I never heard this term before: it would always be called a tracker or a tracking pixel in my environment). Also, to be honest, some of the tools or examples including IE6 made me cringe a little bit and felt a bit outdated, but…

“How to Break Web Software” gives very good foundation for Security Testing Web Software. I haven’t had much experience with Security Testing except for  one of the days in the 30 Days of Testing where I got to play around with Gruyere.

SQL injection, cross-site scripting, session hijacking and cookie poisoning (web cookies not the ones you brought to work to your colleagues as advised in “Explore It”) are just a few attacks which are in this book. Attacks have very clear structure: when to apply it, how to conduct it and how to protect from it.

Not only that the book describes attacks clearly, but it explains the way Web Software works and introduces its terms and technologies. I realized that the last chapter called Web Services would have been like a gold mine for me from the first day when I started working here. It describes technologies I have to work with daily.

“How to Break Web Software” gave me a better understanding of Web Software and even how to be safer in the Web applying some tips mentioned in the book. The attack descriptions were a great way to learn about the testing techniques heard about before, but the best way to learn them better is to apply them practically.

 

 

7 bugs out of 5 will do for Day 8 of 30 Days of Testing

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

With so many apps in the market, it can be tough to choose the one you would like to test: should it be a known and stable app, a small hobby app which you would like to use or an unknown app? This definitely can be overwhelming.

I have realized that there is no need to look too far to find an app to test: my colleague is creating apps, so maybe he would have something new bubbling up in the lab. So, why not to help someone you actually know and give some useful feedback?

The beta app I got to test from the creator himself is called MoveRite. This app helps to learn how to do exercises correctly with videos and detailed instructions. You also can track your workouts and purchase extra exercise sets.

It is an iOS app which I tested on iPhone 6. I explored and familiarized with the app by creating random workouts, checking out functionality. It is in quite good condition, so no major bugs were encountered, but it’s not totally bug-free either (but who is?). Enormous help was that creator could give me test user for purchases, so I could test a lot of areas.

Here are my findings:

  1. No weight exercises have weights assigned to them and there is no 0 to choose.crunches with kilos
    At this stage of the app, all exercises require weights. What should be the weight for your abs exercises? The smallest you can put is 1 kilogram for crunches.
  2. About the app section contains default text filler
    loren ipsum
    This is rather expected in an early stage of an app – text will come later, so just a minor detail. So, let’s move on to better findings.
  3. Same weight numbers are shown for both kilograms and pounds

    This was achieved by changing measurement in the Settings and comparing same data as was obtained in kilograms.

  4. Kilograms are still displayed in selector with pounds being default measurement
    1) Change measurement to pounds instead of kilograms in Settings.
    2) Create a workout (or edit existing one)
    3) Try to select a custom weight amount
    Verify that even if selected numbers are shown in pounds, but custom selection still includes kilograms.
    kgs not changed in selector
  5. App closes after first purchase
    1) Navigate to App Purchases in MoveRite
    2) Click to purchase one of the exercise packs
    3) Sign in to your iTunes in pop-up dialog
    4) Confirm that you want to buy the app
    Verify that MoveRite closes and you are left in Home screen with Thank you message. You need to reopen the app. 
    app_off_on_purchase
  6. After purchasing second exercise pack it does not change to Owned
    Precondition: you just reproduced bug #4 and have one of packs purchased.
    1) Reopen MoveRite (you may need to sign in on launch, so do that)
    2) Go to App Purchases
    3) Click to purchase pack you do not own
    4) Confirm the payment
    Verify that in App Purchases Pack remains with the price which did not turn to Owned even if you did purchase that other exercise pack.
    after second purchase not owned
  7. After purchasing both exercise packs and reopening app – both packs still have prices and trying to purchase you get a message that you already own it
    Precondition: make sure you have both exercise packs purchased and encountered bugs #4 and #5
    1) Reopen the app
    Verify that both packs are with prices again and not marked as Owned
    2) Click on price to purchase it again
    Verify that message appears that you already have purchased this
    IMG_0058

To comment more on the purchase bugs, I am not sure maybe some of purchase bugs were actual limitations of sandbox user that I was given as creator said that it may cause some problems.

Conclusion: it turned out to be 7 bugs and I enjoyed this challenge a lot.  Exploring a new product is a great feeling. The best part is that I am giving feedback to the creator and a little bit contributing to the product.

P. S. MoveRite is open for Beta testing so feel free to join as well and help it improve!

 

 

What I’m doing at work: Day 2 of 30 Days of Testing

TAKE A PHOTO OF SOMETHING YOU ARE DOING AT WORK

I had to cheat a bit on this one: it’s Saturday today, so I am not at work. I had to take a picture yesterday, however, I’ll share it now.

13570268_10209801873230058_84405356_o

This looks like a wonderful job for a woman – doesn’t it? All day looking at clothing. My boss sometimes remarks “You’re again shopping!”.

I am testing fit solutions and visual similarity algorithm. It is a pretty exciting task to do with many layers and challenges. This picture just reflects a common screen view you can see on my computer when you pass by.

Rebirth as an Omega Tester

Last time I wrote an entry in this blog was 2 years ago. Definitely, a lot has changed and it’s time for a rebirth.

Reasons why I got silent were simple: I got tired at my work, it became monotonous and lacking of challenges (later reasons became simpler: I forgot about the blog, it was not a habit anymore and I was pretty busy).

More than a year ago, I decided to look for a new job. With a bit of luck and accidents, I stumbled upon an ad for a first full-time software tester in a startup. As I have met all of the requirements and job sounded challenging enough, I just had to apply even if it was based in other country (where I have never been before).

Response was quick and inspiring: I got homework (I always think it’s a great sign of a company – you can prove yourself with actual task). After that, I had multiple Skype interviews and… quit my job (which is definitely a tough thing to do when it’s your first job), packed my bags and moved to a new land of opportunities.

I must tell you that this change was the happiest change in my life. Now it’s more than a year that I work as an only full-time tester in a promising and exciting startup! I have many stories to share, so, it’s about time to make a rebirth.

Changing from manual tester executing test scripts in a big international company to being a sole tester in a (sometimes chaotic) startup is a huge difference, but, oh boy, how worth it is! Advice for you:

If you ever wake up at least a couple of days in a week thinking “I don’t like my work and don’t want to go there” – it’s about time to change your work. New opportunities are around the corner waiting for you.

And, if you find yourself wondering, why did I call myself an Omega tester, there is a great article by James Bach: Omega Tester: Testing with a Team One. Definitely worth reading it!

Fail is for the Winners Part One: Neglected Bugs

“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better” – Samuel Beckett

Sometimes software testing is like a roller-coaster ride: fails (bugs) make you happy, but at the same time sad, and… to make matters worse: sometimes you may fail by reporting something that is not actually a bug.

At the very start of my work, I was scared to file a bug in order to avoid a… failure. How would I feel like if it actually figures out to be not a bug, but a feature? Maybe I’m just not aware of how the software must work.

Later on, I got braver and braver…

I have filed more than 100 bugs in past 3 months. In this new project we just started, I’m the tester who has filed the biggest amount of bugs. Does it make me the best tester? No.

The best tester is the one who gets the most bugs fixed.

Of course, filing a lot of important bugs gives you a bigger chance of actually getting a lot fixed, but… another side of this is that there will be a lot of Closed bugs which will be neglected and it makes you feel a little bit stupid for filing them after developer’s responses like “it works as designed”, or, “cannot reproduce”.

It takes time and practice to learn how to deal with them, but…

Don’t get down because your bugs were neglected. If there is a chance – file it as a task or enhancement. Even if bugs sometimes get closed for various reasons, it is always very useful to put attention on them. What you are doing is great and maybe first 2 times that bug will roughly be marked as Works as Designed, but in future releases someone will take it as an amazing suggestion to improve the software.

And, remember, don’t let failures bring you down. Don’t be scared of being laughed at. It would be way worse not to do anything and sit silent.

There is only one way to become a professional at what you do: Fail.
Fail a lot and never stop moving forward. Only leaving your comfort zone, you will reach some of the most amazing things in the world…