Results for State of testing 2016 survey are live.

Hello everyone,

I was a contributor for this years State of testing survey. You might see the posts in social media and on my blog to go to the official site and fill in the survey. In case you didn’t, you can now go and see what you missed to be part of 😀

The state of testing survey is an annual survey that Joel Montvelisky and Tea time with testers magazine make and it is by far one of the valuable things that happen every year in testing. So, I think we really owe these guys a big thank you for the great job they do.

The survey itself provides tons of interesting facts that professionals in software testing shared from all over around the world. Stuff like:

  • What title does testers have in their company?
  • Size of testing teams?
  • How testing teams are distributed around the world?
  • What percent of tests are automated/unit tests/integration tests?
  • What are the percent of adoption of CI?
  • What testing techniques are used among testers?
  • What valuable lesson did they learn during last year?  And many more…

So, enough talking from me, you go see it on your own.

Download State of testing 2016 results here.

On trolls and men. Summary of a lightning talk.

I had my first talk at a conference hooray!

It was exciting, it was interesting and it was challenging for me. So, having in mind my inability to write short stuff and the way I always add more and more, my lightning talk preparation really helped me master a new skill and not try to squeeze 30 min lecture in 5 mins.

The conference is called QA challenge accepted and is a local conference about software testing in Bulgaria, where I am from. There’s a lot to say how exactly the idea of the testing troll came to me and what were the previous versions of the talk that I rejected, but that will be sometimes in future.

The purpose of this post is to make  a summary of the talk and a bit of an analysis of the parts where I’ve messed up. So here are the slides.

There was a short introduction that I made which was something like:

I am here to present for you a couple of advises from my good friend, mentor and spiritual guide – The testing troll.

Wisdom #1: The testing troll doesn’t follow “best practices”

The testing troll is a strange animal, once I asked him: “Why don’t you follow the best practices in testing? Everyone uses them, they are approved by the community?”. And he answered something like that:

“See, every time I hear the words “Best practices” I recall when I was a little troll, there was this guy on the TV, wearing golden trinkets and rings. He was selling this magic frying pan, where you could fry fish, after that a meatball, after that eggs and tastes wont mix. Finally you can bake some milk in it and just wipe with a piece of paper and take the pan back to the drawer like nothing ever happened.”

Note: The above might not be comprehensible for anyone who didn’t grew up in Bulgaria, but in my childhood there was a commercial show, selling crappy goods and that’s one part of it. 
So, much like the frying pan, “best practices” are probably a useful tool, but not for all cases. After all, in life in general, there’s no such thing that works in all cases, there are methods and strategies that work, but only being applied in the right context. Each one of us should decide on his/hers own, what methods and practices to use.

Plus, as the testing troll says, “we have to use it because everyone does” is a really dumb argument.

Wisdom #2: The testing troll is not a manual tester, nor automation.

The testing troll doesn’t like the labels “manual” and “automation” tester. He isn’t manual, because isn’t only using his hands and when asked why he isn’t automated, he responded: “None of my body parts is automated, I am pure organic.”

Note: Organic, by that I actually wanted to make a joke with all the organic buzz that is out there right now, but as I think of it more and more, “testing is organic” and I can add some serious proves about it, in a future blog post. 

The main problem, he thought, is that both labels lay on the false assumption that testing is a process that could be performed by anyone, and that testing is process that could be defined in a finite sequence of steps.

And this is not true – testing is a mental activity and being a mental activity it is constructed by mental sub-activities – exploration, analysis, evaluation, selection of strategies and methods for action, application of strategies and actions, evaluation and analysis of the results.

The testing troll believes that any type of testing is performed in the mind and depending on the context, any good tester could decide if he or she would perform it using tools or not.

Wisdom #3: The testing troll treats tools like tools.

The testing troll likes going to testing conferences, to meet the community and learn new stuff. Unfortunately, people don’t talk about testing in testing conferences any more, they talk about tools – how to configure them, how to use them.

