138 Crowdsourced Software Testing Tips
On the eve of the celebration of first 500 members of The Test Tribe Facebook group, an involuntary initiative took the shape of a varied and formed a rich list of crowdsourced software testing tips.
Software Testers from various backgrounds, domain and technologies poured their bit which was later cherry-picked and curated to form a list of 138 crowdsourced software testing tips. The tips are listed along with their author with a view that it surely will help fellow Software Testers in some form or the other.
Big Thank You to all the Contributors. So here we go.
- Be aware of what tests you perform on the application
- Revise the basics time and again
- Talk to stakeholders. Understand what is important for each stakeholder
- Question your assumptions. Question the team’s assumptions
- Have Backups
- Think Cost vs Value vs Risk
- If you can think well, you can test well
- Serve the stakeholders. Don’t be the gatekeeper. Read Testers: Get out of the Quality Assurance Business by Michael Bolton
- Have your own testing syllabus and follow it
- Tools I wish I had known about when I started coding: Revisited
- Don’t miss this treasure http://www.huibschoots.nl/wordpress/?page_id=441
- Check if someone has already solved the problem for you. Find out if you can solve it in a better way. Understand the importance of context
- Work as a team. Any target that looks impossible becomes possible with a good team
- Understand different domains
- Learn how to learn
- Understand the standards set by industry – W3C, Human Interface Guidelines (HIG) by Apple
- Learn shortcuts of the applications, tools you use
- Talk to other testers. Talk to programmers. See how they perceive testing
- Learn to communicate well. Learn to engage in a healthy discussion
- Don’t pay a lot of attention to numbers alone. They don’t tell you the complete story. Accompany numbers with stories that matter.
- Don’t just think about your customer. Think about your customer’s customer also
- Automation enthusiasts: this is for you: 50+ resources for test automation engineers
- If you are stuck, try different heuristics. Testing Mnemonics – Desktop Download
- 36 Days of Web Testing
- Understand personas based testing
- Understand time zones and check the time zone wherever your application references ‘time’
- Know how to use Test Obsessed’s Test Heuristics Cheat sheet Test Heuristics Cheat Sheet Data Type Attacks & Web Tests
- Before starting the testing, write your test ideas in bullet points
- Try to use a simulator for multiple browsers, multiple versions
Think of below points when considering Mobile security:
- Device Logs
- Out of Memory
- Network Leakages
- Traffic Interception & Tampering
- Disassemble the package or mount file
- Binary Protection
- Intra & Inter-app Communication
- Root / Jailbreak your devices
- SQLite data storage
- Subscribe testing magazines like women tester, testing magazine etc
- Keep a mobile toolkit for mobile testing like how mechanics will have. The kit can have more than one device, USB cables, SIM cards, data cards, sim holder, joysticks, an external hard disk with all the essential software
- Follow as many as testers in the Twitter
- Try to attend bug bounty program
- Install developer version of mobile OS like Android and iOS and contribute your bugs
- Read about Android Material design, color theory, Apple cheat sheets, Android iconography, etc
- Keep yourself updated about the new features of the Android and iOS. Watch World Wide Developers Conference and Google I/O
- Use Genymotion, Android SDK, xCode, Microsoft Visual Studia Emulator and BlackBerry Emulator for the Virtual Devices
- Explain your bug Clearly in the Bug Description. Like what is happening? where is happening? Why is it Happening? The developer should understand our bug in the description itself, if not with the help of screenshots.. if not with Steps to Replicate etc
- Try to replicate the Customers Issues. So that we can get more knowledge on the product. if possible take previous customer tickets, and try to analyze it.
- Read the following software Testing books
- Lessons learned in Software Testing
- Testing Computer Software
- Beautiful Testing.
- How to break software
- How Google Test Software
- Hands-On Mobile App Testing (My Favourite One)
- Software Testing in the Real World
- The Art of Software Testing
- Software Testing Learn in 1 Day
- A friendly Introduction to Software Testing
- Do not hesitate to ask questions of anyone and at the same time do not show ego in answering to any of the questions from anyone.
- Below is the list of software which can be considered to take screenshots
- Snipping Tool
- Mobile Testing- Download Crash File( Android) and plist file (iOS) and analyze the reasons and root causes for the Crash.
- Learn about ADB commands and shell command for the mobile testing
- Learn about how trigger pseudo calls and pseudo messages by using ADB commands in the android testing
- Spend time on the android manifest for Android security testing
- If you test android app, ask iOS user to test and get the feedback and do the vice versa
- Explore Android SDK as much as possible
- Use Burp suite for intercepting the request with mobile apps
- Learn about different error codes
- Try to use the computer without a mouse. Use it with keyboard shortcuts
- Use IPCU to analyze console logs of iOS apps
- While reporting application crash bug/ game crash bug, do attach the crash log.
- Check the UI on different screen sizes.
- Designing for all the varying screen sizes — especially in the Android market is a big challenge. The app has to perform consistently with all of them. If the user sees a screen with elements that don’t align or worse, bleed off the page there’s a good chance they will uninstall the app immediately. For this reason, you need to map all the models the app will support and test the app in each screen size on each device. If two different models have the same screen size, it’s not necessary to test the UI in both devices. For example: If the app supports both the iPhone 5 and iPhone 5s, a test of only one of them should suffice.
- Test for the brute-force attack wherever possible.
- Check for host header injection. Just change the host: value and check whether it’s redirected to the host or not.
- Session ID Prediction- Many web applications manage authentication by using session identifiers (session IDs). Therefore, if session ID generation is predictable, a malicious user could be able to find a valid session ID and gain unauthorized access to the application, impersonating a previously authenticated user.
- Check for CSRF related issues.
- Check for DDOS attack
- Verify that restricted page should not be accessible by the user after session timeout.
- Verify that Error Message does not contain malicious information so that hacker will use this information to hack website.
- Keep an eye on how fast the app is draining Battery while doing Mobile Application Testing
- Ask yourself if you are performing the important(as per your context) tests first.
- Consider discussing your tests/test strategy with fellow tester/developer in your team. Brainstorming brings awesome results.
- Ask your Dev about Root Cause of the defect he just fixed.
- Ask your Dev if there is any impacted area(to be regressed) for the defect he just fixed.
- Are you communicating constructively? Remember that it matters a lot in our Job.
- Practice the skill of Note Taking. It helps almost all the time to a Tester.
- Staying aware all the time is a skill. Practice that. Eg. You want to complete a flow from step 1 to step n. That’s your end goal, but you should still notice the spelling mistake in an overlay message which was there just for a second.
- Study and practice Storytelling.
- Keep developer tools(console) open while you test and keep an eye on script(js) errors if any.
- You are able to add a record. Great. But how much time it took? Keep an eye on response time.
- Catching UI glitches? Great. But are your noticing UI inconsistencies as well?
- Eg. In/on same form/module/page
- Name*: Age * : Not ok.
- Browser Developer Tools: Get familiar with the Network tab. Helps a lot to see what requests are going and what response you are getting even when nothing is reflected on UI due to possible error.
- Browser Developer Tools: Try out Browser compatibility modes in IE. Not 100% same as the actual browser but comes very handy when you need to test on different versions of IE when you actually have just one.
- Do view page source(right click on the page or through developer toolbox) once in a while. See if any information revealed which ideally should not be revealed.
- Try URL tampering.
- Login. View doc. Copy URL. Logout. Hit the copied URL. You should be redirected to the login page again.
- XSS: Try simple script in all the text boxes you see. After that try submit/edit/view. It’s fun. If it executes, that’s a problem. alert(“hello”)
- XSS: See a parameter being passed in the URL of the particular page? Try some basic script there and load the page again. alert(“hello”)
- Security: Have an open sign up page but no captcha/recaptcha implemented? Suggest having so asap to your product owner.
- Use the spell check plugin. One click and you get any/all spelling errors on the page.
- Be a part of at least one testing community. Hustling together will open up way too many learning and growth opportunities
- Consider testing your web app on different screen resolutions/sizes.
- Be aware of the environment in which the application is tested. A defect should be accompanied by the environment details and evidence. This makes the defect clear to understand and reduces to and fro of Developer and Tester.
- Ask people from another department to evaluate the product or feature the product under test. It will certainly bring unnoticed review comments.
- Look deep into Services and Database layer while testing
- Create test ideas for UI and Usability
- Use browser add-ons to assist your testing. You can refer to Smart Mission Focussed Web Testing With Addons & Tools
- Never ever tell the identified bug orally to developers unless the project process states to do so. It’s better to be formal in communicating the defects via Email or logging it into the Defect tracking tool.
Dipak Kumar Das
- While testing a web application try to switch user agent by using User Agent Switcher
- Review plays an important role in Testing, let the seniors review your testing at least once. So that we get to know some missing cases if it’s available. In this way, we also learn the perspective of senior/other Tester on the given task.
- Always share the new things with teammates & introduce the better way of testing if we learn any good thing.
- If junior/senior or any teammate missed anything while testing then avoid doing or saying anything which may demotivate him/her. Just handle the things in a proper way. Do make him/her understand the impact of missing on the project. It will help him/her to improve their skills & make them responsible for their own work.
- If you are in a good network or community then try to involve your teammates as well in this it will help everyone
- Always respect the suggestions of every member of the team. And finally, decide on the things which are good for everyone.
- Do review our own test cases at least once in 2 weeks (mostly in free time)
- Monkey testing is also important sometimes mostly for the e-commerce/ games kind of apps. (As The person who doesn’t know more about the product give some better ideas & bugs)
- Don’t test anything in pressure even if the timelines are closed. Do ask regarding the timelines and take a proper time for testing and do it properly. Else end user will face problems and company repo affect due to that. Give go ahead of your project when you are satisfied. That improves the quality of the product & our testing skills.
- Try to do testing on real devices & if it’s not available then take help of simulator/emulators.
- Make sure you have a solid understanding of requirements before starting the test. No Business Requirement. No wiki article. Boils to No RTM. No effective testing. Ask Product Owners, Dev to ensure one is created.
- Tests cases are to improve the software efficiency, not to demoralize the developers. Be constructive while defect discussion and not defensive.
- Brainstorm the Test cases written. 100 minds lead to 100 different ideas.
- Communication is the key. Persuasive communication can take one tester far ahead than planned.
- Connect with other teams in the project as well. Such as Support Team, Dev Team, Delivery Team. This networking helps you get to keep yourself abreast about their process flow which can of use when fixing on timelines, deliverable dates etc.
- Test to improve not impress
Jits Motabhai Pamnani
- Provide all relevant information in the bug. As much as that dev shouldn’t be feeling the need to put the bug in need more info state. And hence save the overall turn around time.
- May it be browser details or a scrolling screenshot, or in case If steps are little complicated, attach a bug reproducing video.
- Make sure to document your results, not just keep it to yourself, but keep it always published in Confluence. And that way the next iterations of the report would be easily comparable with previous data accessible and available.
- Don’t be afraid to reject story/build/release in case basic validation fails or the software is very buggy. A stitch in time saves nine. It’s better to get the issues fixed early rather than fixing when the client reports them
- Start testing with a positive mindset. Ensure that the happy flow path is covered first and then focus on the negative scenarios. It may happen that to break the software we spend too much time focussing on negative plots and later on face time crunch to cover the functional cases
- Test like a child, test like a techie, test like a tech ignorant, test like dog thumping his nails on screen, test like the laziest, test like a hyperactive
- Don’t forget to add a buffer in overall estimation
- A bottom-up approach where estimation flows from engineer to the manager is found to be better
- Shout out at the slightest feel of estimation going wrong
- Estimations are just estimations they are bound to change. Keep the plan B ready
- See that HttpOnly and secure flags are put to use in making the cookies more secure. Read more about the topic here Protecting Your Cookies: HttpOnly
- Use check my links chrome extension to identify broken links
- Create test cases against bugs logged (if missing) and add them into your test suite
- Keep overlapping sessions with your teammates after a sprint ends, so that fellow colleagues are aware of the features you tested and the entire team is updated with latest features in the application
- Do not test the application with a single global role user, always use a different set of users having specific roles
- Example in the e-learning domain. Teacher & student Role
- In procurement, Requester & buyer Role
- Pay special attention to API Testing. Its important in the world of integration, to understand the connections between systems, databases, and networks to find out the flaws
- Analyse the requirements and try to get in touch with the client with a view of understanding their expectation from the QA team. It happens that sometimes the client expects out of the box scenarios and extensive testing from the QA team. It is always recommended at least to get the scenarios reviewed by the client or project coordinator.
- Try to test the web application on maximum version of each browser. You can make use of Cross Browser testing tools
- Look at UI from a layman user perspective. Ultimately it won’t be that only engineers using the application rather people who may not be that used to technology using it.
- Continue Building a strong foundation of integrity, courage and honesty. Continue shaping your career on that foundation by working smart and hard on your testing skills
- Try to understand the logs as well before showing it to devs
- Understand the severity and priority of every bug. Not every bug can be critical or marked as high
- Communication with fellow testers to avoid duplicacy in bugs
- Note down the eta required for resolving any kind of blocker or critical. As time is also an important constraint.
- Peer review always adds value to your testing effort, don’t forget it!
- Testing seems to be more easier when you have an idea of how’s the architecture working for your feature at backend…
- Practicing well planned and well-designed flow of your testing effort is what makes you a better tester in long run
- Questioning always helps you build a clear picture of how your testing approach for a feature should be like…
- Keep a track of customer issues and ensure that the same is not faced in upcoming releases
- Log every bug that you find in the application, especially not reproducible ones with proper documentation
- In a situation of time crunch, test the riskiest and important modules first based on complexity and frequency of use by the end user
- Create your test design always keeping the end user in mind. The geographical distribution, the browser and/or device usage, etc
- If anything changes in the requirements down the line, ensure that the changes are mapped on all levels of STLC as well.
- Do a regular analysis of problems to trace the bottleneck in the overall process. Its recommended making use of a Pareto chart or fishbone diagram as they help in narrowing down the root cause of problems. Read more with an example Fishbone diagram and Pareto principle
Disclaimer: Testing tips listed above are completely crowdsourced. Opinions expressed/vocab used are/is their own. The Test Tribe team has just made negligible formatting alterations in the original content.