New answers tagged

0

If you mean for getting a job, Well, many companies and hiring managers prefer hiring a certified person, be it for development or for testing. For many it is kind of a proof that you are qualified enough. Many others like to show off to their clientele that they have so many certified staff that will be employed to work on their project. Some don't really ...


0

While documenting tests or rather reporting them to your dev team, its suppose to have sufficient details that will help the team trace, understand and fix the issue at hand. Every data you use for testing is important test artifact. Mentioning that in your test cases will tell the developer what data used used for your test that caused the failure. Using ...


1

This would be your test precondition, of which if successful would mean Step 1 you are ready to go with the test. For example, precondition "query database to find X order, navigate to order". Step1 - Using order from precondition, press button Y If the precondition can be achieved then the test case can be run. If the precondition cannot be achieved ...


3

You should aim to create the data yourself although whether you are doing manual or automated testing is a key factor and the following mostly applies to automated testing. One of the principles you should be looking to follow when performing automated testing is setup - execute - teardown Basically you want the system and most notably the data store to ...


2

While testing reports we need to take the following points into consideration - Input data validations eg. date ranges Format of the report Check if there are any calculations like total, max or min values Units are displayed correctly eg. currency Data is displayed correctly based on filters Page navigation and number of rows displayed per page Any links ...


0

Identify base stories. It is very important to identify one or multiple base or reference story against which you would do relative sizing of the backlog. This story is picked from current product backlog or a different story which we have done earlier. But what is important is the understanding of this sory is same among everyone on the team. Team should ...


0

Firstly unlike traditional methodologies where the QA estimate may be separate to the developer estimate, when working in an agile way you will want your software testing estimates to be combined with your developer estimates, producing one estimate per user story. The most common way to do this estimate is using story points where your estimates is a ...


0

I would include tests for expired passwords.


1

If you was under the threat to lose your job as a result of letting a single bug to slip to PROD, you should consider looking for a job in saner company. It is just a matter of time when another bug will slip to PROD. Quality is a team sport. Bugs will always slip, and pointing fingers and assigning blame does NOT improve quality. Firing you for a bug is ...


1

Regarding bug-reports: In my opinion, the best possible bug report (assuming that the person that sends the error report does not know the causes of the observed failure) is a bug report with reproducibility information, so that the developers are capable of reproducing the problem. In several bug tracking sites, for example MySQL, we find literally ...


6

There will always be bugs that get past a tester and land in production. I have even had bugs that where in my face, we researched it, thought it was a fluke, because we couldn't reproduce it and then released the issue into production. The best thing you can do is learn from it and prevent the same in the future. I write an automated test-case for each ...


2

First and foremost, analyse how the bug got past you. Find a way of preventing this, and things like it from happening ever again. Second and maybe even more important, talk. Talk with everyone involved with getting new functionality out. As soon as requirements materialize, get your test approach on paper and scrutinize it AS A TEAM. That a harmful bug got ...


1

The main principles to guide you here are: Each test should be independent. It should perform its own setup and teardown and after running leave the system in the same (initial) state. This will help avoid issues such as "But if I run one test script at a time, I get the result I want" The only exception to this is system-wide seed data needed for ...


0

Yes, A developer would be able to advise how to do further testing. The important thing is that it is before you write the report. Not instead. The developer is not responsible for deciding if a bug has been removed.


0

As "Joern Boegeholz" said; It Depends. Usually I prefer to ask my clients (dev team, management, analysts, designers, the client) how much details they want in the bug report. Many a times people don't really read a whole lot and hence they ask for fewer details, yet if the testers can do Impact Analysis of the Bug and report it in the Bug Report, that's a ...


0

I think it's fair for QA to enter a bug with what they think the impact/severity of it is. This can easily be updated and over-ridden by someone else downstream (e.g. the person triaging issues, project manager, whatever), but a good tester should have some idea if an issue is a show stopper, if it's going to be a big issue for end users, maybe it's just ...


1

To stay simple, and echo what others have said- (20 years experience here)... Find the steps to reproduce Take your screen shots or grab logs, etc. Find the root cause if you can Report the bug. Get it in the system. Perhaps do some limited searching to make sure it isn't a duplicate. speak to the developer at this point or when first able <-fin-> :)


1

You should have 2 test cases because they have difference steps and difference expected result. Run the test case one by one. If you want the test to fail, change the expected value to anything else. It sounds like you are not using testing framework. If you are using xUnit, it will help you to manage test fixture, assertions, ...