The testing troll doesn’t understand people’s passion to replace human testing with a machine one. Machine testing could only replace certain actions, but not interaction, as with the testing of a skilled human tester.

Note: I totally messed here and I forgot what I was about to say. I skipped the rest of this part and moved to next slide, so I don’t waste time and screw up totally. 🙂

As a result, many shallow and inaccurate checks are thrown out there, trying to make us believe that quantity could replace quality, totally missing the fact it doesn’t in any way improve quality of testing, or the information that we obtain, by doing it.

After all, instead of extending their abilities with tools, people are actually shortening them, waiting for tools to do the work, instead of them.

Wisdom #4: The testing troll knows about certification.

One day, while sitting in his cave and testing, someone knocked on the cave door. It was some travelling salesman from some federation.”Come to a certification course”, he said “you will be able to become super giga mega testing troll within three days, plus we are going to give you a certificate about that. And it’s going to cost you just 99.99”.

And the testing troll thought a little bit. All the other testing trolls in his homeland, Troland, have the certificate for being super giga mega certified testing trolls, how does that make him different, then. Plus, every time he went to an interview, people were interested in what he could really do, not if he had a certificate. Also, the cave was small, there was no additional place for another piece of rock to place the certificate on, plus everyone who got inside get eaten, so any way. He sent him away.

Note: Troland is a name I made up to make it funnier, by just combining “troll” and “land”. It’s not meant to mock any real country’s name or insult anyone. 

Wisdom #5: The testing troll believes testing is exploratory by nature.

The testing troll believes that any type of testing is exploratory. Its purpose is to help us expand our understanding about the product. Each test we are performing is a valid scientific experiment, which we perform against hypothesis we have. In software testing we call such hypothesis – testing oracles. Each test is interesting only when it gives us new information. Repetition of an experiment could be of interest to us only when we want to test the system for its internal consistency – if same input conditions lead to the same output results.

A test or experiment wouldn’t be helpful if it doesn’t provides us with information which we could apply in our further testing.

That was my lightning talk. It was meant to be provoking, amusing and share some opinion, hope it worked and based on the feedback it was interesting for the audience. Of course, there’s so much more to improve in doing lightning talks for me, but it was a challenge definitely.

Thanks for reading. 🙂


Software testing is not…

Software testing is not … part 2.

Software testing is not … part 3.

Software testing is not… finding bugs part 4

Software testing is not … playing. Part 5

Software testing is not … easy to explain. Last part.

This post might be considered  a follow-up to Outdated testing concepts, but with it I’d like to switch the perspective to a bit more general view.

After the above mentioned series were published, I went through a lot of feedback, comments and other non-related articles and they made me think. How do anyone, mostly non-testing professionals feel competent to give opinion on what software testing is? What’s the reason about it? Well, my opinion is that many testers lack the ability to tell a compelling story about their job(and that includes me, in perspective), we often neglect the need to explain what we do in two ways: we either switch to our software testing lingo and get people confused or frustrated or on the opposite, we agree with what other people say software testing is, which is most commonly brought down to – executing test cases, looking for bugs, breaking the product, playing with the product etc.

How do we talk about testing?

This article doesn’t aim to blame anyone, it’s more of a self reflection of the way I was explaining to non-testers about software testing, until now and what I believe many testers say, when they are asked what do they do. So let’s say you meet a friend from school and you haven’t seen each other in 10 years and he happens to be a doctor, for example, and asks you what you do and you say you are a software tester. In the past, in my experience this conversation looked like this:

