Hot answers tagged

17

It is always a very good practice to start testing as early as possible. By not fully implemented if you mean still under development, then I suppose that is not such a great idea. Yes, you can go for incremental build releases for testing, that might be helpful. When you say that your testers all log the same bugs, well there's your problem! Do you ...


16

I think the problem arrives from how you use your VCS: You want to commit your code because you have finished a sub task and want to have it backed up in case of e.g. a hdd crash on your workstation. Your testers see changes in the repo or get an automated build which they test. One solution could be a separate working branch which is work in progress. No ...


13

To me this is a perfect example of what happens when effectiveness of testers is assessed based on the wrong KPI, in this case, a number of bugs reported. In the end it will harm testers, developers, relationships between tester and developers and as a result product quality. To me this is wrong KPI and there is been at least two discussions here why is so: ...


10

For estimation, the following aspects should be taken into account: Domain knowledge of the team and the requirements. Risks associated with the project. Buffer time. Historical Data. the software life cycle followed by the project. There are a number of techniques which can be used for test estimation, namely: 3-Point Software Testing Estimation ...


7

Apart from obvious activities like test data creation, test case execution, bug reports...what other initiatives can a QA engineer , take which will help raise his value to the project/Client. You can only do what the situation and context permit you to do. In some shops testers get to review the Requirements before they are finalized. If that's ...


6

I do not know what features QC delivers for running automated tests, but this is what I would do to maintain a Selenium test-suite: As a test runner for Selenium just use a unit-test runner in the language you are developing your tests in. Most xUnit-tests runners generate the same result files, which can be parsed by report generators for reporting. To ...


6

As Bookeater says, you absolutely want to unify tools and processes between the teams. That said, I'm going to offer some extra advice because I've been in this situation (and to some extent I am still in this situation). Hasten slowly - Each team has built up a process and toolset that works for them. A newcomer telling them they have to change everything ...


6

For the REST service testing Postman and HttpMaster are good tools. It supports dynamic parameters, validation of response data, various data viewers, etc. If you are looking for performing load testing of the REST services than Grinder and JMeter open source tools can be considered. This data is taken from the post Tools for REST webservice testing


6

Most of the companies I've worked for over the last 10 years are using an Agile approach. In this approach there are several factors to pay attention to such as: favor direct communication over formal processes encourage a team approach sit together I find that in such environments you want to seek out practices such as: pairing on test plans before ...


6

There will always be bugs that get past a tester and land in production. I have even had bugs that where in my face, we researched it, thought it was a fluke, because we couldn't reproduce it and then released the issue into production. The best thing you can do is learn from it and prevent the same in the future. I write an automated test-case for each ...


5

First priority should be for everyone to trust the test suite again, failing tests suites will not give this feeling. Disable all the broken tests and run all the tests a hundred times to also get rid of all the flickering tests (that work sometimes, but not always). Start running the tests on each commit or at-least daily to make sure the tests can be ...


5

It makes zero sense to waste time on testing a feature (and reporting bugs, and triaging them) if development is not finished yet. All this work will have to be redone again when code is finished. Something is strange in your process, if testers have so much time that they create extra work for themselves like that, which has no benefits to the project. Do ...


4

I once tested a Windows client UI by randomly banging on the keyboard while my coworker randomly moved and clicked the mouse. I found bugs that way, and I could reproduce them, but (at least initially) I couldn't tell you the exact set of keystrokes and mouse clicks that triggered the problem. That is monkey testing. Exploratory testing is testing ...


4

The question of "Is this application/feature/fix ready for release?" is one that can't be answered accurately, because - as the OP said - there's no way to be sure that there are no bugs in the software. More than that, depending on the situation, the business could have reasons for releasing despite the concerns of QA or testers that the software is not ...


4

I shared this more than once 37 Sources for Test Ideas Become a Skeptic, it will change your view of the product but also of life


4

