Tag Info

Hot answers tagged

9

I've read that if a requirement can't be verified by black-box testing or inspection, then it's not a requirement, but a design specification. I don't think that's true. There are plenty of requirements which are difficult-to-impossible to test with black-box techniques; for example, a client-server application might have a requirement that all ...


9

As user246 says, tricks to force developers to test can always be gamed: you're much better off finding out why they don't like testing and what the actual problem is then building a culture of testing and quality from that. You're working in PHP - there are unit test frameworks available for PHP that your devs can use. If they have no idea how much trouble ...


8

It's not exactly clear what question you are asking, but let me take a stab. I would deal with it by creating a bug report. In it, I would mention what you are seeing in Commit A, and Commit B. I'd mention that the combination of the two pushes performance past the prescribed limits. From a QA point of view, it's not important at all in which Commit the ...


8

A requirement is typically a general statement, whereas a use case is typically a specific statement implied or derived from the requirement. A requirement may map to multiple use cases. A scenario might be a set of background assumptions that put a use case in context, or it might be grouping of use cases. Here is a contrived example. The requirement is ...


8

Welcome to SQA, Ana. I see at least two questions: Does it make sense to distinguish between focused tests and workflow tests? Yes, it does. A focused test concentrates on a particular feature, including things like edge conditions. It attempts to answer the question, "Does this feature work in all circumstances?" A workflow test verifies that the ...


6

At some point you have to trust the third-party software you work with. That's not to say the software won't have bugs; of course it will. But you can never test everything. For example, I suspect you do not test the operating system, compilers, text editors, router firmware, printer drivers, and web browsers that you depend upon. (At a previous job, our ...


6

While the entire system isn't under your control (which is clearly the superior option), it might still be possible for some slice of the system to be under your control. You say it's a payroll system. Can you create a "Test Company" that everyone else would agree to leave alone? Can you create "Test Employees" that everyone else would agree to leave ...


6

I am working under the assumption that you would be familiar with the language the tools are being written in. If the team you are on already is writing unit tests a good place to start might be with them. Talk to the developers that are writing the unit tests and get an idea for how the underlying code is working. In the process of doing this start ...


6

OK...now that a few folks have voiced their perspectives on "boxes" let me try to answer your question. I am going to assume that we agree that by 'white box' testing you are referring to the act of designing static or dynamic tests based on the implementation of a programming language that performs some functional task or behavior in a software program; or ...


6

In my experience with documenting system tests, I've found a multi-layered approach works. I really like Microsoft Test Manager for this because of two things: the ability to define input parameters for manual tests and the concept of shared test steps which can be used by any test case. You don't mention if you're using a test case tool, word, excel or ...


6

You're already doing it! The core principle here, which you're already following, is: Prepare some data Enter it into the input field Check whether it is displayed correctly in the output. To make your testing more sophisticated and thorough, consider the possible variations at each stage: 1. Data: Basic numbers and letters Basic punctuation ...


6

Selenium is a tool that remote-controls a browser. You can use it to simulate a user interacting with a web site. JUnit is a framework for writing Java unit tests. It takes some of the grunt work out of organizing tests and generating reports. You can express each test as a method on a class; typically, you have multiple tests per class. JUnit will run ...


5

Essentially, this is a common dilemma in designing an automated test. IMHO, the design of a test is heavily dependent on it's intended purpose in the development lifecycle. You stated that these are regression tests...implying that the current functionality is working correctly and the primary purpose of the test is to expose bugs caused by changes in the ...


5

IMHO, a team lead who is a developer with less knowledge in testing, is the wrong kind of person to be selecting a test tool. Do you have any QA Professionals on your team - perhaps someone with test tool experience? Or, lacking that do you have anyone on the team who will actually be tasked with using a test tool? I would suggest you turn to them. If ...


5

Good luck with that. Your developers are probably bright enough to subvert any gimmick or incentive you put in place. Instead, you need to face the problem head-on: testing needs to be a part of your organization's culture. That's not to say that every developer needs to love testing, or needs to prefer testing over development. Rather, developers need ...


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

As already stated in a comment, it depends. You have to consider a lot of things in order to decide your test strategy. Usually you have limited resources for testing (time, budget, testers, infrastructure etc.), so you cannot test everything equally thorough. A risk-based approach helps you decide where to concentrate your testing efforts and how thorough ...


5

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


4

The first two issues that come to mind are scalability and tolerance of faulty data. Data Science frequently implies large data sets. As a tester, you need a sense for expectations about data set sizes and the corresponding performance. Those metrics need to be put in the context of the computing environment of course; what you can do on a laptop running ...


4

I'm going to go out on a limb here and say that what you have is an ad-hoc development process rather than an agile one. Here's where I'd start, assuming that you have the ability to work with the programmers and project/application management on this (you can get a lot of it even if you don't have that ability). Who - Who is the intended and actual user ...


4

Use cases are a way to translate requirements into something more concrete. If you have use cases, you should test with them. You should test in other ways, too. How you represent your test cases is up to you. Some considerations for picking a representation might be tool quality and cost, and ease of writing, revising, searching, annotating, and ...


4

As ByteBuster indicated, user stories are a very high level description of a goal an actor or customer wants to achieve with the product, but doesn't detail exactly how that goal is going to be achieved. Developers often break user stories down into discrete development focused tasks that are necessary to achieve that goal. Developers should also be ...


4

You did not provide a lot of detail about the relationship between the logging system and the processing system, so my answer is going to be general/vague. I would try the following, in this order: Educate your management. You have a good reason for how you structured your tests. Explain what they can and cannot infer from a 100% failure rate. Explain ...


4

That is the Builder pattern. It is not specific to BDD. It's fairly common in integration tests and functional tests. It's less used in unit test, which typically have less need for complex data setup. A test data builder might either construct data, or find relevant data in a database. (I strongly prefer building data from scratch, but that's a rant for ...


4

The Babel tool will generate characters by language group, or multiple language groups. Typically, if you are seeing a � character, that usually indicates that you don't have a font capable of displaying the Unicode character (or the Unicode code point is not assigned a character). Corruption is usually indicated by a single chars displaying as 2 different ...


3

Cel, As always, it depends. If there's a requirement that the link contain a label then obviously the test needs to check that a label exists (whether automated or not). Here are some of the possible things I'd consider with this scenario: Is the code dynamically generated or static? For a static "once and done" page, the mark 1 human eyeball might be ...


3

I'd agree with the other folks here: it looks like you're testing your application's use of the third party tool, and in most cases that should be enough (if you're working somewhere where a mistake would get someone killed, perhaps not so much). With a tool that interfaces between some form of data and a database, the essentials are testing that when using ...


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


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

As the other answers have said, you will probably not test the user stories directly. The method I've used in the past works like this: Each user story will have one or more acceptance tests. These tests typically cover a high level test scenario (such as "Given that I am logged in as a customer, then clicking the link 'My Orders' takes me to a page ...



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