I — as a tester — have a unique habit: Whenever I’m about to join a new project, I reach out to my project partner and say, sincerely and kindly, “I have five commitments that I want you to stick to for better collaboration.”
Agreement 1. Business analysts, we are two faces of the same role. Please invite us to the customer needs meeting
Our team needs to make the software available to customers frequently, and the continuous feedback from customers will make the most correct direction for the future of software.
If we deliver software with a lot of quality problems and a lot of defects, the customer will be distracted by the strange behavior of these defects and will not be able to focus on whether the value of the software itself meets their real needs and will not be able to give the most valuable feedback. Therefore, only by frequent testing and informing our team of quality problems before each delivery, can the problems be corrected in time.
I believe “Prevention is better than cure” and I will focus on preventing defects, which will save Dev a lot of time and effort to fix them.
To achieve this, I need to attend customer requirements meetings with you to understand customer requirements and software usage practices as early as possible. So by the time you’ve finished defining the acceptance conditions of the requirements, I’ve basically finished preparing the test cases.
We can tell developers what I’m testing before they even write the code, so that they can reduce the number of important and damaging things that they missed because they were too optimistic, and reduce the number of defects. This is an important task for my test.
If you give it to us after most of the requirements have been sorted out, I will waste the time waiting. What’s more, the software already has a lot of bugs in it that wouldn’t otherwise exist, and developers may have to work overtime to get them fixed before the project’s final delivery date. It’s easy to create new defects.
So, please let me know the requirements as early as possible, and please don’t make me wait until later in the project to start testing.
Contract 2. Developers, while you are experts at writing automated tests, listen to us
I know that for you, automated testing is just “another program” written using junit, RSpec, Selenium, Watir, UIAutomation, etc. Writing automated tests is not an easy task for 80% of QA.
However, I still believe that automated testing with testers is more valuable.
You use unit testing, integration testing to ensure the quality of your code. Your daily tests, however, are closer to the code than to the end user. Many tests are not testing software functionality.
You can write functional tests faster and more, and we can figure out what functional tests are most necessary to add to automated tests.
You spend so much time coding that you don’t have much time to look up bugs. We can point out where defects are likely to occur more frequently and recommend automated testing in these vulnerable areas.
So listen to us and we can give you that information.
Contract 3. Project managers, please do not ask us to test all paths of the software
Software testing is a never-ending task. There is almost no software so simple that we can try out every possible path. Even a seemingly simple Microsoft calculator has endless paths and input, let alone more complex commercial software.
If you’re worried about the unreliability of all paths without trying them, wondering how we can say whether the software is good or bad, what the risks are. Please note that we understand the value of software as well as business analysts. Value can help us determine when to stop testing and say to the customer that our software has met your requirements, please feel free to use it.
Because we understand value, we can say with certainty which software uses are critical and which are unlikely. After we have thoroughly tested the software, we will focus on the high-value features. Use limited project time wisely.
Because we understand value, we can categorize the problems we find correctly. We can help devs focus on important defects and avoid spending time on issues that are trivial to the customer but have to be fixed with a lot of effort.
So please don’t ask us to test a piece of software endlessly. We understand value. Please trust our judgment.
Convention 4. Iteration managers, if you have any questions about delivery risk, please ask me
Both BA and Dev are concerned with the conditions under which a piece of software will work well. And in addition to verifying those conditions, we spend a lot of time looking for situations where the software doesn’t work properly. So in addition to testing for defined software behavior, we also do a lot of exploratory testing. We can often find undefined and unexpected behavior through such tests. These actions often pose a risk to software delivery.
We’ll tell you what’s going on and where the problems are.
We’ll tell you under what circumstances the software might behave differently, whether it’s implicated elsewhere, whether it can be circumvented.
We’ll tell you which parts are more unstable and need more attention.
Convention 5. Testers, those Agile practices are also useful to us.
Pairing is not exclusive to devs. I don’t want to see you all sitting alone in your seats thinking. Get out there and talk to your teammates!
Communicate with your test team to see if the test cases you have designed are comprehensive, and what you think of alone may not be good enough. They’ll give you an honest opinion. Take them seriously, too.
If you find that developers make architectural decisions that make testing more difficult. Tell them out loud, “Design for testability.”
If you find the business analyst writing requirements that are not verifiable, defining customer behavior that is not specific enough, including too many feature points in a user story, and so on, tell him to INVEST (independent, negotiable, valued, estimable, short, measurable) out loud.
You are also encouraged to pair up with developers to write automated tests, which can help you learn how to write automated tests better and also help developers learn more about user behavior in pairs.
These are my five conventions, which are the foundation for me to work well in a team.
Author: Qin Qihui, Agile Consultant at ThoughtWorks. She has been involved in numerous agile software development practices and agile consulting. The current focus is on value-driven Agile testing.
To contribute or translate InfoQ Chinese, please email [email protected]. You are also welcome to join the InfoQ Chinese user discussion group to communicate with our editors and other readers.
discuss