Hot answers tagged methodology
14
Peter,
Good question. And an extremely important one for software testers.
I have studied the question of how can software testing inputs be combined most efficiently and effectively pretty steadily for the last five years.
By coincidence, slightly over five years ago, I started with almost precisely the same question you're posing now. At that point, ...
13
How I think about state models for testing. A state is the system's readiness to respond in a planned way to each of a set of defined events. You know that a system is in a new state (compared to a moment ago) if:
The set of events to which it now responds differs from the set a moment ago.
The system now responds to given events differently than it ...
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 ...
11
Preface about my biases: I don't find the term "checking" evocative, and I don't find the distinction between checking and testing helpful. Given that...
First, the word only suggests that checking is somehow trivial. I think checking is important. And creating useful checks is hard.
Second, a key distinction between testing and checking is sapience. It ...
10
The crucial issue IMO is to acknowledge that your pages will need to be adjusted in order for the tests. To pick up on the Selenium issue, instead of using XPath to structure your selectors, add ids to the pages and use those in the tests.
I've also found the Page Object pattern to give good results:
Within your web app's UI there are areas that your ...
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
I think that Larry Elison summed it up nicely when he stated that Cloud computing is just, servers and the internet. Video is here -> http://www.youtube.com/watch?v=UOEFXaWHppE
Testing "Cloud" applications should be tested as though you would test any existing web application with a few added test cases to test the additional "Cloud" features, if you ...
7
"Playing around" and documentation like user manuals can definitely provide a start to developing tests, but they should just be a beginning. Properly testing that an application is doing what it is supposed to requires more domain knowledge. End users who have been using the application and know what it is supposed to do can be a good source for creating ...
7
There are a number of key things that I have learnt are key to have easy to maintain, reliable automated tests.
Map your controls in a single place
Your controls should be mapped into a single location, so that if a control changes, you only need to change it in a single location. Having it in a single location allows you to make a one line code change if ...
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
There is a concept of "steel thread" that we used back at one of my previous jobs where the user story itself is a specific requirement that has a very particular expectation. Anything outside of that particular expectation should be its own user story. The acceptance tests can then be focused and targeted to verifying that the user story's "steel thread" ...
7
To decide what we need to test we need to understand what is likely to break. The current batch of web browsers have a set of commonly known bugs and differences. If you understand these differences, you can go a long way to understanding why pages have javascript issues or render differently in different browsers. Internet explorer has a large number of CSS ...
7
In agile environment the distinction between a tester and a developer is blurred. Testers are not the solely responsible or even the primary owner of quality. Quality is a shared responsibility of the whole team. Individuals in an agile team may specialise in a particular role but will take on different roles depending on the context. Testers who are out of ...
7
What you have described so far is something I'd call 'scrummerfall', but given how it often turns out, could be spelled scrummerFAIL instead. I see several issues that need to be addressed. @Aruna covered several in their answer, which gets high marks from me. To what they have said I would add the following.
1) the team doesn't understand what 'DONE' ...
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
A strategy that I commonly use is that I will put my "end user" hat on and then test the system like it was an application that has been deployed to the general public.
I will make a number of assumptions as to why things are the way they are, and document them. I will then take those assumptions and have them checked by whoever I can, ideally subject ...
6
Discussing your automated test needs with your developers up front can often help.
A developer should not have tip toe around the application with fear of breaking our tests, but if they can proactively make design choices that make it easier for us to maintain them then that can be a huge time saver.
6
Approaching the application methodically and with intent can yield a significant amount of the information that you need.
Start with simple questions - any application should/ almost certainly will have the most commonly used functions on obvious display - follow every option in the menus for a while. Start to map what features you know the application has. ...
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
I repeatedly apply three principles:
Hide incidental details. Any detail that isn't directly related to the purpose of your test belongs somewhere other than in your test. Hide it somewhere, such as in a variable or in a method, and give it a good name.
Name every important idea. Why does the test code log in in as "F.D.Gumby" rather than as some other ...
5
Use your testing skills to help the team define each story more concretely. This shifts your contribution from one of strictly detecting problems to one where also help to prevent them.
As stories are being prepared for the next planning meeting, work with the product owner and developers to clarify the boundary of each feature. Use your well-developed ...
5
This really depends.
No if you have created virtual machines on the cloud and have moved your application onto those virtual machines and placed these behind the a load balancer. You might choose to check that the load balancer functions as expected, and the performance when you place you application under load to ensure you have the correct setting in ...
5
As an end User you test, there is no specific rules to follow. Generally understand what are their requirements and set a work plan what different testing methods you could do with the application. Make sure you are aware of these techniques. You could go with their release notes, what changes they have made in the current version. Then you could test from ...
5
You are neither tester nor checker. Or you are both. I believe the purpose of the article you referenced was to illustrate different ways to approach our jobs, not a way to drop people into buckets so that they can be treated differently. The role you play in your organization is a consequence of many circumstances, e.g. your general experience, your ...
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
First of all keep in mind: there will be always some maintenance. Whatever approach you will use, your tests will change over time. Many people will suggest to skip GUI automation as it is very brittle. It is true to some degree, many times it is just something they have heard from someone. Sometimes people say that because they have tried it once, expected ...
Only top voted, non community-wiki answers of a minimum length are eligible
