Starting or moving to different testing projects can be overwhelming. Usually, there is a lot of information to grasp as quickly as you can. Maybe the team is new, the stakeholders are different, and there might be a lot of specification files to read thoroughly.
Since I started my testing career, I have worked on various projects. I’ve joined some of them in their early stages, while others only later. Every new (at least new for me) project started the same way: a lot of meetings with different people from the project loading my brain with too much data.
Were these meetings necessary and useful? Yes!
If you WANT to find bugs, you are more likely to find bugs / if you adopt a nicey-nicey attitude and just want to help the programmers demonstrate that their program works, you’re going to miss a lot of bugs. It’s not just that you will not report them. You’ll just not see them.
Cem Kaner, BBST® Bug Advocacy, Lecture 6, slide 168.
We all get biased multiple times in our lives. Biases can take many forms and they can be difficult to overcome especially when we don’t even realize that we might be biased.
The BBST Foundations course has a lesson focused on Measurement. The goal of the lesson is to lay the groundwork for understanding how to evaluate a measurement’s validity, and why it’s difficult to measure software quality. When I was a student in the course, the lesson seemed to me more focused on curbing my enthusiasm in terms of applying measures than in providing quick tips for how to start measuring my work in my day-to-day job. After a few years of experience, I appreciate much more the approach of carefully considering how to put measures to question instead of accepting them at face value and jumping to conclusions. At the time I was hoping for some tips that would help me answer some measurement requests and questions with more than “I don’t think that will give us much valuable insight, here’s why”, or “I don’t think that’s a good idea”.
Software teams, agile teams, in particular, are well aware of the need for their developers, testers, product owners, and other team members to collaborate. The usual selection of agile ceremonies creates space for people sharing the planning of the work: planning meetings, product backlog refinement meetings, three amigos sessions for coming up with acceptance examples, and daily meetings just to mention a few. For much of the rest of the time, people are hunched over their own keyboards and screens, working on their own tasks – more so in the time of forced remote work. Even if developers work with each other doing pair programming, testers often work on their own.
A lot of projects and companies nowadays no longer have dedicated testers. That doesn’t mean they no longer do testing; they simply share the responsibility of testing inside a development team. Testing becomes an activity that everyone in the team does, but there’s also a strong focus on automation and trying to create large regression suites that cover as much as possible from the overall functionality of the application.
I’ve also seen automated scripts created in several contexts where the people creating them were focused on solving the programming challenges, but they seemed to overlook one key element: how to make their tests powerful. There were lots of hours involved, lots of tools and frameworks, lots of lines of code, but there was little understanding of the application and superficial interest in what the tests will find and cover. So the teams put a lot of effort in creating extensive automated test suites but the question that remained was “Do they bring enough value?”
If you do testing, and recognize how cognitively rich the activities involved in testing are, you probably also recognize the importance of testing skills.
On all the projects I’ve contributed to, good testing, deep testing, involved skills. Asking a random person from the street to test on the project would probably not have led to spectacular results (unless, of course, they happen to be an exquisite tester with awesome testing skills!). Developing those skills requires a lot of work.
The first course in the Black Box Software Testing series is called BBST® Foundations, but don’t let the title fool you: this course is not only for beginner testers. How would you, no longer a novice to software testing, benefit from taking this course? – To help you find an answer to this question, we have compiled a list – tailored for the experienced tester – of valuable takeaways from the course.
Too many testing courses emphasize a superficial knowledge of basic ideas. This makes things easy for novices and reassures some practitioners that they understand the field. However, it’s not deep enough to help students apply what they learn to their day-to-day work.
The BBST series will attempt to foster a deeper level of learning by giving students more opportunities to practice, discuss, and evaluate what they are learning. The specific learning objectives will vary from course to course (each course will describe its own learning objectives).