1

The PM, the designer, the QA, the developer and other stakeholders; each of them have different perspectives and expectations from the product, even when working with a perfect analysis. An objective look really matters. So, sometimes, especially when I am about to release a new feature or unsure of the requirements of my task, I ask for QA's time and ask ...


0

A classic answer: "It depends" It depends on how strongly the tester is involved into the development process. If he knows that the issue affects two different products which are delivered from two separate branches relying on the same implementation, he can state that in his bug report. A more practical approach would be simply trying to reproduce the ...


0

Just repeating some of what has already been said, but as another voice with 15+ years of combined QA & Dev experience, I would agree mostly with those who say that it all depends on what works best for your company/teams. However that said, I'm a fan of open dialog between Dev & QA, and I personally think teams that have that in place will fare ...


0

I think you should absolutely discuss it with the developer. I work in an environment where we have a mainframe connected via MQ and other middleware to various front ends (web apps, POS machines, smartphone apps). Just because a scenario fails doesn't mean the code is bad. Maybe the middleware developer isn't passing the correct data to the front end. Maybe ...


2

Report the bug. A QA person's role is to be an independent verification authority. Someone who understands the products requirements and who is focused on quality. Make sure you document your problem scenario/reproduction steps so that your bug report stands up to scrutiny. The problem with discussing bugs ahead of logging them is that it introduces ...


0

so, just out of my mind... error of data format(works for all data, always, always useful) wrong number of decimals(12,5868$ shall not pass) wrong account number(i.e. properly formatted, but does not exist). Both origin & destination account not credited enough. This one can be the source of many tests. Take the money, send it back, take the money ...


5

I think, it is always good to discuss things in person. You are lucky you have that things going on at your work place. In many companies all communication happens only via a system and that at times creates lot of confusion. What you write and what the other person understands may be completely different. For things like developers don't consider the bugs, ...


2

Since I work at a team that doesn't have specific requirements for projects, I always communicate it with the developers and showing them how I reproduced the issue. They will acknowledge it. Sometimes they would say, let me check on that.. Coming back, they would say, oh I have fixed that please test it. Before they can fix it, I have already documented the ...


3

If my dev counterpart is available I try to talk with them first. That gives them the chance to request extra information that I might not have thought of. If my dev counterpart tells me that that area is not ready for testing, I tell them I will enter a bug just to remind myself to come back and look at the area once they believe it is ready. If I hear ...


4

It depends. Some of the factors I've found impact whether or not I report something formally or not: Development Methodology - If I'm working in an agile environment I'm more likely to work informally with the developer at first. In a waterfall environment, I'm more likely to report the issue because the developer has probably moved on to something else, ...


4

My view as a developer is that even if you are unsure it is a bug then report it. The upshot of this is (some of this has been mentioned by others) If you are unsure if it is a bug then you do not have enough product knowledge to perform the testing. This could be for several reasons, including partial training, poor documentation and insufficiently ...


4

If it is a clear and obvious breach against uncomplicated acceptance criteria, then report bug as soon as possible. Feel free to bypass the developer, BA or product owner. Otherwise, do not report the bug unless you first talk to the author of acceptance criteria (eg: BA or product owner), and the developer. If you do not: it is possible that you will ...


6

As a corollary to what David said, testers have the same memory limitations that developers do. If you don't log the bug, chances are very good it won't get fixed. This is especially true if it's not a severe bug, as chances are very good that the developer(s) are working on fixing severe problems first, and won't fix less severe ones for a while. And by ...


11

Do not discuss defects immediately with developers. Mainly because context switching is bad for their focus and could take up to 5-30 minutes to recover from. How to communicate a defect depends in which stage of development the defect is found. When I find a defects during testing of a task of the current iteration then I document the defect in the ...


5

It depends... What is the overhead associated with reporting a problem? Some organization have big enterprisy processes, that requires lots of clicking, mandatory fields and multiple actors between the time a problem is open and the time everyone is done with it. You might also loose sight of important problems if they're drowning in a sea of minor (or ...


7

Should Testers first discuss the bug with the developers before reporting it? From my experience in several different organizations I think the answer given the current question details is "it depends" It will depend on general factors such as: size of company size of development group current deadlines location of developers industry development ...


4