Friend: Software tester? That sounds cool, what do you do?
Me: Well, it’s kind of like being a programmer, but I am actually testing the code, not writing it.
Friend: But why do you do it, why does it need to be tested?
Me: Because, we are all human, we make mistakes, programmers as well, I need to take a look at their work and  see if the product we create together works as expected.
Friend: How do you know what is expected?
Me: Well, we have requirements created by our clients and we test it against them.
Friend: And what if it doesn’t work as expected?
Me: In this case, we found a defect, we log it in defect management tool, the programmers fix it and we test again,  to see if fix really worked or if didn’t introduce any other defects.
Friend: Ahh, I see… I think I got it.

I know this conversation might look silly, but I did really had this kind of conversations, so this is kind of a compilation of all such talks that I had. The point that I am trying to make here is, we talk about software testing so often by only mentioning only things like: requirements, “kind of like programming”, finding defects etc. and  in the same time we have so many things left off, that are essential to the quality of testing. And who if not us, should be able to build correctly the vision of software testing in other’s eyes and minds. That’s why I am getting really pissed off by people who are often not involved in testing, but trying to school testers what to speak and how to articulate concepts in testing.

Software testing is not…

And this is how I got to this idea. I want to try and figure it out for myself. What software testing is not, what are all these people telling us that is not true and not relevant to testing professionals and most importantly, what software testing is, which will be the topic of the second part of this series. I believe the part of what software is, is the part that gets often omitted and leads to misinterpretation about testing and it’s nature.

So, I made a mind map and I will try to briefly cover what software testing is not, in this chapter. Some of the things, might cover with Outdated testing concepts, so I will run through them quickly.



software testing is not - mind map

Easily performed by anyone.

This is a lie, and I am totally comfortable to call it a lie. In your experience as a tester you will get feedback from non-testers pretending to be “testing” the product. That will be your project manager, your devs, your CEO, designers, anyone will try to make you believe that testing is a task that everyone can do. They are not to blame, more often they are not doing it with bad intent, it’s our job to set the boundaries of what testing is and who can do it.

There’s two sides that have interest in this lie – one is the companies selling pseudo knowledge, that try to make you believe you can become skilled software tester overnight. The other interested side of this lie are the companies that are outsourcing people and threat them as irreplaceable components. They will try to make you believe that talent and expertise don’t matter as long as you write down your tests scripts in the most detailed way, so the next “clicking monkey” could perform everything you did and hopefully get the same success rate as you.

All of this is wrong, and I encourage you to speak up and tell people who believe one of the above claims, that testing is a structured activity that has a purpose and is not a mindless hitting on keys, that there’s way much more than just playing with the product.

In fact, my challenge for you is, every time you are involved in a project, where you and another “pseudo tester” are testing, please, make sure to show non-testing related people the value of true testing. Make them understand the difference between a tester and a non-tester doing testing (still keeping in mind, I don’t consider the latter one “testing”). Make them understand what a skilled professional is capable of by providing the vital information about risk, information of the product on functional and para functional level, provide the better reports, the better test documentation, the better explanation how the product works and most important, learn to sound like an expert, don’t shy out and don’t let people tell you how are you supposed to test, if they are not related to testing directly. There’s one competent person in software testing and that’s you.
Also see:Outdated testing concepts #1 – Anyone can test.

Fixed in a specific time frame.

If you tell this to your management it will probably give them a heart attack, unfortunately it’s true. Let’s try to recall what is testing all about – it is about gathering information and it is about evaluating risk. When your manager or project manager or stake holder comes to you and asks you “Is there any bugs?”, do you think he or she really cares about the bugs? What they are really trying to ask you, in my opinion, is “If we release the product like this tomorrow, is there a risk for our clients? Is it possible for them to reveal a problem that will harm our credibility as a service or product provider?”.

Having that said, we can also repeat again that testing is activity that can only “show the presence of bugs, but not their absence”. Therefore, aiming to release with zero bugs is utopic idea, you will release with bugs, no matter what, so you better know and not lose your fucking mind when that happens. What can we do better is to know what are these bugs and be aware if they are critical for our clients or not.

