There are many software development blogs out there, but many of them don’t publish testing articles on a regular basis.

Also, I have noticed that some software developers don’t read blogs written by software testers.

That is a shame because I think that we can learn a lot from them.

That is why I decided to create a newsletter that shares the best testing articles which I found during the last week.

Let’s get started.

Technical Stuff

The Really Valuable Stuff

Assisting with inquiries: Part one – your audience is an extremely important blog post that helps you to share information with the stakeholder of your software project. It helps you to divide these people in different groups and create a tailored message for each group. Originally I thought that this tutorial talks about testing, but when I was reading this blog post, I realized that you must use this approach every time when you communicate with people. I urge that you do your colleagues a favor and read this blog post.

Cucumber is NOT a testing framework! is an interesting blog post which argues that Cucumber is a specification tool. Last week a colleague of mine said that Robot is a testing framework, and I agreed with him. However, when I was reading this blog post, I realized that a specification and an automated test (or a check) are two very different things. Why? If you want to find out an answer to that question, you should read this blog post.

Testing myth #1: Writing tests slows you down is an important post that explains that writing tests slows you down only if you think about short term costs (i.e. you want to get this shit done as fast as possible), you haven’t written a lot of tests, or you write your tests on the wrong level. I agree. If you don’t write tests for your code, you are doing a huge disservice to the poor soul who have to maintain your code in the future. Do you really want to be remembered as the person whose name is used as an identifier for shitty code?

Outdated testing concept # 2: The holy guardian of quality crushes the myth which states that testers are responsible for product’s quality. The author argues that a single person (developer, tester, or a manager) cannot be responsible for the quality of the end product. Instead he proposes that: “Everyone adds value with his own unique skills to the product and bears the responsibility for the consequences of his mistakes”. It is hard to disagree with that, and to be honest, I don’t even want to.

Understanding How To Do Accessibility Testing is a blog post that made me feel (a bit) ashamed of myself. The reason why I reacted this way is that no one has ever done accessibility testing for the software that was written by me, and this blog post reminded me of the fact that this probably means that there are people who simply cannot use “my software”. It would be quite easy to say: “It is not my fault because…”. I won’t do this because I want to be proud of my work and blaming other people won’t help me to achieve this goal. Instead I decided to learn more about about accessibility. Where should I start?

It’s Time for Feedback

Because I want to make this newsletter worth your time, I am asking you to help me make it better.

If you have any feedback about this newsletter, share your thoughts on the comment section.

If you have written a blog post about automated testing or software testing, ping me on Twitter.

You can share this blog post on Twitter.

P.S. If you want to make sure that you don’t ever miss Java Testing Weekly, you should subscribe my newsletter.