I work as QA engineer whose responsibility is primarily testing the functionality of a financial web application and database testing to some extent.
I have miss some critical defects in the past builds and let those slip in production environment. Customers have reported many serious issues and all the blame is indirectly on me.
I think my approach is not good and I just test the happy path. I don't use out of the box thinking.
How can I deal with this?
Feeling guilty doesn't help your company ship higher-quality software. Instead of feeling guilty, use those escaped defects as signals about what you could learn next.
It sounds like it would help to find a mentor: either a more experienced QA engineer or even a sympathetic developer or manager. If you can't find a mentor at work, you might try looking outside of work, e.g. at meet-ups. If neither of those is an option, consider moving to a different job where you have better opportunities to learn from others.
Directly answering your question: NO,(serious) defects found after the release are not the fault of the tester alone! Any company thinking that way is a company I would leave ASAP.
Having said that: improving your testing and sharing what has been tested and what has not been tested is a first step in communicating what actually has been done when testing. Deciding whether an application is ready for release should be based on proper information, and in my book, is not the responsibility of a tester.
But, checking only happy paths is in general not really a satisfactory approach. Changes are the developers already tried that one. So your job is trying to think of ways the program could fail. What can go wrong and would be a real problem for its use? That all depends on your context. Ideally, and I work in an agile environment, you as a tester are part of the team developing the application, so making sure things work as expected could (and should) be a joint effort!
Go read blogs, like this Michael Bolton - "Testing is". And see the blogs from James Bach and there are many more sources. Try this to guide your thinking using the Testing cheatsheet. I often use the Heuristic Test Strategy Model - HTSM to create models of what might need attention.
There are active test communities, like Ministry of Testing, I consider myself being part of the Context Driven one. Online courses exists, sites with examples to test, like the test puzzles to help hone your skills.
Go learn and improve. Don't feel guilty. Mistakes can be a blessing in disguise if you act on them, and learn from it. Good luck!
I've been in the industry a long time, since the late 80's and I remember one thing that has stuck with me that I heard early on: "You can't test quality into software you must build it in." I was younger in those days and my first boss was on the old side (probably as old as I am now :-) It didn't make much sense at the time, but as the years rolled by it really started to make sense. What he meant was, it a process that completes a software project. Everyone has a stake in Quality. This is in no way excuses you from missing something major, quite frankly that shouldn't happen in this day and age. Back in the day we didn't answers at our fingertips via boards like these, nor did we have tried and true open source testing tools at the ready. Happy path isn't even 1/10th of the equation. Platform, edge, boundary, stress, performance, I could go but you get the idea. Remember that you are building a software application, I've seen teams get bogged down with documentation, let the app be your documentation to an extent. Have the app open at every meeting on the wall, even if it's just the landing page, remember that is what you are developing. For you current situation the best thing to do is 'peer review' your test cases with the team, the entire team if you can. Another cliche I remember is "Individually we are imbeciles, collectively we are genius." The synergy that is created when a team collaborates is an awesome thing to experience, ultimately it results in better app. People that are paid big bucks to "team build" can't come close to that feeling. And check your ego at the door <<< this is probably most important. Everyone has a stake in quality and everyone should be involved in the process.
You should improve the way you design your test process. First you should formulate a test strategy where you write down the entire test process as general as possible. Then you should prepare your test cases using the entire toolbox, equivalence classes, decision tables, state diagrams and make sure you test any critical input. If any of those concepts is unknown to you I can only recommend reading up on the ISTQB foundation level syllabus.
When you have all your test cases as well as the general workflow in writing you can go and get it signed by management, ideally have a meeting with the developers, they usually know where the most vulnerable points of their software are. After that you just need to follow your test documents and if some defects still slip through you know that you tested anything feasible and neither you nor management or development thought of anymore cases.
In my experience with enough time you develop an intuition for your application and many of those formal steps can become more natural but especially at the beginning writing down your approach and getting opinions on it is quite invaluable.
Have you gone back & reviewed the defects that slipped through?
Use the mistakes as an opportunity to learn & improve going forward.
If it was something off happy path then you know new areas you need to test? or did the UAT testers have different data that you don't have that shows issues you can't catch with the test data? Are you getting a full accounting of changes & code changed so you know all the places to look? Do you need additional training on the application?
There may be different answers requiring multiple solutions. Pick one & start, and keep improving from there.
Well, in my perspective QA cannot be blamed every time some mishap happened in production. A lot of factors play a role when any issue which is observed in the production environment but not on QA or staging.
Factors Like
Environment set up is different.
Infrastructure is different like QA or Staging are on premise and Production is in the cloud.
Certain stored procedures DBA forgot to execute as part of Release.
Deployment is not proper.
Other integrated system is not behaving properly or providing the proper response.
As you mentioned, you just focus on the happy path then there would be blame as it's QA's responsibility to cover all possible path, so next time you better cover all the possible scenarios/paths which will help you to reduce the production issue.
Top software testing companies follow a systematic approach to deliver a high quality product. Below are some of the points that can be beneficial for you to ship a bug free product.
I can understand feeling a certain amount of guilt about issues making it out to production. However I personally feel like the overall quality of a product should not be owned by an individual QA but by the entire team instead. A lot of the "shift left" methodology addresses this.
some of the things that we've done:
This would likely take buy in from all stakeholders though. Good luck.
I think the moniker Quality Assurance is misleading, at its core. I can't really assure that only quality code is going out the door anymore than any other person can make sure there are no defects. The extreme view of this is that I don't put in any defects at all, since I"m not writing the code generally - but that's not all that helpful either in an organizational context.
I like to think of my role as Quality Assisting (I shamelessly stole this from Atlassian) in that I am there to identify risks and mitigate any major failures but Quality is really the responsibility of all team members. I facilitate that process and if it comes to it, ask the hard questions and push for the answers that I think the end users I advocate for deserve.
Don't let major defects wear you down - it happens to the best of us, and there is no way anyone can guarantee perfection.
I work as QA engineer whose responsibility is primarily testing the functionality...
QA Engineer as describe by payscale (which came first in my google search ???) Job Description for Quality Assurance (QA) Engineer. A quality assurance engineer creates tests to find any problems with software before the product is launched.
I have miss some critical defects in the past builds and let those slip in production environment. Customers have reported many serious issues and all the blame is indirectly on me.
I think my approach is not good and I just test the happy path. I don't use out of the box thinking.
So as defined, Create tests to find any problems. As you mentioned (highlighted), those problems were Critical and YES your team will blame you why you missed that critical bug. In my opinion these are some of the things that I consider when testing
Reading your question only, no individual should be blamed for any defect. There has to be a process for continuous improvement and should be mandatory adhered. Once its rigorously in place there wont be any blames automatically.
The answer depends.
It is true that the testers will be blamed if a client finds issues as tester is the end user on Company level.
But the team should understand that Unit test plays an integral role in Testing. If developers perform proper Unit testing as per scenarios and explain flow to the tester, testing team will design test cases based on that.This will help Tester to understand the product and think Out of Box.
This is the job of Team Lead or Project Manager to check completion of testing