From everything said up to this point, it seems estimating time for testing is a wild guess and yes it is. Here are a couple of reasons:

  • Since exhaustive testing is impossible, we can’t run “all the tests”.
  • Do we know what system holds as information, before we start the process of testing? We might have requirements, but are we sure they are up to date, before we run into an inconsistency?
  • Do we know how many defects are there in the system, until we actually discover them?
  • Do we know each defect’s complexity, until we try to document it?
  • Can we anticipate the appearance of regression bugs?
  • Can we predict the changes in parts of the system where we don’t expect them, due to the actions of inexperienced developer or bad system architecture (strong coupling between components, lack of unit tests, lack of following recommended development practices) ?

What can we do when we are asked for an estimate, then? It will be a wild guess, but let’s keep it our little secret, ok? People in management and marketing, people working with digits and pie charts, they don’t like uncertainty. What we can do as testers, though is make sure they understand that testing is process on its own, it has different phases and it shouldn’t get mixed with the development process, e.g. the estimated time for the development isn’t the time in which the product is going to be ready to release, we should make the best effort to inform our co-workers that testing takes time and we shouldn’t try to fit in a minimal time frame that was left for us, but rather ask for a dedicated time for testing.

There are ways in which we can try to minimize the uncertainty in our prediction on how long testing would take:

  • Experience is one for sure, the more we test, the more capable we are in order to guess the time to test a system, based on its complexity.
  • Which brings us to our next point – knowing the system, the more we know about it, the easier it will be for us to guess the time to test it.
  • Knowledge of the scope of the change – which is directly related to the two above, we need to have profound knowledge of the system and be aware what part of it will be affected by the change in order to estimate time for testing.
  • And of course, knowing our own process – this is important as well and it should be our first concern, we should know how we will approach the changes, how many meetings we will have to attend to, in order to gather our initial data, how much time we need to write our documentation, if we use one, what documentation will we write, etc, etc.

So, this is for now. The topic is complex and the article becomes lengthy, that’s why I will split it in parts and try to provide explanation of another branches of the mind map in couple of days.

Until then, every comment and opinion on the topic is well come. If you liked it, please feel free to share it in social media. Thanks for reading. 🙂


Some kick ass blog posts from last week #11

Hello, here’s the new portion of kick ass blog posts:

  • Software testing isn’t just a set of skills that we all read about in testing books and white papers, there’s a large variety of skills that we primarily don’t relate to testing, but might benefit our testing in a great way. Simon Knight made a great point about it in his post here:
    7 Things Awesome Testers do That Don’t Look Like Testing
  • Another great post by Michael Bolton in the series “Oracles from the inside out”. In this article Michael is talking about “conference” as a process in trying to reach shared understanding with the rest of the team. You can see the whole article here:
    Blog: Oracles from the Inside Out, Part 9: Conference as Oracle and as Destination
  • Another interesting and inspirational blog post by Simon Knight on writing a blog post. In it, Simon gives his view on a simple plan he follows when trying to write compelling content. You can see the full article here:
    Write powerful blog posts with this simple template
  • And if you are interested in the topic of how people are writing their great content, I encourage you to read Mike Talks’ article, which is inspired by the one Simon wrote:
    WRITING 106 – A scientific template for writing a blog article…
  • I love reading automation posts that aim to teach testers something new and new ways to improve their testing abilities and I am happy to say, Bas Dijkstra is always helpful in that matter. His recent post teach us how to write readable test code, something like recommended coding practices for testers. Which, in my experience is something that is often neglected. The full article you can read here:
    Three practices for creating readable test code
  • Great point from Katrina Clokie on making testing visible and letting other members of the team know what testing is actually about. You can review the whole post here:
    Use your stand up to make testing visible
  • Not to miss an important event “Dear Evil tester” by His Evil Testerness, Alan Richardson, is out, go and download it. By far I am like 10 % in it, really at the beginning, but I love the portion of dark, sarcastic humor that “Dear Evil tester” offers. I will keep you updated with my opinion on it. Until then, you can do it on your own:
    “Dear evil tester” on LeanPub
  • New issue of the testing magazine “Tea time with testers” is out. Don’t ask me what’s in it, I had no time to check it out, yet. Yes, I am human, laws of physics and time apply to me, too. 🙂 You can review the February issue here:
    Tea time with testers – February 2016

