If you happened to see the movie “Everything Everywhere All at Once”, here is its monthly IT version. We gathered EVERYTHING about quality assurance and software development trends from EVERYWHERE, so you can read ALL AT ONCE.
We also have some cool news. We received your feedback about how to make it easier and more convenient to communicate in a more professional environment but still keep it a bit informal. So we decided to create our LinkedIn group devoted to Software Testing Talks. SO now you donāt need to wait until the beginning of next month to get another portion of STT. Get it right away from the group and discuss all significant events with like-minded people.
Taking a moment, I would also want to remind you that in June aqua presented a release of new super cool features such as bulk test case execution, KPI alerts, new syncs and more. To see what features and how they work read our full article from our product manager Kate Hornysh.
Getting back to our digest, hereās what got thrown at us:
- Is this bug buggy enough?
- We donāt talk enough about the onboarding of QA specialists
- Login – logout or the typical day of a QA tester
- Such fun to be a tester!
- What is the difference between Quality assurance andā¦ quality assurance?
- 4 reasons why testers need freedom not control
- Handwriting in quality assurance
Is this bug buggy enough?
Pigeonholing of different defects can be overwhelming for even experienced testers. Now imagine if you are a junior and your QA lead tells you the defect you have just found actually is not a bug. If it was me, I would be really confused. But the truth is so, not every found defect is a bug. Why? Here is a good thread on this topic and a better answer:
If not a bug, then what to call it?
āMy devs have requested that I reserve ābugā for when I fail a test because the functionality doesnāt work. I agree. But then what do I call all the other things that need fixed – like grammar mistakes, UX issues, validation issues, etc?
For reference we use Azure devops and I report issues with a requirement as child tasks on that story. So in a child task I write ābug: xyzā with supporting info and then send it back to dev to fix.ā
I think this one is probably the best response amongst all:
>>> Check this thread out in the r/softwaretestingĀ Reddit community.
Here is another thread with a similar request and if grammar mistakes can be considered as bugs:
Bugs vs style issues vs incidents
āBackground: I recently changed careers to QA with a company that has 2 websites (mainly saas). I am the only QA for 7 devs split between the teams. As the only QA I donāt have a mentor to teach me the best practices of how to QA correctly so Iām reading everything I can find but still feel like Iām probably missing things. The company uses Azure dev ops where I write manual test cases for each story while devs write code. Then I test each story.
Question: I run a test and find it functionally meets the acceptance criteria but has styling issues (maybe border color doesnāt match elsewhere on page). Would this be logged in sprint as a bug?
What about grammar issues (like punctuation)? Would it fail a story? Do you or PO decide if it needs fixed now or later? Do you call it a bug or is there better terminology?
What about something just acting weird that is related to the story but not an Acceptance criteria. Maybe the story asks for a box to be checked and it does check but there is a weirdly long delay. Do you call all theses bugs and log them in the sprint? Or pass the story? Or does someone else make that decision for you?
I guess Iām mainly trying to figure out what is my decision vs devs vs PO and trying use the right lingo in the process.ā
Based on my experience I found this answer the most relevant. First of all, always discuss with your team the way you categorise discovered issues. And secondly, make up your own tags for the bugs that can help you navigate through the process:
>>> Check this thread out in the r/softwaretestingĀ Reddit community.
Tips: if you are using aqua ALM there is a way to define a type of your bugs through the āCustom fieldsā feature.
We donāt talk enough about onboarding of QA specialists
This is not the first time I have seen complaints about a lack of onboarding for QA testers. What they are saying is that employers usually give you something to test right away. No diving into the product, providing a period to study the documentation, or even a chance to meet your team. I think itās pretty unfair. However, since more and more testers started openly talking about this issue, it seems there is a tendency to change the situation.
Onboarding new QA team members and how to set them up for success
āI work for a startup that was recently acquired by a much larger company (we will be maintaining ourselves as an “independent” company or rather a department of the acquiring company. In other words, we get more money, but we still control how its spent more or less). We are going to be scaling up our team in all ways including more QA engineers. At this point, I am the most senior person on the QA team, but I’m still very much learning my role and do not have any experience in managing and onboarding new team members. Currently I have an interim QA manager whose actually a member of the dev team. This dev has 20+ years of software industry experience and has worked with QA teams in the past. He is providing me guidance, but simply cannot handle all of the heavy lifting while also keeping up with his work load. He has asked me to start putting together documentation on what I do in a given day. I don’t have a formal process. I have things I do, but honestly don’t have a good strategic flow to my work. I don’t necessarily want help on how to tell people what I do since I’m the only one that knows that. I’m looking for some insight on what information is generally the most helpful to new hires. Again, I’ve been a new hire, but honestly every time I’ve started a new role at a new company it’s been pretty sparse because I’m generally being brought on as the 1st QA that the company has ever hired, thus I’ve never had a true in-depth QA engineer onboarding anywhere I’ve ever worked.
tl;dr – What information about the companies that you have or are working for has been the most helpful and beneficial to know on Day 0-1 that have gotten you the furthest in terms of smooth onboarding, understanding the system/SDLC of the company, or anything in between?ā
Unfortunately, this thread doesnāt receive any comprehensive answer yet but it is good chance for you to do it first.
>>> You can share your opinion in this thread r/softwaretesting
Login - logout or the typical day of a QA tester
I believe there is some typical routine for all testers around the world including me. Mostly itās to log in to all programs, check emails, have a meeting, and then log out of all of those programs. However, for some testers, their typical day looks a bit off than mine.
What does a typical QA day look like in your field?
āI have been doing QA for about a year and Iām not sure itās a good fit. Just wondering what to expect from beginning to senior level in various fields.ā
And here are examples of non-typical routine (or maybe too typical) of some testers:
>>> Check this thread out in the r/QualityAssurance Reddit community.
What is the difference between Quality assurance andā¦ quality assurance?
This is definitely an ongoing discussion. WE all know there are different types of testing, techniques and methods but there is not too much said about types of quality assurance in general. Can evaluating call centre work be considered QA? I donāt know honestly. Based on the main definition from Wikipedia probably yes: āQA is systematic efforts are taken to ensure that the product delivered to the customer meets the contractual and other agreed-upon performance, design, reliability, and maintainability expectations of that customer.ā
Human QA Call Center Vs. technical QA coding?
āIām a bit uninformed-I do Quality Assurance for a call center and it involves reviewing the quality of the service colleagues in my department based on their interaction and grading it. What makes this type of QA so different from the QA I see on this platform which all seems to just be coding? I try to learn more about the coding side and the job descriptions all seem so vague and I descriptive? Can some one clue me in? I want to learn more about QA for humansā¦.ā
This answer confirms my theory and the next answer gives a good insight why we often call testers āQA engineersā not just āQA testersā:
>>> Check this thread out in the r/QualityAssurance Reddit community.
Such fun to be a tester!
You know, I am not a big fan of complaining about the boredom of a job. I believe that in any kind of work you can find something fascinating and entertaining. Especially when we talk about testing ā you can always find something new š And I agree with this guy, it can be boring sometimes but take āthe fun of some āexploratoryā session time.ā
>>> See more answers here.
I am very proud of myself because I happened to find two very cool threads on Twitter.
4 reasons why testers need freedom not control
Micromanagement never brings anything good into the working environment but for some reason, this practice is still alive. This is especially noticeable among the community of testers. I have repeatedly heard about distrust on the part of the management of the work they have done. And I really agree with all the reasons in this post about why it’s so important not to over-control your employees.
>>> Check this thread here.
Handwriting in quality assurance
Numerous studies show that the most effective way to memorise information while learning is to take notes in notebooks. I will not go into details and just leave a link to the article, but this method boosts the brain’s ability to remember more. And as practice shows, this method is great for learning testing. By the way, using your own notes during real testing also helps a lot. If you are too lazy to make personal notes, then you can use the ones that Lisi made and post them on her Twitter. I honestly kept a couple for myself.
>>> To see all handwritten pieces you can in this Twitter thread here.
I hope you relished our June compilation of Software Testing Talks.
Join the Software Testing Talks LinkedIn group and r/softwaretestingtalks Reddit community to get our monthly discussion lists directly to your feed.
I would also be happy to get your feedback, suggestions, or ideas about āSoftware Testing Talksā blogs. Donāt hesitate to contact me on Linkedin. Letās make the testersā community bigger!
