Wonder why you want to present this to management? What is your goal here, what do you hope to achieve. Do you want to show them they have unknown quality issues?
Normaly I would expect the product to have either an issue tracker or a backlog. Just put the issues on the list, discuss it with the business owners and let them prioritize. Together consider the ...
From the Context-Driven Testing Principles:
"The value of any practice depends on its context."
There is no "industry standard" for this, and even if there was a 99.9% consensus in adoption on one practice or the other, the value of the practice is still dependent on your context.
That being said, some things that you may take into ...
I wrote an answer to a similar question on the Software Engineering Stack Exchange.
There is no "industry standard".
In a perfect world, I would want the testing to happen twice. The "first pass" of testing is on the feature branch. This gives the manual testers the opportunity to create their test cases, make sure they all make sense, ...
You state you are junior. I wonder if you are a "team of senior + junior QAs and you are one of the juniors of the team" or you are "alone in charge of this".
If it's the first case, don't do any report, just tell your senior QAs teammates what you see and ask them for advice.
From now on for the rest of the answer I will assume that you are in this latter ...
Most of the above answers have explained the concept of "Context" when making such a decision .
I would like to iterate on test strategies when planning to test feature branch:
You don't have to do regression test in feature branch
You can do feature testing (testing of the feature that was newly developed)
Sanity test (basic functionality works ...
I am not sure if there are any standards for that. I believe this might depend on a lot of factors specific to your project.
In my experience we do not perform any sort of manual testing against feature branch because there are usually a lot of features in release scope. So we have a release branch and we do development auto-tests/CI when feature is being ...
An boarding document
is exactly that.
It should contain references and pointers to information such as:
End to End Tests
Product demos and videos
Links to the produce/service
Information about the various environments
Information about accounts and logins to use
The first task of any employee is to follow and update the ...
As QA you are correctly getting a weird feeling. REST aims to do CRUD on resources in a standardized way. By adhering to that standard, you decrease the mental load on the next developer trying to figure out how the application works. Making exceptions to the standard would increase technical debt.
So this issue needs to be addressed and if the one person ...
For my experience, the best way for it to be less time consuming is to automate it but since you tagged it as manual-testing, the only advice I can give is try grouping it.
For example if you have hundreds of objects, and when you move this object you need to check how they behave. Im pretty sure, there are lots of objects that when it move, it will have the ...
A lot of things can, and sometimes/often will, go wrong with merging. So any tests done before the merge will not spot any bugs (re)introduced during merging. This is something you have to keep in mind when you (partially) test before the merge.
As others indicated, there no standard norm but more like each company norm.
I had the same question as you before with my previous company but at that time we started moving towards microservices and with Agile there are lots of featured/improvements being done in 2 weeks. So we are divided in team for the features/improvements and each team have QA member ...
This sounds like a dream tester job to me, we can perhaps swap jobs if you want, you'd get many of these in my current position:
absolutely no unit tests, because devs are always running out of time with new featurs and projects, project managers do not even consider the option of little more time for unit tests
there was no tester in the company before me ...
I feel you are blessed to have such a team. I have worked with teams with ratio 1 QA to 10 developers and handled multiple projects at a time. In this case, I used to get bombarded with User stories from developers, with least bit of testing from their side. This environment is highly toxic for a human being because:
No time for a break
Bombarded with user ...
Both Mailinator & Mail7 are good email services, but I personally like Mail7 more. There are various reasons behind my choice.
First of all, it is completely free as of now and its free Pro Plan allows me to create 25 Private Inboxes with Unlimited Emails / Day. And there is Up to 3 days Email Retention. It also gives me 25MB Storage.
I have also found ...
Abstract sub test cases like functions and call by hyperlinked names.
As in programming, we define abstractions as functions , similarly in manual testing we can abstract common functional behavior as sub test cases and develop domain specific keywords(sub test cases) and call by hyperlinks.
Once we have identified an functional flow pattern and named it , ...
An "optimal way" will depend on your purpose (actually, the value of any practice depends on the context).
A test case, like a Product Coverage Outline, an executable specification, or a checklist, is a document target at a particular person. So your question needs to be complemented by who will read the test cases (and with what purpose).
Is there a possility of financial loss by the end-user and that loss that is significant?
If so, advise management.
If there is no loss, raise it as a functional issue and prioritize it's importance against other issues for the product.