Other roundup posts: 

Automate the planet’s – Compelling Sunday. 

That’s it for this week. See you next week! 🙂

Some kick ass blog posts from last week #9

Hey there, here’s the new portion of kick ass blog posts from the previous week:

  • Really amazing start of this weeks roundup and really good post by James Thomas. It shows in a wonderful way how opposition in science and testing can drive us to reconsideration of our positions and stating our ideas more clearly. Definitely a must read:
    Bug-Free Software? Go For It!
  • Another interesting post by Albert Gareev on accessibility testing and the fact that tools might only cover small part of the process that a skilled tester performs, related to accessibility assessment. Automated tools and UI mock-ups in early stages of testing might provide some help, but confidence is build only through expert analysis and taking a closer look, even at a mark up level. You can see the full post here:
    What’s in a label?
  • This is a really interesting webinar by Rex Black, busting some myths about exploratory testing. It is interesting from the perspective of being thought-provoking or even argument provoking. Unfortunately I wasn’t able to hear it all, I accidentally navigated out of the page and found I can’t forward the player to the point I was previously at(which is great user experience, by the way). Anyway, I will probably spend the time to hear it all and share  my thoughts in a separate post:
    Webinar: Myths of Exploratory Testing: 2/24/16
  • And here are part 2 and 3 of James Thomas’ transcript of a talk he had on testing and joking, he called it “Joking with Jerry”
    Joking With Jerry Part 2
    Joking With Jerry Part 3
  • The February issue of Testing Circus magazine is out with great topics from Mike Talks a great interview with Rosie Sherry and much more compelling articles on testing. You can download it here:
    Testing Circus February edition.

Some other roundup posts:

Automate the planet – Compelling Sunday. 

That’s it for this week, guys. See you next week.

Test conf calendar page is live!

I’ve done some changes to my blog, as you might noticed. Besides the fact that I changed the theme, so it doesn’t look like my grandma made the design of it 🙂

I had the idea to make sort of page with all testing conferences I know and have their information and links to their websites, but it turned out it isn’t that easy. So, the idea was dormant for some period of time and now I finally figured it out. Turns out there’s a nice plugin for calendar events that does magnificent job about it. So, it’s done and you can find it in my blog here:

Some important things to say.

I wish to state explicitly, I am in no way involved in the organisation of any of the mentioned conferences or have any material benefit of listing them. The only reason why I do this is the community of testers that I belong to and the fact that I was looking for such place, where all software testing conferences are listed and I couldn’t find it. That’s why I decided to build it on my own. So, this is a community thing and aims to help community members find conferences easier, get to their site, find local events etc. It all depends on the community and their interest in it.

Some credits, that I need to give.

I didn’t do this all by myself. In fact, long after the idea came to my mind I came up to a list of conferences located here: and maintained by Chris Kenst. I never knew the guy, nor I spoke with him, but I’d like to say “Big Thank you!” and acknowledge his great work on listing and maintaining the site, where I got many of the conferences I listed in the calendar, here. First I thought I might contribute there, but the list there doesn’t quite fit what I was looking for, from usability perspective. That’s why I decided to give it a try with the calendar and see how it goes.

Next steps.

I know I missed many conferences and due to my lack of time and the fact I am far from being a polyglot, I will be happy to get any help on adding new conferences. So, in couple of days or a week max, I will try to provide a form for submitting new conferences. I would really like to add new interesting conferences in locations that are not familiar to me or other testers from US/EU like Australia, Afrika and South Amerika, as well as small local events, so they could reach more people and gain more popularity.

