Tag Info

There are a couple of aspects to this issue: The same terms being used differently in different locations/workplaces. For that issue I'd recommend getting a clear definition of the terminology in use there, even if it isn't correct. Why? Terminology usage in an organization is part of that organization's culture, and changing the culture isn't always easy ...

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

Your testers deliver the tests scenarios that should be implemented by the developers and some of your developers write more tests than required. Give them a raise! I recommend to review the extra tests and check if they make sense. Encourage all developers to write more tests to put their knowledge into tests. They know implementation details, so they can ...

I maintain a Glossary of Testing Terms (based on this: http://strazzere.blogspot.com/2010/04/glossary-of-testing-terms.html) that we use internally. In addition, we maintain a Glossary of Business Terms containing terms and acronyms for the industry in which we live, as well as company-specific terms. We have a periodic "Lunch and Learn" session where we ...

I read two questions: (1) should we document the tester-written unit tests and (2) how should we treat tests that assume implementation details? It's important to distinguish between scaffolding and unit tests. (Please don't get caught up in my terminology; I'm just trying to make a point about some concepts.) Scaffolding is code a developer writes as ...

Introduction ( this should be brief, something like why we test our applications and why its Importand) Scope and limitations of our Test platform Resourses (Software ex Selenium, Test Scenarios, Links for tutorials) Procedures ( how to register a bug or tests priority) But in general the documentation changes according to whom it is intended for, ...

I document the following: What I think the problem is. Sometimes this can be tricky, and if I'm not certain, I'll talk to someone about the functionality before submitting it. What do I think the expected result should be? Again, tricky. See #1. Steps to reproduce. The easiest way to a developers heart is to provide detailed easy to follow instructions on ...

I think the key here is to realize that documentation is no longer a task when you are in a regulated industry. It is now a released feature, with interested clients and external stakeholders that you need to satisfy. You should treat it like a user manual would be treated on a non-regulated project. For our team, we deal with externally released ...

A clear title - I want to be able to be able to tell at a glance without going into the report itselt what I am looking at. Description of the bug - this should be as consicse as possible Reproduction steps. You should be able to reproduce the bug and hopefully have narrowed it down to the simplest possible steps. Evrionment considerations (OS, browser, ...

I have found OneNote to be an excellent tool for storing this kind of data. It has a very hierarchical organization which also is friendly to reorganization. Also, you can put a notebook on a network drive and have the whole team work on the same documents. My team used to keep everything in word documents on Sharepoint. By keeping everything in a ...

This varies from organization to organization and team to team and application to application. It all depends on what works best for your situation. 1) Test documentation attached to requirements. This works well with HP's Quality Center. All test data is in the same application and tests are individually linked to a master test plan and a specific ...

I distinguish between release notes and release contents. (The specific terms do not matter, and you may use different terms than I do). The release notes is an externally-consumed document that helps users understand what is new in the release. It usually describes new features. It may or may not describe bug fixes, depending on the product, the type ...

When a customer asks you for something using words that you don't understand, you must ask for clarification. I'm guessing that the customer wants to understand how the whole UAT process will work - who does what, how, and when. But that's just a guess. The term "UAT Protocol" could mean anything to this particular customer. Guessing and hoping for the ...

In the traditional sense of the word a unit test is designed to test the smalled functional unit of software such as s single method or function. Unit tests are intended to provide limited testing of the functional capabilities of a function or method in isolation. Typically, unit tests are written and maintained by developers because they should be used by ...

I had a similar question, which I posted on softwaretestingclub.com : http://www.softwaretestingclub.com/forum/topics/ieee829-testing-standards-in What i've taken from the answers, not only from the site, but also peers at my current client, is that there is still documentation in Agile, but less of it, and less up front. The information in your stories ...

I would say why only create a document. You can create a mind map or a any other visual representation of what are you trying to convey. Its a nice way to get your message across and won't cost you any words at all. I have used test strategy to communicate in essence, only the following things What you plan to do ? How you are going to do it ? If I am able ...

I found this document based on IEEE-829 and have used it for rough guidance, but remove categories that seem like overkill for my team or merge categories that seem similar. Since I started doing this, I've received many compliments on the clarity of my test plans. I use a wiki for documentation, which makes it easy for users to jump to the sections they ...

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

Comparing old versus new is often quite a testing challenge, particularly without deep documentation. The basic, obvious parts will likely be fine. But the edge cases, the hidden dependencies, the more subtle parts, and the fixes and patches applied to the old system over the years, all can easily get lost in the transition. A full Functional Spec would go ...

It's in git so you could do a sparse checkout to get the JavaDoc part of the repo only. This blog post about sparse checkouts goes through it in a reasonable amount of detail: http://blog.quilitz.de/2010/03/checkout-sub-directories-in-git-sparse-checkouts/comment-page-1/#comment-3146 Or you could download them from maven central: ...

Where I work we are not quite as progressive. We simply store the documents categorized by product feature (i.e., modules of the application) on the network. Installation testing is slightly different. We store per the version release; also the installation testing documents are stored located with the repository of tasks (anomalies). There is nothing ...

A bug report should include as many details as possible. But keep in mind that it should not bog down the tester from creating them if it involves lot of effort from their part. A good template should contain Title (Short and descriptive), Build No, Requirements Reference (Optional), Problem Description, Expected results, Steps to reproduce, Analysis ...

It's interesting that you mention it's important for as many people as possible in the organization to read and remember your test strategy. I infer that by default, people will not read or remember your test strategy. That tells me you want a document that is both instructive and persuasive. If you want someone to read all the way to the end, you ought ...

A simple and inexpensive approach would be to record the documented procedures/scripts and the tester's findings in a spreadsheet. It sounds as if you have more than one tester. If you are concerned about the logistics of multiple testers updating a single spreadsheet, you could use an online spreadsheet, e.g. from Google Docs. There are more ...

If you are looking for tracking there are options like Jira - http://www.atlassian.com/software/jira/ or MSTest if you use Visual Studio. Although you can find many options at Open Source Testing as well - http://www.opensourcetesting.org/

Some of your developpers are probably doing a combined BDD/TDD approach as described in MSDN Magazine: BDD Primer - Behavior-Driven Development with SpecFlow and WatiN. I see unittests as a kind of executable documentation that fail if the documentation (=testcode) or the some productioncode (that is called by the testcode) is wrong. Do you consider ...

Where I work - a team of 6 testers - we use Excel spreadsheets a lot. For bug fixes, there's rarely more than a text file saved with our bug tracking tool (built and maintained by the company). Feature development usually gets a spreadsheet with a listing of test cases and results. The regression automation has a separate shared spreadsheet where the results ...

Particularly in a small company, go to the readers of the report to find out what they need for it to contain. Usually, people don't want to hear about your testing work, just the results. Those results might include any open, but deferred, bugs. It might include release notes. It might include features added. Etc, etc. Do others know the definition of ...

A test log is simply a log used for testing. ISO 9000 compliant timber companies typically have detailed guidelines for the structure of test logs. For example, they must still include bark, must be between five and ten meters long, and between 50 and 100 centimeters in diameter. Like production logs, test logs must have visibly apparent concentric rings ...

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