"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 ...
Get a good Scrum Master who can convince the organization that Scrum teams should not be depended on other teams to deliver shippable software. It is an impediment he/she should resolve.
Traditional Organisations want the benefits of Scrum without changing their ways. Even for great coaches, this could be a process of years. Don't give up. Be bluntly honest ...
If you have an automated regression suite, you should definitely re-run it. If your organization is really on the ball, this will happen automatically along with all the unit tests and other tests as part of your continuous integration process.
If you don't have that luxury, then if you don't see a major risk, then testing only around the areas that ...
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 ...
I've tested in the sprint + 1 system under the SAFe framework. The framework does not specific this but lends itself to doing it for organizations coming from waterfall.
Mu suggestion is:
Your questions of
Does one need 2 Definition of Done? When does the PO take the item? Does he take it off twice? How much buffer does the deployment team ...
Automate a test in the simplest way possible
Automate another test
Repeat and evolve into a robust framework
Your plan sounds traditional and will probably result in a lot of research and over-engineering. Start simple and let your tests form around your application and business. Tackle uncertainties as soon as possible. Don't make your plan ...
Welcome to the site!
Your situation might be a difficult one for a couple of reasons:
you're new to the testing and you don't know much about the process,
about the technical stuff, and about yourself in such a situation
you're the only one on the team who is supposed to test; I find this the biggest obstacle because you basically have nobody to ask for ...
It really comes down to who is consuming the information contained in your notes and what that information will be used for. If your testing found a bug, for example, you would likely want to write up steps to reproduce, information about your environment, and other information that would help find and fix the bug. If you are reporting on what you tested to ...
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 ...
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 ...
Why? In some ways the answer is quite simple:
Different testers have different backgrounds, experiences and motivations
To dig into this more however, here are the areas to address in light of that with the goal of improving things - probably the main goal of the OP asking this question and other readers of the question.
If folks do not ...
It depends. What are the the risks?
One of the risks that come to mind are code-depencies. A fix in a piece of code could be used in a lot of location. Not just the location that the original defect occurred in. In this case you should analyze the code and decide if you need to also re-test all dependent locations.
When the application could endanger lives ...
Use tests to drive code design.
This is the difference between using tests as quality checks, post development instead of using tests to uncover and drive the design up-front.
"Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don’t improve it. Managing the Unmanageable. Steve ...
Classic testing is Quality Assurance
Agile Testing is Quality Engineering
Traditionally most testing as done at the end of the development. It asks if the product that has been developed meets the requirements, both explicit and implicit.
This field is primarily concerned about automation and automated tests.
You should consider to keep them simple and use any data for analysis during the timebox to see where to explore next. The charter is just a mission to get you started, not a detailed work assignment and reporting tool.
I like the format ckenst proposes in his writing exploratory charters:
How to Write Exploratory Charters
This is based on "A simple ...
If you have a set of Regression Tests, testers can start automating them starting with which are easiest to automate. This will save you a lot of time in the long run during Regression Testing. Of course, this requires some programming skills and if the testers do not have those at the moment then this is the great time for them to learn it and apply to ...
Should we take notes in a simple text file or should we take it in a
fancy Excel sheet?
I am used to carrying a notebook with me, It's my childhood practice. I believe as a human being I can't remember every point, I discussed with the teammates. I have all the things with me like a personal digital assistant, laptop, desktop, Personal Server,
As I see this, you've got several problems here, all of them communications problems.
You are not communicating to your clients what known issues are in each sprint release. This leads to the client teams finding bugs that you already know about, wasting their time, making you look less capable to your manager, and wasting your time.
Your clients are ...
Now QA is not the only person responsible for the quality of the product, instead QA's are taking up the role of a person who drives the quality process inside the team. Some things which you can do/introduce to improve your and your teams efficiency are :
Educate the whole team about the importance of quality and also that QA's are not the sole person ...
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. ...
I recently read quite good blog post from Michael Bolton, where he used James Bach's Heuristic Test Strategy Model to generate test ideas.
That blog post has 5 parts, so do not be discouraged on first two parts: Exploratory Testing on an API? (Part 1)
The cynic in me feels that if developers could be relied on to detect & fix their bugs as they go along then separate testing teams would never have been invented in the first place.
Much zealotry in this thread...
Speaking only about the testing aspects:
Obviously, you should only re-test of the part where there were bug fixes.
The problem is to identify such area.
One can do it:
Backwards: E.g., frontend components that do not feed from a service X will be less impacted by changes in X.
Forwards: E.g., if you change service X, frontend components that feed from X ...
I found myself in that very same position last year. With a team of around 12 devs and only 2 QAs we used up all our time testing features and couldn't do the (IMHO) more important work of improving processes, making our test infrastructure better and also carrying out some more long term initiatives that would improve things from a quality standpoint. Plus ...
As part of Test summary, collect all required information on the testing performed, This will help to prepare a sound Test summary report. Lessons learned can be explained in detail, which will convey the responsibility which was taken to solve these issues. also, this will be a reference for upcoming projects to avoid these. Similarly, mentioning the best ...
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 ...
Ranjeet listed pretty much every point, my 5 cents :
First priority should be given to Business Value, followed by security vulnerability, complexity and usability.
But one think to note is, QA's should never negotiate on the exploratory effort.
Exploratory testing is what helps a good tester show his value to the team. Developers and product owners ...
Trust your feelings, Luke.
Seriously, the scenario you described is an anti-pattern. They simply are not ready to let go of waterfall. They are probably concerned about the panic among test leads and managers and testers themselves when they realize that their services as they currently exist are no longer needed.
But this is really a binary thing. You ...
This is a pretty general question. It depends on a few factors. Here are some questions to consider:
Do you have any test automation?
Is the feature/area of bug fixes a critical area, possibly creating more risk?
What is the scope of the bug, feature, area of test? What other features/areas does this touch? Is the code being fixed a shared function or class?...
Simply, the term "shift-left" means integrating QA early in the development cycle. Another way to think of it is: test early, test often. Shift-left ultimately advocates for Quality Assurance over Quality Control.
With traditional waterfall development, QA and testing didn't start until after development was finished, often the bottom of the waterfall. If ...