No. Requirements should be originated from a single point. Your developers might misunderstand something so that you'll be testing not what your stakeholders require but what your developers implemented (effect of a broken phone).
Asking your product owner will let you catch the gaps between what the business expects vs what your team actually implemented.
Good and Interesting question.
Here are some to make the tester's job easier:
Developers should perform basic testing before giving the product to the tester.
Include QA from the beginning of the project, not when the product is ready to test.
Work as a Team, not as two different departments [Developer & QA]
As the developer, never ask the QA to ...
In this situation - unfortunately - your best option is the slow and painful method. I've used it as a general tester, and for test automation.
The way I approach this is to use these techniques:
Find gaps in use cases/specifications wherever possible - Every time a tester finds a hole or an unconsidered situation in a use case, specification, or design ...
When a new project development starts in an organization when does the testing role come in?
It depends on the company, industry, development approach, etc.
Two commonly referred to methods for development are Waterfall and Agile
In Waterfall you do the testing once the development of a feature is done.
In Agile you do the testing before* and ...
Treat them as equals.
I have seen a lot of developers thinking they are more or better then testers in their companies and also treat them that way. Developers and testers have a similar goal: Making high quality software.
Just a few quick ones off the top of my head:
Run the code they've completed at least once on their machine before marking it as 'Done'.
Consult with QA on their intended route to implement a feature or bug fix to help flush out potential issues or bugs before even one line of code is written
Encourage QA to participate in sprint planning/grooming, design ...
I've worked in both roles for a while and my recommendation is:
Pair (before coding when possible) on test plans
See QA as an asset that is protecting you and customers from the mistakes we all make
Have an open mind when a QA approaches and avoid the (common) mistake of explaining away an issue as their lack of understanding
Don't assume that they can pass ...
I think this is a delicate topic in the software industry, one that I have experienced in the past.
Essentially what I did was have a one-on-one conversation with the person and tried to bring it up conversationally with the development lead. This led to the conversation of job place requirements and what I was responsible for and what the dev. leads ...
My preference is to turn this into a team discussion with the goal of getting coding standards in place that require test-friendly locators to be used.
There can be resistance to changing the standards, but with a lot of tact and a bit of effort, testers can get this through.
The informal conversation is always my starting point. If that gets me nowhere, ...
In game testing, a tester focuses mainly on the following points (from Johan Hoberg's blog):
Fun Factor Testing
Game Level/World Testing
Modification API Testing
I personally believe that testing a game required very sharp judgment ...
I know this problem way too well. There's no "right" answer, unfortunately, but there are some things you can do to help with this problem.
Dependency map - do you have a list of application features that have heavy dependencies and tend to break when changes occur in other areas? If you know changes in feature X tend to break feature Y, you know you always ...
If you can, try & promote the idea of test first development (aka TDD, BDD, ATDD, Specification By Example) with Continuous Integration (frequent commits to a pipeline such as Hudson or GO from Thoughtworks which continuously runs the automated checks to see if any of them have broken after a recent commit)
Before Developers write the code, they write ...
Greater communication between dev and qa so that qa already knows about wip issues.
Communicate first in person where there is disagreement, then document the agreement.
Clear definition on what quality metrics are being used at your company.
More discussion and planning up-front before the first line of code is written.
Talk about what testing is ...
I've seen this pattern in nearly every shop with qa/qe and engineers. My advice from being a dev for 20 years and now a qa engineer for 5 years:
This is a practice that programmers actually do with each other. Did you check this? what about that? What about the other? It's not "questioning the person" though (although it certainly can feel like it), it'...
Maybe you will find a predefined checklist somewhere.
How will you be sure that it is appropriate or correct? What if its not really for you? Will you just take the word of somebody without understanding your needs?
Testing is not a standalone activity because:
resolving bugs means talking with product and development to make sure that the bugs are well understood and that the path to correct them makes sense for all.
understanding business requirements and what an application is trying to achieve means working with business users and product owners
There have been situations where the Devs and the QAs ask questions about this same process. And I always jump in to clarify when this happens. Since I have been there, done that. However, in most of these instances, the Dev lead says something to this effect after my response: "We will discuss this with the QA engineer and the PM" OR "I ...
My ex-client went through a very similar thing. When I started, QA weren't invited to walkthroughs, project meetings, sprint planning, daily stand-ups, etc., and developers were estimating the time for QA! Genuinely couldn't believe it.
The problem was, QA (being the ultimate gatekeepers of quality) were just seen as obstacles rather than valued members of ...
Personally, I do not think making a request via Jira instead of via Slack would make any difference despite Jira being more formal and having more publicity and visibility.
My personal suggestion is:
Invest some effort on looking into why developers only offer less desirable locators? Is there a different opinion regarding what a desirable locator is ...
System requirements are the translations of user requirements in a much more technical language. They are basically the things that a software must perform.
Not exactly. The system usually consists of hardware and software. In some situations, it could even include humans performing well defined processes (for instance, changing depleted batteries).
The short version: regardless of the development methodology, your role is to provide information about the overall quality of the application. You do that via testing anything that isn't included in the developer-maintained automation, and reviewing the developer-maintained automation.
The long version: This question and its answers is a good starting ...
This is a simple point, but very effective:
Be a developer who says "thanks" or "good catch!" or something positive whenever a tester finds a defect.
It's the daily currency of the respectful working relationship. All the formal processes are good, but they flow from the basic attitude of respect.
There are some major red flags here.
You're only going to any testing after development is completely done? If this is development of a single feature, that's fine. If this is for an entire sprint worth of data, that's dangerous. You do not want to wait two weeks before sending a bug report to a developer. When I was developing I could barely remember what ...
I had exactly this discussion with our developers recently, and I do not have satisfactory solution.
Start with understanding what works:
What data is valid ?
What data is used ?
What is successful ?
What are the variations ?
What are the users like ?
What are the long term business goals ?
What are the short term business goals ?
Goals can be very different across industry, company stage, location, profit vs non-profit, etc. Learn what quality means to ...
It is hard to say what your workflow will be. I've worked a few SDET/QA jobs, and it really seems to vary quite a bit. I'll try to cover some of my experiences, though, and hopefully that will be helpful.
I usually like to start my day with a little bit of blackbox, just to get my brain into motion. I'll spend a little while every morning ...
In my opinion, there is incorrect use of terms:
User's requirements in plain language should be called user's stories or etc.
Requirements for the hardware are often called system requirements.
Functional requirements cover what your Application need to do and in which way (i.e. its functions)
P.S. Also, you can read about requirements from the wiki: http:/...
If you want to go fast, you need to assume that once something is tested and working in a cycle, it will continue to work in that cycle. If you cannot make that assumption, you either need to spend more time testing (by yourself or with the help of others) or your developers need to deliver higher-quality code. No one but you and your developers can decide ...
To start off, have a positive attitude towards tester's activities & identified issues
Provide unit + dev-smoke tested builds to QA
Share release notes with info like included fixes, features and known bugs etc
Provide support in technical & back-end understanding of system
Provide support in analyzing hard-to-reproduce issues
Be appreciative ...
Testers have a role in every phase of a project (be it waterfall, iterative, or full on agile):
Project planning - ensuring proper consideration is given to procuring and setting up of test architecture, and for both testing and resolving faults found during testing.
Requirements gathering/setting - testers can help ensure the requirements are described and ...