Tag Info

Hot answers tagged

19

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


17

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


15

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

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


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


11

An answer - as Phil implied, is that you take every record and playback tool you can find, and burn them in a fiery pit of despair. I probably got myself a down vote for that, so I'll try to earn it back. Good Agile teams test constantly - not just at the end. If you include test design as part of feature design (and consider how the feature will be tested ...


10

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


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

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


9

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


9

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


8

I second (third?) the congratulations! While I'm nowhere near as experienced as Joe or Bruce, I can offer a few tips from experience: Communication is critical - you absolutely must have at least an instant messaging application to talk real-time with your team. That application should also be something your development team is using since you want your ...


8

Without being flippant, this sounds like you've got a serious communication problem in the team. Given the limited timeframe, here's a few things to consider: everyone in the team needs to know what a good bug report looks like everyone in the team needs to search for a bug report on the issue they're seeing before they write up a bug report. This means ...


7

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


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

It really depends on what you're trying to achieve with your automated tests. The answer should drive your approach. Are you trying to: reduce regressions? reduce the amount of repetitive manual checking your testers have to do? (This may be the same thing as reducing regressions.) please a manager with some magic numbers? Some ideas: Test first. Make ...


7

It depends, and there are no industry standards. Seriously. Any metric can be gamed (and will be, if you use it for assessment). I'm not aware of any standard approaches, not least because the teams are - or should be - evaluating themselves regularly and looking for ways to improve their own processes (if they aren't then they're probably using ...


6

In my opinion, there aren't any extra skills need to test a stable system. What tends to happen once the system is stable and not under continuous development is that the proportion of time spent on exploratory testing drops compared to the proportion of time spent on regression and checking. I'm assuming here that by "stable" you mean that the requirements ...


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

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

The role of a software tester in an agile environment - as with any other environment - is whatever it needs to be for that specific project. Sometimes there'll be a lot of close-up work with design as well testing (I personally think of design as the testing that happens before you start testing, because that's where a lot of the potentially problematic ...


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

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


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

There's a few extra factors here that can impact the way you handle this problem: Do you get results for each test as it completes or do you have to wait until all tests complete? Do you have multiple machines on which to run the tests (and is it possible to do this) or are you tied to a single system running your tests in sequence? Can you break your ...


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


5

I would start with what you have, the inputs and outputs, then start questioning. I like to go through a bunch of what if's, such as in your case "what if the database is unavailable?" or "what if the mail queue is full?" or something like that. If you can't come up with questions like that, then ask the developers "what didn't you test that you think I ...



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