I hope you like it and if you are interested in adding conferences to the list, just follow my blog in the next few days.

Good luck!

Some kick ass blog posts from last week #8

Here’s the new portion of kick-ass blog posts from the last week:

Another round-up blog posts.

Automate the planet – Compelling Sunday.

That’s it for this week. See you all next week.

How blogging can improve your testing?

I had recently my 3rd year of blogging, at least this is what wordpress claims. I had the idea to write some overview article for my experiences as a blogger, but I didn’t have the time recently. So, I decided now it is a good time to take break after the tough topic about outdated testing concepts and before I move to another topic. Here’s a short story, how blogging helps you improve as a tester…

They made me do it.

I started blogging as a part of an assignment I had. I was part of this coding academy, which still exists today, organized by Telerik. And we had this class of “Knowledge sharing”, I think that’s what it was called and they made us get a blog, just any free service by our choice. The reason was, as future developers, to have our own technical site which will be useful for us in order to make our own port folio and from a more technical perspective, to see how is a site looking from the inside. Being honest, I had no idea what to do. 😀 They told us it has to be technical one, so it was even harder to me, since I was at that time with none to minimal technical knowledge.

In fact I dropped from the academy, because … well you know the story with all these famous, successful drop-outs 😀 Joking, in fact I dropped out, because I wasn’t good enough for a developer and couldn’t handle working at the same time and spending enough time doing my assignments. So, practically I failed miserably. But the blog was still there.

Every beginning is tough, they say…

I hate clichés, I’d say my beginning blogging was awful. I had no idea what the fuck will I do, I was trying to put every single bit of technical knowledge that I had into it and it wasn’t a lot. And it wasn’t easy, my first articles were awful, the good part is, they are still there lol. In fact, I am proud of them, they are like legacy code, every time I take a look at them, I say “Thanks God, I have made some progress since then.”

Recently after that I started working as a tester, a profession that I felt was “my element” and I had great passion about it, so it was easier to at least target my content. But it didn’t get better in any way, I knew nothing about testing, either. So, I took the best course of action I could, I started reading. And I read almost every piece of post, book, slide or post in social medias that was related to testing.

How blogging is relevant to testing?

We are back in modern days, I don’t think I am quite popular blogger, yet, I just have a small group of readers that read my posts and if they are happy with what I wrote, it’s a bonus, not a purpose. But the lessons that I learned in that process are priceless.

Lesson #1: You will definitely learn how a site looks on the inside.

And this is amazing! As tester the best knowledge you could earn is practical one, and what could be better catalyst for you to strive for high quality looking of your own site, than testing it and developing it on your own. I am talking about hosting your blog on some hosting service and it isn’t so difficult as I thought in the beginning. There is some wonderful issues that you will have to deal with, that will contribute a lot to your knowledge as a technical person in general and as tester in particular:

  • You will most likely run into some small config errors – rights of folders, logs getting too big, the one I first ran into was the amount of memory dedicated for the PHP, I think it was in php_config or something.
  • You will run into some security issues – probably, too much spam comments, files you wouldn’t like to expose to the outer world, etc.
  • As you content grows you will definitely run into performance issues and will probably gain knowledge about what caching is, how to use minifiers, CDNs and so on.

In other words all these are precious technology knowledge you will be getting from the front seat and believe me, you will never forget them, as you personally experienced what it is to have a crappy performance or if your site was down for some reason.

This will give you the larger perspective on what it feels like being the end consumer and how to deal with specific problems.

Lesson #2: Blogging will be helpful for you to channel your knowledge. 

Intelligence is not a linear thing. It is multidimensional, and sometimes the way to make it sharper isn’t to just go and learn stuff. Sometimes you think you know, what you know and yet you only have a shallow understanding of it, you repeat terminology you don’t feel completely comfortable with. That’s why I claim it is important to express yourself and your thoughts publicly. Also, it is verbal expression of one of the core testing principles, don’t trust anything, test even your own assumptions and opinions. I guarantee you, the moment you are visible enough for the community, you will have the most correct measure on whether or not you are developing in the right direction, because once you make a mistake, you will know it.

