15
Depends on your definition of testing, anonymized data is widely used by Microsoft and others for monitoring and testing in production, it's the basis for A/B testing or monitoring for example.
In Europe the GDPR does not allow usage of private data, but the GDPR does not apply to anonymised information and anonymised data can be used without consent. ...
12
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 ...
answered Jun 12 '20 at 13:59
Niels van Reijmersdal
30.9k3 gold badges47 silver badges115 bronze badges
9
I wouldn't say it is common to use real data in testing, although the customer might provide a subset of "real" data in order to facilitate the process.
Apart from the privacy and business issues, there are also the legal ones, e.g. General Data Protection Regulation (GDPR) has been enforced since 25 May 2018 in Europe (but I think every company dealing ...
8
Some of the things you can do to prevent this situation from happening again:
establish test code style and guidelines throughout the company or in your particular project
code review the tests
configure code style linters on commit or before/after sending a pull request
regularly talk and discuss test coding practices with your QA team
organize workshops ...
8
It depends
In some industries it's not feasible to test without customer data. Sometimes it's not possible to properly anonymize said data - I test software that uses the US social security number for a large number of lookups. That means that any method of anonymization must ensure that the social security number of a given person must produce the same ...
7
What they mean by "Provide reports on testing" is creating a record of the execution of tests (manual or automatic), what build is being tested and the results of the tests. Any deviations from the test plan should be documented as well as any unexpected behavior.
The specifics of what the report should contain are highly dependent upon the business needs ...
6
This one seems to have two parts so I'll break it out like that.
Test Leadership/Management Reports:
Functional Test Report (RTM*)
Regression Test Report (RTM* sometimes combined with functional report)
Interface Test Report (RTM* optional depending on interfaces)
Security Test Report (RTM* optional depending on security requirements)
Performance Test ...
5
Requirement Traceability matrix maps the user requirements with the test cases. In simple words, the matrix helps in determining if all the requirements have been covered(i.e there are test cases which can be traced back to the requirements).
There are 3 types of RTM:
Forward:Requirements->Test Cases
Backward: Test Cases->Requirements
Bi-...
5
This is company specific. Any sort of bug reporting can work in different teams.
Your two examples seem kind of silly though. Whats so unclear about opening and navigating to web page, and reproducing error, or adding items to cart and checking what discounts are applied?
My personal opinion is that when dealing with new or inexperienced developers, one ...
5
Assuming one cannot start as a "calm and relaxed horse", and we have only these two options, I would focus on starting to deliver as quickly as possible - at the end this is what you were hired to do.
If there are factors that prevent you from starting to work, this is not your problem - this means that there is something wrong in the company's onboarding ...
5
Carefully name tests reflecting requirement in the form of input data & expected result.
I have been in similar situation but for integration UI tests, where it really helped us when we started carefully naming the tests with single specific requirement although sometimes names were very long.
We made sure that test name should unambiguously reflect ...
4
As @vincebowdren says, start with screenshots. There are numerous simple screenshot tools (I've been using the Windows 7 snipping tool for some time now - I can use the mouse to draw a rough circle around a problem area or highlight something), many of them freeware. I'd recommend mapping a keyboard shortcut to start the screenshot tool, for speed.
You don'...
4
Yes, Selenium is an active project (see commit history on GitHub).
Then why are there so many unresolved open issues?
It's open source. We can't expect the team members to fix bugs on a daily basis, because they are just enthusiasts and all have real-life jobs. The developer in charge of a particular area may not have time to deal with it right away, even ...
4
I think Agile testers should assist their Product Owner with writing Acceptance Criteria in the user stories. If you write scenario's in Gherkin you can create manual test cases that match your four criteria of a test.
Scenario: Some action (1. Name)
Give I am logged in (2. Pre-condition)
And I setup something else
When I do some action (3. ...
answered Mar 11 '14 at 8:29
Niels van Reijmersdal
30.9k3 gold badges47 silver badges115 bronze badges
4
This link should be a good start:
http://www.softwaretestinghelp.com/test-case-template-examples/
4
I'd establish good practices for quality bug reporting and I'd have a meeting / session / lunch & learn to present them.
I'd use this opportunity to create, establish and document how a bug should be reported.
I usually make sure to mention that they should consider capturing:
URL
Date & Time bug logged. Often automatically captured by the bug ...
4
I guess you should want to find a balance between both options. You don't want to work really hard and go crazy, but you want to find a sustainable pace. I would prefer to start a bit slower and act more as an observer, but I do think being open and honest about what you see is important. Having a proactive attitude is also key for your long term success.
...
answered Aug 12 '17 at 7:25
Niels van Reijmersdal
30.9k3 gold badges47 silver badges115 bronze badges
4
Take a step back and ask yourself "What is my goal as a QA lead?".
Is your primary goal to generate documents? To write test cases? To provide numbers to project management? Of course not. These things are only useful if they support the ultimate goal of helping deliver a quality product to the customer.
One of the basic tenets of agile is "Working ...
4
Principles related to the processing of personal data
Personal data shall be obtained only for one or more specified and
lawful purposes, and shall not be further processed in any manner
incompatible with that purpose or those purposes.
So as per data protection law applied, production data can’t be processed for ulterior purposes from when it was ...
4
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 ...
3
Depends on the quality requirements of the project and the maturity of its user stories. If the test has to be done once by the same person who has written the test cases, then documenting the test case steps would not be essential or indespensable.
On the other hand, a project requiring different phases of regression testing over a long period of time with ...
3
It's in git so you could do a sparse checkout to get the JavaDoc part of the repo only. This blog post about sparse checkouts goes through it in a reasonable amount of detail:
http://blog.quilitz.de/2010/03/checkout-sub-directories-in-git-sparse-checkouts/comment-page-1/#comment-3146
Or you could download them from maven central:
http://repo1.maven.org/...
3
Comparing old versus new is often quite a testing challenge, particularly without deep documentation. The basic, obvious parts will likely be fine. But the edge cases, the hidden dependencies, the more subtle parts, and the fixes and patches applied to the old system over the years, all can easily get lost in the transition.
A full Functional Spec would go ...
3
I don't have time to do all the documentation, test cases, strategy,
test plan, etc.
I almost always recommend producing the minimum necessary documentation. Call it lean documentation, minimum viable documentation, whatever. You want just enough that helps plan and guide the testing you need to do. Anything more starts to lose value very quickly.
...
3
Timebox it and afterwards evaluate. I would say time-box one hour and then see how probable it is the tester will find the steps to reproduce the issue.
Often its easier for developers to reproduce the issue, since they understand the code for that part. And they are more proficient in code-debuging.
answered Aug 5 '15 at 8:05
Niels van Reijmersdal
30.9k3 gold badges47 silver badges115 bronze badges
3
I recommend avoiding external documentation because no one wants to maintain it. Instead, use comments in your code and useful names for your classes and methods. And ask someone to review some of your code specifically with those considerations in mind.
3
I've introduced the following structure which includes a section that reflects the Agile Testing Quadrants for Unit, Integrated, Performance and Exploratory testing.
Each link goes a detail page for that area which outlines what is being done for our company in that area.
3
We have daily builds, Below are some of the lessons that worked for us
(Knowledge Part) - Documented notes (critical discussions, one-liners - running notes are usually captured and shared after design discussions, MOM etc..). This is a quick reference used during testing, preparing test scenarios. We usually shared test queries, SQL queries written during ...
3
This question is ambiguous, so I'll try answering two interpretations.
I don't know where to start on writing the technical document, but if someone can tell me what belongs in the TOC, I might be able to figure it out from there. You have not provided enough detail for us to tell you what belongs in your TOC. Here are some options:
Ask someone else on ...
3
Documenting everything in Jira is a possible waste. Everyone in the team should already understand what is expected to get the user story DoneDone, this includes all testing. If you do not know what and how to test I would question your current proces, not the level of documentation.
Agilish teams should focus on testing before or in parallel and not at the ...
answered Aug 17 '16 at 8:31
Niels van Reijmersdal
30.9k3 gold badges47 silver badges115 bronze badges
Only top voted, non community-wiki answers of a minimum length are eligible
