When I got a comment on my last post, I realised that I had to make myself more clear on some assumptions. Some of them were made on things that I have been thinking about lately, but not discussed with very many people. And I havent blogged about it.
In any project, there are things you need to get done for the project to succeed. In software projects in particular, my view on success is when the software developed brings value to someone of importance. Projects have a budget, usually in money, time or labour of some sort. These have to be distributed among people/equipment to achieve a set of tasks until value is brought by the system.
Software development is a huge domain with lots and lots of different people that are concerned by the software that is developed. We usually call them stakeholders, direct or indirect stakekholders. Indirect stakeholders is pretty much any person on the planet since we are living in our small ecosystem called earth. In software projects we usually only refer to the closest indirect stakeholders and the direct ones. All stakeholders usually have roles within or around the software project.
Human beings need to have labels/folders in our brain to function in a normal way. Otherwise we would be overwhelmed by information if for example every person we meet required its own folder since we are unique. In software development we have a whole lot of roles. Usually everyone can envision people with specific roles doing certain things within a project. Some examples of roles would be (in no special order):
Programmer, Usability expert, Line manager, Architect, Tester, Third party vendor, Configuration manager, Project manager, Scrum master, QA, Customer, Product owner, Business analyst, Test manager, Developer, Requirements analyst, End-user, Designer, Test automation expert, DBA, HR, Project funder
As you can see, from the top of my head I got a good amount of software development roles that are involved in or surrounding projects. I also assume that no project have all of these roles defined.
What is really important in a project is the tasks that need to be done for the software to deliver value. There are many ways to organize, visualize and manage task flow in a project. Usually certain roles or people are tied or expected to do to certain types of tasks. But in the agile context, anyone within a team should be able to do any task. That includes all types of people that are on the team. But is this the best thing to do? Should a usability expert write database queries? The product owner develops the back-end API? The tester helps the customer to write down user stories or acceptance tests?
Which tasks are included in a role definition?
Context, context, context! Of course the tasks that need to be done for a software system to start delivering value varies for every project. The people included in a team also vary, which means that knowledge and skills are different in all contexts as well.
The tester role
When I talk about the tester role in a project team, I usually refer to a person that fulfills and executes the tasks needed to achieve quality of delivered software. Those tasks are usually a good blend of tasks associated with QA, test automation, BA, testing, configuration management etc. But what tasks are expected from a tester like that? That question needs a context.
This is my question to you, please take this one as a challenge!
The project is a member and event registration system with backend, customised member browsing that relies on login privilegies, data uploading, invoicing interfaces towards economy system, customisable registration forms that deliver data separately towards the main system, email template creation and sending etc. You got the point.
Project team consists of 6 people for 20 weeks, in 2 week iterations. One of these is a dedicated tester. The customer is an organisation that has regular members and every now and then organises these events. There is a dedicated person within this organisation that is responsible for this project investment.
What should a developer in this project expect from the tester?
What do you think a developer usually expects from the tester?
What kind of skills are required by the tester?
What kind of tasks will the tester do? Start/mid/end of the project?
As a somewhat inspiration to your answers, take a look at this post by Michael Alexander, where he brings up what testers should be good at, but how should the skill set be used in this project?
Some people have learned that I will give them my thoughts on anything they put in my hands. Most commonly this would be in the software domain, but just as much I will give my thoughts on anything that I can inspect, question or at least have some clue about how it should be, or not be. Sometimes I dont even know this much, but I am able to ask the right questions for the producer to realize the flaws himself. Apart from software this can be documents of some sort or even important emails they are sending.
I really enjoy questioning “products” with the sharp eye of a hard-to-please customer or just like a regular user. With my profession I also have some of the necessary skills to communicate what I believe are flaws or suggestions of improvement in constructive ways that will motivate or even compel changes to be made before deployment. Sometimes the bugs I find are very serious, and sometimes not so serious, but all of them at least become visible to the stakeholder that shows it to me.
Thinking about all the software products I have gotten my hands on, there is a remarkable amount of them where obvious bugs or flaws have appeared almost instantly when doing the first exploration of the product. I have no numbers to build this discussion on more than just a gut feeling that as a tester, if I just get a hand on a product, there will be questions to ask and bugs revealed almost instantly.
I dont know why this is the case, but there are of course several factors that are more obvious than others usually. Things like environment and configurations, testability in development, testing skills and heuristics of developers or even inattentive blindness are factors that usually cover a lot of this. But isn’t there another dimension? The dimension of not only letting another person look and inspect the product, but letting a tester have a look. Sometimes I wonder if my feeling “hand it to me, and Ill show you how broken it really is”, is it something that everyone can sign up on, or is it the way of the tester?
An example of this was when a friend and colleague of mine showed me the product he was currently working on, a mobile phone application. As a tester in the project he had been questioning this particular app for some weeks already. Within 5 minutes I discovered something that for me was an obvious and serious bug, but he and his team had not discovered it before. Was it a coincidence, or is it cause I am a tester and will look at the application in a different way than my colleague? I am quite sure that any other person than another tester would not have found the bug. Say what you want about it, but it was a good thing letting me play with the product for 5 minutes while having a break. And what if you include me fulltime as a tester in a project where you dont have any dedicated tester?
I think of this quite often, and especially when it come to smaller projects (1-5 people) that just say they cannot afford having a tester that does not produce value. And as a tester it is not so easy to prove the value added before getting involved. Though this is a whole new story, can any team of any size creating any product AFFORD to NOT have a tester if you not only think of the customer value created but also include the customer value that you risk to loose if/when delivering an untested product?
Today I was thinking more about the persona of the tester. Thinking about the people surrounding me, mostly developers in my project, but also my test colleagues that I hang around at lunch or in some coffee breaks.
A thing that struck me was that pretty much all testers that I meet are stubborn as nothing else. One thing that shows every time I meet my colleagues is that we never run out of discussions, we only run out of time. Mainly this is because none of us agree completely with the others, never! They are probably also the audience on this blog that can have the most different opinions on what I write. =)
So, is this a good thing, bad thing or a necessary thing for the tester? Yes
Well, if the tester would not stick to his opinion when advocating a bug, no bugs would be fixed when mr-I-never-do-mistakes-developer is on the other side. In this case the stubbornness has to be used for taking the leap towards the analyst or customer. But if its a bug that emotionally struck the tester, and he is being stubborn about it, it could damage the project just as much, if not more than the bug itself.
If the tester was not stubborn enough to continue testing the product, even if no bugs are found in a long time, the most serios and complex bug found at the end of a really long and complex test run would be still unfound. The same goes for the stubborn tester popping the why stack whenever there is anything fishy in the product. But of course, this would also become annoying for whoever has to answer these questions all the time.
I would say that all testers are, and need to be stubborn on their questioning. More stubborn than the products/people/processes around them. That excessive stubbornness and questioning makes a good tester.