While performing software testing tasks, a number of documents needs to be created/updated time to time and that seems very time consuming activity. As sometime it is important but we hardly re-use any related document after the build is released, per my experience. So, please advise if it is purposeful to spend time in maintaining such huge records or testing can be done without them.
If documentation is not specifically required by project or company process, you can try to reduce it and use just short lists of what was tested rather than full test case format.
From my experience completely ditching documentation is not a smart idea since you’ll want to have something as a reminder of what was done, especially if you work on several projects. I used to test without documenting work and now sometimes I have problems when I return to undocumented project after several months of inactivity.
If the application you are testing is only ever going to be used once by one person for a completely trivial purpose and never used again, then no documentation is required. In every other instance, some sort of documentation will be needed:
- When users report bugs in production but no-one who worked on the app is still with the company
- When version 2 needs to be developed but the guys who built version 1 have left the company
- When users need help or support in the ordinary operation of the app (traditional test scripts are actually very good for helping to create Help files or a wiki)
- When a third party (a client, a regulator, a lawyer, the police, the Government) requires evidence of tests performed or some other tangible guarantee of “quality”
- When a user blames the app for something bad happening and escalates their complaint to:
- Your CEO
- a court of law
- When something happens in real life (on a scale of 1 to 10 where 1 is “everybody is laughing at your company” and 10 is “somebody died”) and your company is blamed for it in the media.
These are the times when you will be thankful for your test documentation. I know, I’ve seen all of these (though fortunately, on the last one, my personal involvement was around a 5). Risk analysis will help companies and managers take a reasoned decision on just how much documentation is essential to create and retain. If your risk on the last one is a 10, then be prepared for a lot of printing which you hope no-one will ever look at again.
I’ve started using session sheets, which I’ve found useful. They include test methodology used, steps to reproduce any defects found etc. Hopefully they’ll help me identify things like how much time is wasted on setting up environments, configuring new features etc, so I can try and reduce time spent not actually testing. Also, if somebody is off ill etc, if someone steps into the breach, they’ll be able to continue incomplete work. It should also be a good resource for the rest of the team to be able to identify areas of testing that can be looked at in a different fashion, and provide a basis for any automated testing (I’m trying to get to grips with Selenium and have used my beautifully crafted steps to reproduce to create tests). Any defect found in session 1 (for example) and not resolved are copied and pasted into the defect section of the session 2 sheet and so on.
If it helps anyone (and maybe if anyone can make any suggestions for changes - one hand washes the other), the sheet contains the following:
Sheet name - Ticket #/session #
Name - staff member’s name
Purpose of session
Planning/Time Break Down
Session Notes - Notes on what and how things were tested. Defects are structured as DF-Ticket#Session#Defect# (eg DF-AA111001)
Defects - Defects identified (referring to reference #s above)
Issues/Debt - Anything that you haven’t been able to test, or anything that has prevented “proper” testing
I would suggest documentation is very important and main part of any testing project. Although, it seems time consuming and most of the software tester won’t like documentation as time spend on it is considered as non-productive. They feel better to spend time in exploring the functional phases of the application or product rather than sparing time in typing lengthy document.
Still any quality assurance company gives a lot of prominence to documents and considers it fundamental to an effective project. They have dedicated resources to maintain the documents at regular interval. A decent document, help guide and instruction notes etc. are considered as efficient and well-organized software testing practice and results in glitches free release.
We understand that verbal communication is quick. But, verbal miscommunication and lack of proper documentation could become reason for rejection of project proposals also, that means ultimate loss of capital and it can only be avoided with the help of effective documentation.
Some of the important documents includes:
- Software Requirement Specification should be client approved and all the product related requirements should be properly listed.
- Test Plan Documents are created to organize testing schedule, team involved, various resources required and it also covers testing scope etc.
- To perform regression testing, test data is required and if we have test data ready in a document then testing becomes easy and less time consuming.
- Test Case Specification document, bug Report Document, after release/post release document etc. are also important.
- Once the build is released per the specified requirements. The acknowledgement from the client is required in form of user acceptance document regarding, the release is accepted.
- Weekly/monthly status Report are there to maintain projects particulars like on track, delayed etc and should always be up to date.
- If daily stand up call with client is there, then to avoid any miscommunication between client and the organization MOM (minutes of meetings) should be prepared.
It does not matter how many documents are prepared but the main thing is, document should be accurate and transparent. A qualitative document is prerequisite for systematic testing approach and client satisfaction.
Hope this information is helpful for you.
Quite simply, documentation in some form is needed for a worst case scenario: What if everyone on the team won a mega lottery and quit (that’s better than the 'ole hit by a bus, train, etc. scenario)?
How would anyone know what to do, how to do it, any special consideration, where you left off, and the list goes on?
It’s also good for code reversion. Have you ever worked on a project where something was updated, then updated again because it wasn’t quite right, only to find that you had to revert back to the old way? I have. Proper documentation ensures that you know where you need to go back to and how it should work.
I could go on, and you might say that these are edge case scenarios, but they do happen in the real world.
Oh yes, I forgot the “lottery win” scenario. And I’ve seen that one, too. I once ran our team’s Lottery syndicate, and our Operations Director always smiled a nervously weak smile when he saw me collecting the stake money each week.
In a previous existence, he had been a hospital Chief Executive - and had arrived one Monday morning to find that the hospital had no midwives because their syndicate had won big time over the weekend. He lived in fear of lightning striking twice…
For me the amount of documentation needed is a product of your situation. I’ve worked in regulated domains with high requirements of tracability and in unregulated non-critical product development. You do not need to have the same level of documentation for these. Some learning from the regulated products are that the documentation you produce during testing is vastly superior to any documentation done prior. As an example a friend of mine worked on a fighter jet project, which in the latter stages had a spectacular crash in the middle of the city during a show. He was then very happy that he clearly could show that he had in fact tested the very thing that caused the crash and that it had been reported as a weakness, but was dismissed that a highly trained pilot would “never” do that. I’ve also had the experience that two different testers running the same documented test case have produced different results, i.e. one of them found some bugs where the other didn’t. They of course did not actually do the same thing during testing even if the followed the same test case. Hence the documentation that you can write while you test which aims to capture what you did is superior to the test cases for this purpose.
My suggestion is that you try to map out what your main objectives are in terms of using the documentation and then find the most suitable media for these cases. Such as if you only care about tracability during / post testing documentation is better. If you care about new people training there are some interesting options to. My favorites are guided learning and a knowledge map. The latter is sort of a catalog of who knows what, so when you need to know something you know who you need to talk to in order for you to learn about that. Another thing we have right now is a how to. If you want to know how you do a certain thing you follow the howto. This is way easier to maintain and new people can also contribute when they find any irregularities in the documentation. If you want to solve the bus factor (how many people need to be hit by a bus before you lose the knowledge), pair testing is far superior to documentation. For status reporting, test reporting there are both good options and tools that can help you.
tl;dr you documentation is can be improved by tailor make it to your situation
Not only as a QA but as an IT professional you should have to focus on the documentation skills Because after doing so many things, in the end, you have represent each and everything.
But here as a software tester, you have to learn how to write a better bugs report which things are important and need to focus on designing better bugs report…
Good bug report should be included
for complete details Please check here:https://www.testrigtechnologies.com/how-to-write-a-better-bug-report/
Can you think of a good bug report which has none of these factors?
Why is “numbered” important? (Can an e-mail be enough?)
How specific is “Specific”?
What if there’s a critical bug which we can’t reliably reproduce?
And why am I writing a bug report in the first place?
I hope It will be helpful for you…
Numbered:- unique id can be easily identified, It saves lots of time and helps to decreased complications in the bugs report… In a simple word, a unique number can easily be identified
Specific:- According to me, if it is specific… issues will be fixed expediently.so make it clear
Reproducible:- if bug report as irreproducible, it will never get fixed so Describe your steps to reproduce clearly without missing any of them.
Priti Software testers at Testrig Technologies
The following examples are based on previous experience, and are not all from the same company.
Situation #1: My company does not have a issue tracking system. Instead, we talk to each other, and modify our specifications on the spot if the issue is important enough to fix. If the issue is not important enough to fix, we discard it. Thus, there is no place for unique numbers, and no desire to add them. What is then wrong with this system?
Situation #2: A customer sends an E-mail to us, “The system doesn’t work for 10 minutes each day!” There are no more specifics than that (not even which 10 minutes or if the 10 minutes are in-a-row (spoiler, they weren’t). The customer is part of our core business. Losing them will mean closing our doors. How would you handle this situation as a bug report?
Situation #3: An automatic test has failed, but it only failed once. When the tester was supposed to log in as User01, it actually logged in (successfully, I might add) as User02. The proposed release date for this change is tomorrow, and we have no idea how it happened. (The reproduction steps took several days to figure out). So we have a very serious security threat and no reproduction steps, with not enough time to isolate those steps before release. Could you make a “good” bug report based on this?
They usually don’t.
If you don’t have value for the document, or the value is not equivalent to the effort to produce it, you shouldn’t do it.
This is a key principle of Agile software development - “Working software over comprehensive documentation”.
I have just read a fantastic article that discusses the importance of documentation. I suggest to read the full article - Realizing Test Cases, Test Scripts and Test Scenarios as Valued Testing Assets
Here are some of the interesting points:
Detailed test documentation has many purposes and can be a great investment when leveraged for reuse in future projects and other purpose, such as CI tests and regression tests.
Test repeatability is essential for the ongoing testing of releases, especially for the purposes of regression testing and continuous integration (CI) testing.
The need to measure the status of testing for the purpose of determining readiness for release requires there be something to measure. While defect levels are important to measure, without test case status, they lack context.
Determining test coverage levels.
Using the test documentation as a basis for knowledge transfer.
Using test cases and test scripts as the catalyst for process improvement, especially the processes for testing, requirements analysis and documentation, and software development. By understanding where defects seem to be concentrated, more effort can be applied in preventing defects in those areas.
Test automation requires in many cases the ability to understand the test before automating it. Much of this understanding can be gained in the process of documenting a test in test cases and test scripts.