New answers tagged quality-assurance
1
Both the term generally confuse the testers in software testing company. Usability testing is a part of User experience testing. Usability testing is being performed to determine system's ease of access by user.
User experience testing is being performed to test different aspects of user experience to determine the best way for a system and its elements to ...
0
Meeting standards such as ISO 27001 and 27018 are usually confirmed by performing audits. The organizing providing the product or service would need to be audited, and there are companies that can be hired to perform an audit and confirm compliance. The results of these audits are generally provided to customers and partners as proof of compliance. If the ...
0
Impacted Areas of Product
This is what i would suggest apply 80 20 Rule, pick up the prod issues and try to understand the impacted areas , these will be your most impacted and critical areas. Any kind of existing metrics will help you to do this.
Test Data
Analyse if possible the data used in prod and compare it with the ones you are using , there might be ...
5
UX (User Experience) is the process of creating and building software products (web/app/etc) that provide relevant experiences to users. It includes aspects of branding, design (UI), usability and function. In simple, usuability is subset of UX.
So when you do Usability testing, it's only checking if product is easy to use with real users.
For UX testing, ...
3
You can have the best user interface in the world but if the application is slow or does not solve the customers "pain" it won't be used.
User interface is one component of user experience.
UX > UI.
1
So now product is live right? So take the defect leakage ratio. Number of defects in post production/client or stake holders found vs defects found by qa team. There you can analyse how much you missed and find the root cause of the same. Have a pareto chart for the same. Find 80:20 principle. Then work on those 80% issues and get corrective measures.
0
That's why we did it in our project:
Our Story: We recently migrated an complex front end application from angularJS to angular 8 while utilizing the same API for data plumbing with little changes in
geographically distributed sub-teams.
It helped us testing components directly to isolate & resolve issues quickly by putting issues in right buckets ...
1
Adding to @Kate Paulk excelent answer using her example. A few more examples where bugs can be hidden or cause performance issues:
Pre fetching of information to be used in filtering (you ask for all possible product types and then filter them locally, trading loading speed for responsiveness) can be done wrong
Telemetry data can be wrong, contain ...
1
Speed and Stability
Relying on UI tests to test APIs will quickly lead to a lot of problems.
It's ok for 1 test perhaps, but once you start to add more, a lot of problems arise.
Here's why you should avoid the UI when testing APIs:
UI tests are slow
UI tests will not show API level error codes
UI tests require browsers (even if headless)
UI tests are ...
3
So you know where any problems originate
If you have an API that's retrieving information and a website that displays it, you test the API to make sure that the correct information is retrieved. Then you test the website to make sure the information is displayed properly.
Say you're looking for products in a category. Let's say the category is "hair care ...
0
Lots of good answers. I've been in a similar situation and it took process changes in order to overcome the product issues.
Product quality issues are a reflection of the process used to develop the software.
For me, my QA philosophy is what I call "Quality First Development." This entails:
Deliver Excellence: Users should not be finding bugs.
...
0
Seems to me you already found your company's weakness, it's right there in the way your phrase your question: broken (if even existing) processes.
When all's said and done, a product and the product's quality is a sum of processes that led to its creation.
In software, those processes may include:
Correctly gathering and understanding the client's wants ...
0
In my opinion you should keep the focus on the main problem in hand, which is that the client is not happy. In other words, there is a deviation on how the client expects your product to work, and how it is developed to work (the product team's point of view). Given that your product is huge, there is good chance that the client requirements got gradually ...
0
Depending on how frequently your process changes, I may not want to look at historical data or would want to limit how far back I go for historical data. Instead, I'd set up a method for looking at new issues and performing causal analysis on them. Prioritize based on when the issues were found - issues found in production or post-deployment are the top of ...
0
A random sample is giving you bad data, because on the one hand there are defects which generate a lot of low-impact low-effort tickets and on the other there are defects which generate just one ticket with a huge impact and require a huge effort to solve. If you just take a random sample, then your selection will be skewed towards the first, but what you ...
14
I would start by collecting cleaning up the data - don't pick 50 random bugs, but start by classifying them, manually or semi-automatically, maybe using keywords or information from the bug's logs - bug's age, environment, software module, etc. A bug can end up belonging to more than one category.
Move on and look for correlations in the data. Again this ...
3
Generically speaking, creating a software product (pretty much like anything else) has the following major steps. There might be small differences from company to company, but the main idea remains.
behavioral requirements - they describe mainly what the user sees and how the user interacts with the product;
architecture and design - specifies how the ...
8
Ask more questions.
Strictly speaking, to have higher quality in product, have
Higher standards
More testing
Better feedback
However, I would determine the maturity of your development processes.
Ask questions such as:
How closely are developers and testers together to share understanding?
How do you do three amigos when a change arises?
What shape is ...
Top 50 recent answers are included
