4 things a QA staff wants for developers
Hi, application developers and QA staffs.
I’m belong to an Android application development team as a part-time QA staff. Today, I’ll tell you 4 things I actually asked developers of my team.
As a premise,
Spec of author
I didn’t develop as my job this some years but I developed and released few Web applications privately. My team required:
- who can make communications in Japanese and English
- who can explain bugs with sentences
Unexpectedly, I have also:
- a little old knowledge of Android application development
- the experience of team development on agile process with Trello, Slack and GitHub.
I joined a startup in January and worked as a part-timer for one month. I write what I feel now.medium.com
Targets of this article
This article may be useful for:
- A Project Manager who considers to add QA staffs to own team
- An Application Developer who asks QA staffs to manual tests
- A QA staff who joins to an application development team for the first time as this position
1. I regard Interests of Users more than Circumstances of Developers.
Most of the users (of course) are not interested in any circumstances of developers (for example, implementation status of APIs for each OS version, difference of UI between iOS and Android, budget shortage of the team and developers’ physical condition), so I regard actual Users’ feeling.
2. Write clearly how to test or answers to questions.
I think that it’s the advantage of hiring a non-developer as a QA staff to do Black-Box-Test objectively, so I keep in mind not to get unnecessary information.
Additionally, trying to get unnecessary information is too heavy to work effectively in the limited time, so I skip the information for developers on the task boards.
If you are a developer of a team, you might be working with other members to fix bugs or implement feature. Perhaps you might want to give information your team members (for example, URLs of official documentation for developers or issues on StackOverflow, the card which archived in the past and variable names in the package). It’s a wonderful mind and you should do that from now on.
However, you should separate clearly information for developers from instruction for QA staff as mentioned above.
3. Follow our format. I also do so.
How can we do to do like what I said above? Yeah, let us follow our format on the task boards. It should not be a difficult way.
I, the QA staff, would like to add cards with information to replicate bugs. Which device and OS version? Which revision and build environment? How can you replicate that?
You are a developer, please do the same.
4. Do not feel bad if I make a strange question.
I often ask “is it spec or bug?” about strange behaviors of applications. Perhaps, such behaviors might be common (not strange) for you. I don’t want to blame you but wanna give good effects for our product by those question. Please do not feel bad.
I wish our applications make people happy and smile. Let’s do our best for the same purpose.