Hot answers tagged agile-testing
18
it makes the higher ups really happy to see results, and the winning
QA members get lunch.
Since you have set the system up so that there are "winners" and "losers" based on bug count, it's not much of a surprise that testers are trying to find a way to win. You are focusing on the wrong goal. You have basically told them that the goal is not improved ...
15
This "standard" is being created in the face of direct and repeated pleas by citizens of the Context-Driven testing community to cease and desist.
Whatever this thing says or is based on, it will not be based on a truly representative community of testers, nor will it be based on research that passes muster among competent social scientists.
It's yet ...
13
I would suggest that you go back and do those unit tests when you are required to refactor that area of legacy code. The approach for do this is described in this question.
When you are working with legacy code with no unit tests, its the same principle and techniques to add them regardless if you are doing TDD or not.
I highly recommend Working ...
11
Bug hunts should be fun and productive for the entire team, and a little professional competition can go a long way to improve moral of the entire team and help them grow.
This is a rare case that I slightly disagree with Joe. I also like the idea of a point system.
But would expand to include:
Everyone is involved in the bug hunt; not just testers. ...
10
Ideally, the DoD for each user story should mean all tests for that user story are passing, and all automation is completed, running as part of the overall automation (as opposed to on one person's machine), and running with no errors.
Real world usually means compromises, since there's rarely enough time or resource to cover all the potential implications ...
10
Who would be administering QC? If it's going to be you, I'd recommend you give it a miss for now. I don't think it's particularly suited to small teams, or Agile teams: it's aimed at large companies, with waterfall development methodologies, and pretty much the whole design is aimed at that - you might find yourself having to swim against the current a lot ...
9
One of the most common problems that I've faced is the role of the tester. Often times, teams/companies start to believe that an agile approach using TDD eliminates the need for testing. My first experience with it was when of my former teams was told that they were going to become an agile team. Agile Testing by Lisa Crispin and Janet Gregory helped me ...
9
Craig, I have been working in a similar environment for 6 years. DEVs and QA are on the same box, using the same code which is constantly in flux. DEVs check out a program(s), update & re-compile while I am in the middle of testing. At first, I was very frustrated as you are. When possible I do create my own "sandbox" (db only, not actual program) but ...
8
Agile Testing
This is the (IMO) canonical book I refer people to in this situation. It's a fun book to read, and gives you plenty of ideas and context to start with as you transition.
8
I've been the first tester on a team before and seen how they've tested their software before (usually doing a very good job of it as well). For as small as you are, I think that you're on the right track for the most part.
Creating automated tests as you go is great. You may find some benefit to some TDD approaches which ask you to create the tests ...
7
HP Quality Centre is a product that has been around for ages. I haven't used the product in anger for a few years, but I don't think that it is particularly tied to any methodology.
HP's tools are generally pitched at the non-techical tester with record and playback and step-by-step test execution, especially now as WinRunner is now end of life.
As someone ...
7
I remember a couple of years ago sitting in a session about Exploratory Testing in regulated environments and having the same question: how can you use ET on environments requiring strict documentation of the tests being done and more-over auditing the traceability between requirements-design-testing-issues-verifications-etc.
Then I heard the explanation ...
7
After reading your account, I have a few questions. They might sound harsh at first, but your account sounds to me like you're in an organization that has to consider some harsh realities.
1) Is it the complexity that's a problem here, or is it your reaction to the complexity? (Along with your organization's apparent lack of reaction to the complexity?)
...
6
Ideally there should be a regression or "hardening" sprint before the project ends, and in the dream world, a hardening sprint every few cycles.
I'd suggest that automated tests of the steel thread of the sprint be developed as the sprint progresses, and any bug fixes get an automated test as well. This way, you build your automated regression as the ...
6
Welcome to SQA, FJFG. As Bruce McLeod once wrote, "There are no 'best practices', there are only good practices in context." A good practice for you will depend upon your context. I will suggest some contextual considerations. You may be aware of others.
Your primary job, or at least your initial job, is to own and convey business requirements. Those ...
5
I've worked as a solo tester on a small agile team as well, and I've found the two things that help most with regression testing are automation and risk-based test prioritisation.
Having an automated test suite with good coverage is definitely very helpful. However, I wouldn't recommend relying entirely on automated test for regression, as there are some ...
5
The elephant in the room: maintenance.
How do we maintain this new feature:
what things need to be configurable?
can we easily roll this out (what's the roll out?)?
what support tools do we need to resolve issues with this in production quickly?
I worry that one day all of humanity will be maintining code of our forefathers...
think of the children!
5
The main challenge with any waterfall style testing is that you are increasing the time between the defect being introduced and the the defect being found, and the closer you can bring these points together, the cheaper the defect is to fix.
My recommendation would be that you split your testing and do some in the current iteration and some in the catch up, ...
5
Answering your second question first: yes, you absolutely need test case design standards. They don't have to be monsters. As with all things agile, they need to be enough.
For your first question there's no "right" answer, but I can give a few guidelines. Your standards should be based around a kind of test case triage: first priority is being able to set ...
5
Not saying that it's cheap, but, tools like OneNote tend to fill this void very well. We use a notebook for each application. For projects, we use Tabs/Sections for Modules/areas, and for operational type changes, we use a new section for each Release. Each session takes up 1 page. These get stored on either a sharepoint or in a shared folder that we all ...
4
At work we are using the HP QC. It is a very powerful tool but I would use it only for really big projects. I think that it is not suitable for small/media projects. The projects I am working has 17 teams and more than 160 people and this tool is a corporate decision and not the result of an analysis of which tools are available.
4
I think the key here is to realize that documentation is no longer a task when you are in a regulated industry. It is now a released feature, with interested clients and external stakeholders that you need to satisfy. You should treat it like a user manual would be treated on a non-regulated project.
For our team, we deal with externally released ...
4
This is the exact problem that bedevils the environment where I work, and have yet to find a strategy that works well and consistently.
Some of the strategies and techniques that help are:
The testing specialist works with the coding specialists on the unit tests. Even if the testing specialist isn't a coder, knowing the coverage of the unit tests and ...
4
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 ...
4
I assume that you have a suite of unit tests the developers are running which is essentially your first line regression suite.
The purpose of a functional regression test suite is to help ensure that code churn didn't destabilize existing functionality, especially across dependencies. In general, the functional regression test suite should be ran every ...
4
I see design of requirements (user stories) and test cases (acceptance criteria, scenario's) as a collaborative effort of business analysts, developers and testers.
BA typically kicks of with the initial user story and acceptance criteria.
Further elaboration (conversation, architecture meeting, story analysis,...) may
- split the user story
- make ...
4
"The answer to any sufficiently complex question is, It Depends"
In this case, I think it depends on where you work. Where I work (msft), I don't manage people, but I am at a fairly high "level" within the organization. I choose not to manage people because it allows me to do more of the work that I enjoy doing. I've never been a consultant, but I'm told my ...
4
Use whatever you are comfortable with. I'd suggest starting with something basic for recording notes like Notepad++. The important thing is to be able to keep detailed notes about your session, to setup a session charter, etc. Once you've got some practice with it, you can see what works and what doesn't.
I've used Rapid Reporter and Session Tester as ...
3
No. It's too late for the tests to affect the design, so you can't get the major benefit of TDD.
What you can do, however, is to write tests as you work on the code. Say you've got a method that's too long. Write a test of a little piece of it, assuming that little piece had been extracted into a new method. Now extract that method. Or say a bug report ...
3
The key question is can you afford for it to go wrong?
And the answer to this quite often is dependent on how quickly you can fix the problem if it occurs - debug it until it works in production. While not a nice place to be, for some things that once done, should never need to be revisited you can get away with having no tests.
If your business / lives ...
Only top voted, non community-wiki answers of a minimum length are eligible
