55

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 floor ...


44

I would operate under the assumption that your developers are documenting this somewhere, since I would also assume that they are good developers who care about good development practices. As a developer myself, I strongly believe that developers should be expected to describe what they've done in a language other than code. It doesn't have to be ...


36

In my personal opinion, I think this theory is flawed. As you stated, there are so many variables that come into play: % of escaped defects treat all bugs as equal, but they are not. Some bugs are more critical and some are merely cosmetic. If they really want to go with % of escaped defects, they had better find a way to properly and accurately weight a ...


31

There doesn't seem to be a lot of research data on this; this is what I found: Waiting for builds: This article about "Why software testers can't test" quotes a survey from IBM (The Future of Testing: Where Do Testers Spend Their Time? 2014): 59% of those polled, the largest percentage for all the available choices stated that the one activity they ...


30

Measure it. Pick a test area, measure how long it takes to test manually, then measure how long it takes to test with automation and how long you spend maintaining your automation. (There are other things you could try to measure too, e.g. bugs found manually vs with automation, but they can be hard to quantify.) If automation is better, you'll have ...


29

As Yu Zhang has said NEVER perform security tests without consent. There are no exceptions to this rule. You need to make it clear to the team member that senior management would be justified in firing him for his reckless actions. For that matter, your customer could choose to take legal action against him including criminal charges. That said, there are ...


25

Disclaimer: this answer is purely based on personal, anecdotal experience. In my 10 years as a Software Developer, I have known 4 different situations: no tester (besides myself), tester in another team, large delay (weeks), tester in another team, short delay (hours), tester in same team, short delay (hours/days). Note that Unit-Tests were always on my ...


19

"there is nothing to test" That is a strong statement. I like to use James Bach's definition of testing: Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: questioning, study, modeling, observation, inference, etc. So, unless there is nothing new to learn about ...


18

Seems that your boss (correctly) understands that to write automated test takes longer that perform the same test manually once, and is concerned that you will spend so much time automating you will not have time to do manual/exploratory testing. Tests are code too and needs to be maintained too, adapting them to the changes in the application. Value in ...


18

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 ...


17

As others have said: code review. It is not uncommon for code like assert true == true to be used as a placeholder during test automation development (I personally would use assert true == false or assert fail or similar as my placeholder so my code could not pass until I was ready to write the correct assert, and so there was no chance I would forget the ...


15

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 they'...


14

Security tests should be only executed with a written customer's consent. Your team member's intention might not have been malicious but due to its highly sensitive nature of software security, all security related testings must be executed after acquiring a customer's written consent. In some countries, owning security testing tools is not legal. The ...


14

Request a meeting between upper management of QA and DEV and explain the goals of what you are asking. I think the description you provided in the question is a good start at explaining the why of the ask. This additional information, for instance, may help a tester to find similar issues in other parts of the application or can provide ideas for ...


13

It depends What matters is that you are able to effectively communicate the current state of the software in test to your leads and management. How you communicate that information will depend on your workplace culture and any regulatory requirements your employer needs to meet. The biggest potential issue I see with the way you are currently communicating ...


13

The short, simple answer: No The slightly more nuanced answer: It can be, but you have to be very careful The real explanation: Like most other candidates for tester performance KPIs, escaped defects is dependent on the activities of too many other people to be viable as a simple measure. Unlike something like words per minute or accuracy on a standard ...


12

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 ...


12

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 ...


12

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, ...


12

Proving the ROI of automated testing is hard. Teams that do refactoring to keep code lean and mean do have a high demand for test automation. Watch the first episode of Clean Code, it will give you and your boss insights about why projects slow down and how bad code can even kill companies. His solution, CleanCode! and clean code is well written code with ...


12

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 ...


12

TL;DR: Devs write own unit tests. If you want different eyeballs to look at the unit tests code, code review is the answer. EDIT: OP clarified question: it is about e2e tests. For e2e tests, using separate team of developers is possible but adds different kinds of challenges. Added to the bottom. Related question: How does a tester's perspective towards ...


11

The fact that this thing happened means that there is something wrong in the security testing processes inside your team. At least, there should have been an agreement/consent between both parties - a team that does the testing and customer itself. Some of the practical things you can do to prevent this from happening again: improve education and awareness ...


10

What value is "yesterday, today, blocking" to this team of testers? Presumably, they have similar scrums where they present the same information to the functional team they are assigned to. So you may be asking them to repeat what they have just said, or will soon say. Perhaps you instead want to focus your meeting on "what is important for other testers ...


10

As Bookeater says, you absolutely want to unify tools and processes between the teams. That said, I'm going to offer some extra advice because I've been in this situation (and to some extent I am still in this situation). Hasten slowly - Each team has built up a process and toolset that works for them. A newcomer telling them they have to change everything ...


10

I am definitely using the test pyramid as one of my 'guidance' tools. I frequently combine it with the 4 Agile Testing quadrants in talks and presentations.                                As Niels says this ...


10

You're going to get all kinds of recommendations on QA team sizes, from zero to twice the number of developers, or higher. The right number for you depends on what you need to test, what kind of testing your developers do, and how solid your software needs to be. My experience is that small teams -- no more than a handful of people -- are more effective ...


10

There has to be some sort of pain point to make Management and front-line employees aware of the need for testing. How your company does that depends on how mission or life-critical the software truly is. The typical Developer/Tester ratio in an unregulated development shop is anywhere from 4:1 to 8:1. NASA uses a ratio of 1:8. That's right, each Developer ...


10

In addition to some of the other suggestions, you could consider a few other options: Build/run load tests for new/recent work (given the maturity of your test automation you may already have this under control) Review existing test automation for obsolete or ineffective tests (You have no idea how much I wish I could reach this point) Review and refactor ...


9

Eduard, welcome to SQA. I will assume you are that developer. I think there are a lot of ways a developer can help a QA team. The most obvious way to help would be to write automated tests or to write tools that make testing easier, e.g. creating test data or automating a deployment. You may have skills outside of coding that would also benefit your ...


Only top voted, non community-wiki answers of a minimum length are eligible