Another reason is, sometimes we don’t get how shallow our understanding about an idea is, until we try to express it verbally. That’s what I meant by “channeling your knowledge”. We might have more “explicit” knowledge about stuff, what we don’t have very often is the verbal tool set in order to express what we know. In the process of determining what to say, you will see your ideas getting clear and concrete.

Lesson #3: Blogging is your chance to promote your own brand and influence the community.

Like it or not, you are your own brand. And it is better if you can promote your brand in the best possible, most effective way. I can’t remember if it was Kaner, Weinberg or Bach, but one of these guys said a quote I love so much, quoting by memory “Being a good expert and not sharing it publicly is like winking to a girl in the dark. You might do a great job, but no one besides you will know about it.” And it is like this in testing, if you don’t have the balls to state what you think you might be the greatest tester in the whole world, no one would notice. Actually, I don’t think it is even possible, as all great testers that I follow do have blogs and massive online presence.

During the years, having a blog benefited me with some great opportunities to meet and connect with people who I would never meet otherwise and this is wonderful.

Lesson #4: Blogging can accelerate your personal and professional development.

Having all the above combined helped me to educate myself in testing way easier than it was in the beginning. In the beginning it was hard to find any source of knowledge, which is reliable and is worth spending your time. Now, I have access to so many great sources of information, I barely handle it reading watching and responding to anyone who shares some information. Being part of the community and the interaction with it, can benefit you so much in terms of getting more knowledge, getting fast feedback and spreading your ideas way faster and to a wider audience.


I am still wondering why is there so many specialists that are still shying out from having a blog and join the community of pro-active testers.

Once I watched an interview with Stephen King, where he was asked: “What advice will you give to novice writers, what to do, to become successful?” And his answer was: “They have to read a lot and write a lot. Because there’s nothing more delightful, than reading some really crappy book and say… this really sucks… I can do better.” So, my advice to all novice testers is practically the same – read a lot and write a lot, this is your amazing opportunity to make yourself recognizable and influence the testing community and add your unique input to it.

Thanks for reading, I would love to read your feedback in comments and Twitter, if you liked the article, share it with you friends. Good luck.

Some kick ass blog posts from last week #7

Here’s the new portion of kick blog posts from last week:

  • Alister Scott wrote a really useful post about testing email with cool tool called Mailsaur, if you ever wondered how to do that, you might wanna take a look at his blog:
    Testing email in e2e tests with Mailosaur
  • Interesting article by Maaike Brinkhof on the anchoring effect bias in testing. I’d say the post is really thought-provoking and interesting to read:
    MAAIKE BRINKHOF Mapping Biases To Testing: The Anchoring Effect
  • Awesome post by Rich Rogers on software testing terminology and in particular – functional and non-functional testing, two terms which carried ambiguous meanings for a long time.
    Functional or non-functional: does it really work?
  • Another interesting post by Bas Dijkstra on checking your checks and mutation testing – a concept that was new to me and made me research a little bit more about it. You can review the post here:
    Do you check your automated checks?
  • Knowing protocols and basic technologies in web is something that I always strongly recommended, that’s why I really liked that post from T.J. Maher on the history and basics of the REST API, strongly recommended to anyone who wants to develop strong IT domain knowledge:
    Introduction to REST APIs
  • Another pro Selenium tips portion from Anton Angelov with the 2nd part of his post Advanced Webdriver tips and tricks:
    10 Advanced WebDriver Tips and Tricks Part 2

Some other roundup series: 

Some kick ass blog posts from last week #6

Here’s the new portion of kick blog posts from last week:

Other round-up articles, that you might wanna take a look at: