Hot answers tagged methodology
13
I am a self-taught programmer with 14 years in QA experience (most of it as a Software Developer in Test). My experience in QA helped increase my understanding of design, many different core/fundamental technologies (html, http, tcp, msaa, etc) and exercised my analytical and critical thinking skills, all of which helped prepare me to become a developer.
...
13
Starting testing during development is too late, and starting testing before deployment is usually a recipe for disaster, missed deadlines, and high unexpected costs.
Testing should start as early as possible. If you have a prototyping stage, then testers should be involved in the prototyping before any requirements / stories are solidified.
Early ...
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 ...
6
I noticed you did not ask whether it was better to start testing during project development or before deployment; you asked which was more efficient. You also did not specify whose efficiency you wanted to maximize. You did not say who would be doing the testing, but since you mentioned testing before deployment, I assume your refer to testing by someone ...
6
I'm not sure what kind of advice you are looking for.
You said "here's a lack of quick (not more than 8-10 hrs) and easily available tasks for staff evaluation. It would be nice to have 5-10 typical testing apps for checking various aspects of QA specialist skills".
Other than "Create them", I'm not sure what kind of advice we can offer?
I've created ...
5
You should clarify your question to define what is meant with "start testing".
Take a look on this diagram (taken from here):
There are various aspects of tests.
They are defined and run at all phases across Software Development Life Cycle (SDLC):
Acceptance Tests are defined just at the same time with Business Requirements - e.g. they are defined at ...
5
Of course a passing unit test does not guarantee a functioning system. A buggy unit test could produce a false negative. The system could also use the component in a way the unit test does not, e.g. in a way the component author did not anticipate, or in a way the unit test author did not anticipate.
You can also think about this in terms of the ...
4
Testing team should be involved in the project from the very beginning. Especially important are gathering system requirements and design phases. Basically speaking you have to design your system for testability. It's quite difficult to implement test automation if your system hasn't been designed to support test automation.
It also depends on your ...
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
Was there any requirement for formal QA to be performed on there side. Many small shops don't have dedicated testers. It's just the developers who are writing the code who are testing it and the customer performs a testing/UAT role. The client should be aware of this up front.
I'm finding that what I've been doing (trying to squash every possible
...
4
The two obvious steps that you seem to have missed out:
Perform the tests. Much may be done auto-magically, but manual testing is still a key aspect at integration and system test levels.
Report the results. Whilst automated tests may generate a results file, you'll need to interpret and present the results in a format that is appropriate to the ...
4
Tracebility matrix is a tool. It doesn't have any inheritent value, but it might be easiest way of mapping certain kind of relations between tests and requirements. As with any other tool, if it seems to work well, use it. If something else fits better, use that. If the tool nearly fits your need, modify it to give what information you need.
If testing is ...
3
I have never seen such a matrix and never heard of it before :-(.
Your goal:
Which requirements is almost never tested, and which is tested extremely often?
can be achived by agile/technical means:
Using Behavior driven development bdd as automated test for a userstory to verify that it is complete and still working.
There are code coverage tools ...
3
"Testing", "validation", and "verification" are just words that people attach to different kinds of practices. Some of those practices focus more on "Did I build it right"; others focus more on "Did I build the right thing." You can name and group those practices in different ways depending on what you are trying to accomplish.
If you want to be clear ...
3
There is nothing wrong with having a plan for your career that involves more than one kind of job. However, even if you want to be a developer, you need to take your QA job seriously. As soon as you do a half-hearted job on a test plan because writing test plans does not help you become a developer, you reach a fork in the road: either you convince someone ...
3
Systems testing is often performed against the whole platform, and treats the environment as a black box. system integration testing however, acts upon a subset of the whole system, and may mock other platforms, interact with databases, network sockets etc to evoke appropriate responses from the parts being validated.
The objectives of system testing is to ...
3
Every fix should be analyzed separately.
You need to ask yourself
How can I verify that this bug has actually been fixed?
How can I verify that this fix hasn't introduced new issues or side-effects?
What other tests does this fix suggest I should perform?
Sometimes, a very isolated bug requires only an isolated test for verification. And sometimes a fix ...
3
I want to explore two areas: Scope and terminology.
There are systems at (at least) two different scopes here: The end-to-end system and the unit, which is also a system.
When I'm analyzing a "defect," I like to think in terms of three parts: Failure, fault, and conditions. The failure is the system's production of incorrect results. The fault is the ...
3
I currently work on a small team, where I develop test automation in essentially the same way that you describe. To develop effective test automation at the higher levels, you have to be able/willing/trained to quickly perform the scenarios manually before they are automated. Inevitably, defects will be uncovered during these manual runs. As a result, the ...
3
Statistics is often used explicitly or implicitly. Some examples:
Analyzing the validity of multiple performance tests results.
Choosing parameter values based on distribution, e.g. uniform vs. normal
Developing test techniques, e.g. a proof that randomness is as good as X wise testing under certain assumptions.
3
Not exactly.
Unit testing only isolates units in isolation. In these tests all dependencies to other units are mocked or stubbed out. So how do you know those units together do what they are supposed to do? Code tends to grow hierarchically in complexity, and with that growth comes more and more units working together, more and more groups of units ...
3
There are many cases where unit testing as you have described would not be "sufficient".
(And you haven't really defined what you mean by "sufficient" in this case. Good enough to move the code to Production? Good enough to pass it on to QA? Good enough to please your boss? Good enough to feel like you did a good job? Something else?)
In most practical ...
2
When talking with new college grads (freshers), about starting their career, I give two examples where starting in testing may be a good idea:
The best developers that I know are awesome at testing their own
code. I asked one senior developer why he spends so much effort to
get to 100% coverage on his unit tests. He replied that he wants to
be "the man", ...
2
Michael, the solution is depends on your plans, budget, etc.
If you plan to continue working with this dev shop for a long time and you have enough budget – then the best decision (you know it without this words) – is hire a tester for the team.
But it will not fix all the issues at a moment. As I understand, you are the Domain Expert and only you know ...
2
Addressing your question specifically, it is your job to report every bug you find. When you start making yourself ignore the smaller details, you do the customer and yourself a dis-service. Down the road the might notice these smaller bugs and wonder why you didn't find it. Or they may fix all the big functionality issues then want you to catch all the ...
2
Experience in testing may help you in programming better, but will not replace programming experience. Hence, as others stated, getting a job as a developer will require experience in development. Similarly, in many companies and projects, getting a job as a tester will require experience in testing.
It appears to me from your question, that you see ...
2
Are the tests at least categorized by product, feature and separated by unit/integration/functional? If not, that would be a good place to start to start before trying to figure out what coverage they provide.
One possibility would be to run code coverage on your product while executing the tests. This could give you a good indication of what the tests do ...
2
tl;dr
Read different blogs and people's perspectives while you build a set of practices that are best for you. Note that once you change a job, only a few of those practices might come with you. Don't get stuck with a few methodologies and practices marketed as the "best practices".
Long version:
"Best practice" questions will have numerous ...
2
At risk of rehashing previous threads, verification (according to ISO12207) is ensuring the correct processes and standards are followed and that all requirements are traceable though the lifecycle, not the testing of actual requirements. Testing is a validation activity - you are validating the code against the requirement.
At the end of the day, your ...
2
INHO the testers' responsability is the sameone that all other roles' responsibility: to contribute as much as possible to the success of the project.
That is, keep an eye on the ROI of every one of your activities. Keep a balance between the cost and benefit the project (and the whole team) will get for those activities. Keep aligned with the project and ...
Only top voted, non community-wiki answers of a minimum length are eligible