It depends on the methodology of SDLC we are using, ex: if it is agile development with continuous-integration in place,then it should take 30 percent of development time. Like 15 days development of sprint, then time taken for testing should be 4.5 working days, if key features of applications automated. It also depends number of QA resources involved ...


4

No, it doesn't make sense to test code that you know is incomplete and not ready for testing. But rather than blaming your QA folks... I suggest that you take a closer look at your software development process. It sounds like there is a failure of communication between developers and QA, and a mismatch of expectations. For instance, it sounds like you are ...


3

Timebox it and afterwards evaluate. I would say time-box one hour and then see how probable it is the tester will find the steps to reproduce the issue. Often its easier for developers to reproduce the issue, since they understand the code for that part. And they are more proficient in code-debuging.


3

Testcase format I like one of the following formats: Arrange Act Assert Given When Then These give a clear separation between test phases and steps. How is the test situation setup What is the action under test (try to keep action steps under 10, preferable less) What is verified Details How to write the step details of test-cases greatly depends ...


3

Research and Analyze. Period I think these two tools are enough for a tester to generate creative ideas. And I would like to give you a simple example. Talking of your question, if you would have researched the SQA website well enough, you'd have known that the question put forward by you have been asked multiple times- here and here. If you would have ...


3

The fact that multiple testers test the same thing without even talking to each other shows very clearly that the process is broken. You shouldn't have 2 developers develop the same feature independently and you shouldn't have 2 testers test the same feature independently . It sounds obvious, but if 2 people work on the same thing, they need to know about ...


3

This question has been asked many times before on this forum. So you should try to research a bit before adding this question. Take a look at Here where there is a list of good thinking tools and techniques mentioned for improving your practical thinking ability. You can start by reading the number of books mentioned here You can also follow many of the ...


2

Scrum does not define any processes for testing, its more about a general iterative software development workflow and describes communication points and artefacts. The cycle of a Scrum sprint is that the team commits to a certain number of stories and at the end of their sprint. Those stories should meet the teams definition of done. Which should including ...


2

An area missed in earlier answers is working with your development team. You need to ensure that not only the lead, but each member of the test team has a good relationship with the development tea, counterparts. The developers are your greatest allies. Get the devs to write some more robust unit tests. Explain and have them buy off on your test plans and ...


2

You know that (a) is wrong, which eliminates A and D. Not sure why you thought it might be D: it shares wrong (a). So you need to decide between B and C answers. Both suggest (b) and (d). Difference is: Which one to add along (b) and (d)? (e) or (f)? So question is: why (e) and not (f): e. System testing environment has been tested and passed f. Static ...


2

You are SO going to hate this answer. It is Yes and Yes. There is some possibility to integrate between TFS and fogbugz. http://www.fogcreek.com/fogbugz/docs/70/topics/sourcecontrol/setup/TeamFoundation.html Your goals should be: Maximum tool level integration (to input info only once). Define overlap between procedures and utilize this Minimize ...


2

It depends. I saw acceptable time/effort ranging from 0 (outsourced testing to almost un trained testers) to infinity and beyond (combined engineering team with engineers that know their way through the code and product). YOUR answer will vary according to (just throwing some ideas): Your skills and knowledge e.g. how familiar are you with the product, ...


2

What are the most important components/parts of a well-written test plan document for a testing project. Consider you are testing a Financial web app. As per IEEE 829 standards, the components of a Test Plan document should be : Test Plan identifier References Introduction Test Items Risks Items to be tested Features excluded for testing Testing ...


2

I am working as QA and also to write a test cases of mobile application and web application. In Both Application required in writing the test cases are : Test case id Test case(unit to test) Preconditions Input test data Priority Steps to be executed Expected result Actual result Pass/Fail Comments and for more information see below of reference link ...


2

That question is the entire reason that the QA team exists. As QA engineers it is our job to test the application and get an idea of its quality and whether or not it is fit for purpose. As such, there are three answers possible: Yes, I think the application is ready for release No, I think we shouldn't release because the quality is insufficient I can't ...



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