Agile methodologies foster accommodating frequent changes. This means the test case documentation will soon become obsolete. Some projects have very short sprints or iterations. The manual tester might not have all the time in the world to go sequential by first preparing the documentation and then begin to test. Some of the projects are even more nasty where the requirements would change in the same sprint itself.
Agile testing is characterized by quick iterative life cycles which squeezes tester’s ability to develop and maintain test cases, leaving very less time for documentation. Consequently, in this high paced agile environment, one is always on the lookout for tools that facilitate easy and quick documentation and test case preparation. ‘GOOGLE DOC’ is one of the pragmatic options readily available FOR FREE to use.
Yeah!…everyone knows about google docs but do we really use it?
How does Google Doc help in Agile Testing?
1. Test cases are easy to prepare, save and share with the clients and within team members.
2. All team members in the project including client, developers, testers, designers etc. get updated with the current status of the project.
3. Each member is aware of his/her tasks and get updated with the bugs and changes they have to work upon.
4. Good to make runtime changes particularly with frequent requirement changes.
5. Team collaboration helps everyone work together towards the common goal.
6. Maintains Versions of changes to the documentations as well.
7. Most importantly, keeps transparency towards the client.
I generally use the below template while testing multiple projects in agile and it’s been a great asset until now!
If you have the liberty you can also employ tools like Pivotal Tracker, Redmine, etc. These tools are easy to maintain and offers a user friendly UI to put across requirements and feedback.
Now that I spoke about the testing tools, let’s have a look at few small but important things which a tester can keep in mind while testing the web app:
1. As the requirement changes, the UI does too and at times quick and dirty addition of buttons and links occur. As a tester, you must ensure that the positioning of buttons is consistent with the overall design.
2. Undo links such as cancel, back, previous often gets less attention from the designers as it does not fall in the happy path of the functionality being worked upon. As a tester, you must ensure they get enough attention and user friendly space in the design.
3. At times developers take the liberty to color links in an inconsistent manner than the designer style guide. This happens when they suddenly add a link that is not part of the PSD. As a tester, it is important to ensure things that are not part of the PSD but are yet put in, fits with design consistency.
4. Another place where design looses consistency is usage of capitalization. For example: some buttons remains capitalized while some do not. Keeping a check on this is important for better user experience.
5. Error messages should get listed as per the sequence of fields on form.
6. From cross-browser compatibility perspective, its often better to first get the application stabilize on Firefox and chrome and only then moving to getting our friend IE happy.
7. It is very easy to miss out on a missing icon. Keeping a good eye on that is equally important to justify the hard work that the designer might have put in to get the fine details look good.
8. Communicate with images than words. Use of screenshots to highlight bugs/issues. Use software like ‘Screen Capture’, ‘Fire shot’ so that one (client and developers) can easily understand bugs.
1. No link is left behind. It is often the case that the developer misses connecting the link. Checking each link is functional is our responsibility as a test person. For identification of links you can use ‘Link Checker’ for each page.
2. Make it easier for the developer by using the same tools they do. Install firebug and report any errors that it spits out as it is to the developer. It makes their lives easier.
3. Manual testing is hard and ensuring everything is working as required at times gets tiring. Take a quick 2 minutes break after every feature or do something that you like. That keeps the mind active.
4. A good QA person would be able to spot dependencies. When something new is added or a bug fix just made it, what else could break? Thinking about this constantly ensures new code does not make the old one unhappy.
Live Push today??
In agile testing live push is an important and regularly performed activity. Consequently, it’s difficult for tester to test all functionalities in detail and ensure a stable system before deployment. While going live following things can help:
1. Test all the high priority bug fixes/changes first
2. If any input field gets added that may affect the database then check out for data inconsistency in the associated fields.
3. Report the broken pieces as they occur to you immediately so while you are still testing, the developer can start to fix the broken piece.
4. Be sure to meet the scope for each sprint for each go live.
5. Ensure the environment is stable to execute final round of testing before go live.
6. Regression testing is must. Ensure that a change, or bug fix, does not introduce new faults/bugs.
7. Ensure once again that the application is stable on all the browsers (as per requirement).
8. Update the status immediately as resolved so that everyone in the team can get a feel of the overall status.
9. In short of time if some bugs/issues not resolved before release, inform client with the issues and their severity.
Follow me on Twitter