Definitely make a ticket. If the bug is "don't fix", you can refer another tester or developer who finds the same bug to the existing one, and save the developer some time. If the bug is a quick 5 minute fix, it still takes 5 minutes to do, and you have to remember to properly re-test. If these little distractions add up and are not documented, things ...


45

As a developer with 15+ years experience, I'd say: please report the bug. I'd much rather have a ticket in the tracking system than a vague memory of a hallway conversation, or an interruption of what I'm working on. As Joel Spolsky put it: At any given time, I can only remember two bugs. If you ask me to remember three, one of them will fall on the ...


4

If the tester thinks that it is a defect, most likely it is a defect. The developer may be correct that the process is working as intended, in that case the defect is possibly in the documentation, user interface or testing plan. It should be logged, even if is testing error. This will lead to better determining where documentation deficiencies exist.


4

If there is possibility to discuss the bug, it could be valuable, for example you will have direct information of the cause and who will be the assignee of the bug. But generally it is not mandatory. It could be done as well after the bug is reported. Does not matter if you discuss the bug with developer or not, probably you will have to report the bug ...


7

I imagine this would depend on the bug being raised. If it's a glaringly obvious bug (pages not loading, basic function not working, etc.) then I wouldn't waste a developer's time confirming it and do a write-up. However if I come across something that may be considered an edge case or I'm unsure of the intended functionality (mostly found during negative ...


11

We prefer to talk to developers first. Then, we together decide if detected error is a result of some quirk in processing and not even worth of bug, or, if it is worth a bug, we negotiate who will enter it to Bugzilla (we call if "buggify the feedback"). Often, developers prefer to write the bug description, because that way they can better describe the ...


14

In my own experience, I've found that this really depends on the culture of the team or company that you're working with. On a team with good communication skills, and where everyone works together well, you may very well be able to just tell the developer about it, they take a look at it, and say it'll be fixed in 5 minutes. If it's longer, maybe ...


2

Here are a few techniques I have seen used. ACH is a loose enough standard that an ACH that works for one financial institution will not necessarily work for another. If you have a particular financial institution in mind, they may be able to set up a test account for you. You can use ACH to move fictional amounts in and out of the test account. Lacking ...


0

Forward Proxy Performance Performance Performance can mean a lot of things. The least interesting but most widely cited benchmark for this kind of server is “how many 1k responses can it serve from memory per second?” but that doesn’t tell you how it will do serving 200K (or 200M) responses from disk, which is a much more difficult thing to manage. Try ...


0

Boundary Analysis work Example:Q In an Examination a candidate has to score minimum of 24 marks in order to clear the exam. The maximum that he can score is 40 marks. Identify the Valid Equivalence values if the student clears the exam. a) 22,23,26 b) 21,39,40 c) 29,30,31 d) 0,15,22 Solution: The classes will be as follows: Class I: ...


0

Testing is a full fledged activity which goes in parallel. They are like tracks of a Railway line, going the same direction but not intersecting with each other. It's possible to have QA professionals who are well versed in coding and likewise Developers with a good instinct for QA. If I were in your place, I would consider dev and coding experience as a ...


1

Do you guys have a specific person that does Automation? If not, I would highly suggest you begin looking into Selenium since you guys are webapp-based, depending on your comfort level with coding you could start with just using the Selenium IDE and using the record function and move up to Selenium Webdriver from there.


2

Suggestions: Work on your writing and communication. You've asked two questions in your post, but haven't used question marks. Ellipses have three periods. Learn the difference between its and it's. Use an active voice in your writing. Speak to people more than you email or message. Conversely, don't socialize too much or waste other people's time. Find ...


1

qa_test235, I noticed that your are an unregistered user of this forum and I am not sure how this affects your ability to participate. Become a registered member of Stack Exchange and participate as you can in helping others learn about SW testing and quality engineering. This activity may seem unnecessary or maybe a burden. Over time this will add some ...


1

Test automation and push toward continuous delivery is slowly but surely reducing the need for manual testing. Learn BDD and other means of how to ensure developers' are writing good automated test and satisfying business needs. To go even further, learn how to write test code yourself; QA experience and knowing how to code will make you stand out from those ...


2

Are you recommending the best/most appropriate way to test a problem? Are you thinking of scenarios or perspectives others arn't? Are you making sure you are seen as a valued asset within the team and not just a rubber stamp? What I must stress though, is that there is no "quick fix". The main thing is to build up trust and respect within the team. ...



Top 50 recent answers are included