Hot answers tagged test-management
12
Dedicated Testers
I think that it is important to highlight that the role of being a tester, is different to the job of being a tester.
There are many situations where you need testing, but you simply can't afford or are unable to have dedicated testers, i.e people who have that job 100% of the time.
You simply don't have enough testing, or resources to ...
11
> The integration tests can sometimes take a long time,
> thus discouraging users from running the entire test
> suite prior to checking in
For the checkin-runs you can mark the long-running tests with their own category
and tell the test-runner to exclude those long-runners
You may also look at Is there a way to separate long running (e.g. ...
10
Welcome to SQA, Rosa. I am not sure your question makes sense; QA is an abbreviation for "Quality Assurance", and often is used as a synonym for testing. ISTQB is a type of certification for testers.
See also Do ISTQB/ISEB Testing Certificates prove someone can test? and http://en.wikipedia.org/wiki/Caps_lock.
9
Solution Overview
To solve this problem, you will want to intelligently select a manageable set of combinations based on a pairwise coverage approach (explained below) or a more thorough variation of combinatorial test design.
Glowcoder and user246 have good points. I particularly like testerab's comment for reasons that will become clear in a minute.
...
9
I always want an independent, dedicated, competent tester to test my code. However, I also always want a personal chef to cook for me. I usually can't afford that, either.
Most developers have not worked with a truly competent tester, and so they don't know what that is like. For me, the few times I've had that, it was great.
Having an ...
9
Automation is using software to test software. Testers use automation for the same kinds of reasons that other professions use automation: to do things in a more reliable, repeatable way than we could do with people.
There are other reasons why you might use automation. For example, it may save time and/or save money, although if it is done in the wrong ...
8
The problem here isn't white-box testing. The problem is that there is no specification. This is where domain knowledge and product familiarity really matters. A tester who just tests that the code does what it was intended to do (from the dev's point of view) by reading the API could very well miss a variety of issues, such as a business requirement that ...
8
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 ...
7
There's an excellent series of articles about test estimation that everybody involved in producing or using test estimates should read:
Project Estimation and Black Swans
(Part 1)
Project Estimation and Black
Swans (Part 2)
Project Estimation and Black Swans
(Part 3)
Project Estimation and Black
Swans (Part 4)
Project Estimation and Black Swans
(Part ...
7
So if I understand your question correctly, you are reporting a test as passed even if it fails later, because you are going to do another test phase.
I think that I need to share some tough love. This method is wrong, and could be downright dangerous to someone's career.
The reason why is that you simply don't know what state any particular build is in. ...
7
My perspective is - This question is more related to identifying charter / vision for the team based on current state of the Team
You have to assess your current test process, tools, bugs, automation, product quality to arrive at areas of improvements
Your proposal for roadmap would cover below aspects
Roadmap for Team
Team should have a roadmap to ...
7
You're asking a unicorn question.
Why?
Because you've skipped over the point of all that work. It doesn't matter what proportion of different types of testing you do, it doesn't matter what your organisation is, and it doesn't matter what technologies you use, if you don't know what information your stakeholders want to discover from your testing.
That's ...
7
I think you answer this by asking, "Why do I need a build acceptance test suite?" There is no universal answer, but if your organization has a suite, someone should be able to answer the question.
For example, in a previous job, the developers on my team frequently made changes that rendered the build unusable: it would not install, or it would crash as ...
7
If you're using C# you can include test case titles, descriptions, etc. in XML in the automated test case itself, then compile with /doc. The compiler will search for all XML tags in the source code and create an XML file.
Another approach is to use meta-tags in your automated tests and use those to produce a list of automated tests.
There are several ways ...
7
I'm going with my favorite response here: it depends.
Sometimes the decision is made because that's the language the tool supports. Sometimes the language is a flavor of the language used by the development team - this often happens where there's an expectation that the development team will be writing at least some of the test automation code. Sometimes ...
7
You should not edit the tests to pass. There are still defects in the product, and running the tests and having them fail on those points continues to provide data that the issues are not fixed.
Since the development team has accepted the bugs and scheduled (although not solidly) them to be addressed, modifying the tests to no longer report the defects ...
6
What you really need to interested in is testing each component in isolation.
Integration level and above becomes more challenging to test. If you are using automated tests then these cannot rely on putting data into a database and expected it to be there straight away. There is a replication time that you would need to wait which could significantly slow ...
6
The primary challenge that I've found when it comes to integrating automated tests with manual tests is the general lack of experience of folks writing GOOD automated tests. As noted in another post, there are serious problems with organizations buying into "record and playback" test automation. If an organization starts on this route and doesn't have ...
6
Ok, this is exactly the situation we faced in my old gig. Allow me to offer some advice...
First of all, think VERY carefully before you commit to maintaining test compatibility with multiple development branches. Think about it this way: Let's say you have a team of 5 manual testers, and one main dev branch to test. Then, the SW team announces they have 3 ...
6
RN.
You've got several options here. One is, as you mentioned, to reset the database before each run. That's probably a good idea anyway to ensure that you've got the same starting condition and the beginning of the run.
For the individual tests within the run, you can operate a simple counter through the run and use that to generate your business key - ...
6
The features of many software projects are based on customer stories. Stories describe a typical or target customer and describe how that person uses various features of the software to help them perform some desired task. It is also common for these user stories to have a persona (e.g. Jeremy is at a sporting event and uses his phone to take a picture, ...
5
Yes. They are vastly different.
Testing code to be used only by a captive audience has a completely different set of risks, schedules, priorities, impacts, etc. "Good Enough" means something very different for an internal audience than it does for paying customers.
The impact of poor quality has a completely different dynamic.
Very often, the budget ...
5
Your options here would be controlled by dependencies & overlaps between the two test cycles.
Analyze them first both short & long term -- resources,test infrastructure,test results,business impact
Then,as you mentioned that you can not run two releases concurrently, try and spot overlaps,see what work could be done which would help both the test ...
5
I like posting results online, and then emailing stakeholders only for failures. No email means everything went smoothly. If someone isn't sure or just wants to see what was run, then the full set of results is available online.
As TristaanOgre points out in the comments, testers need more frequent communication to be sure the tests ran. I would add that ...
5
There's no inherent preset relationship between development time and testing time. And there's no inherent preset relationship between development/test staff ratio, and development/test time ratio.
The time required to test something is contextual - it depends on factors that may have little or nothing to do with how long it took to develop that feature.
...
5
It is a good idea to explore automated testing, but it is difficult to create a system that will allow to you "press a few buttons or so to make sure everything's functioning as intended". Automation is rarely a complete or easy replacement for manual testing. Test automation requires a significant up-front investment and an ongoing maintenance cost. It ...
5
With something like this, that's huge and has no prior testing, I'd say that your first priority would be exploration (most likely manual) to both gather information and to determine the best approach to build regression for it.
I'd approach this way:
Manual exploration, focusing on independent clusters of functionality and testable material. Some of the ...
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
You might want to look at QAComplete or ALMComplete by Smartbear. We implemented it a little over a year ago for a team of 10 and are quite happy with our choice. We purchased the SaaS, cloud hosted version and were up and working with in almost immediately.
I've used QC at a past job and found it to be too big too expensive and an administrative drain to ...
5
One possibility here is to build into your testing the ability to flag a failure as a "Known issue" which is then reported with each run of your automation.
I've gone into more detail in my answer to the question user246 linked - I'd recommend you check into my comments and the other responses there.
Only top voted, non community-wiki answers of a minimum length are eligible
