When you hear the term “software testing,” do you think about one particular type of test — such as functional testing or regression testing — or do you immediately start visualizing the complex, interconnected web of test types and techniques that comprise the broad world of software testing?
Most experienced developers understand that software testing isn’t a singular approach, although, in the broadest sense, it refers to a collection of tests and evaluations that aim to determine whether a software application works as it should and if it can be expected to continue working as it should in real-world use scenarios. Basically, software testing aims to ensure that all the gears are churning smoothly and work together like a well-oiled machine.
That said, there are a variety of approaches to software testing, all of which are equally important in reaching a realistic conclusion to the pressing questions facing developers and testers:
Still, it’s not a simple matter of running a few tests and getting the green light. There’s a process to thorough software testing, which entails writing appropriate test cases, ensuring that you’re covering the right features and functions, addressing user experience concerns, deciding what to automate and what to test manually, and so forth.
We’ve covered many different types of software testing in our recent guide to software testing, as well as in many individual posts (check out our testing archives here). Beyond knowing the ins and outs of software testing, it’s helpful to learn from those who have traveled the path before you to learn from their mistakes and leverage the tips and tricks they’ve learned along the way (and graciously decided to share with the development world). That’s why we rounded up this list of 101 software testing tools.
The list features tips and insights from experts on many of the less black-and-white aspects of testing. Such as considerations for choosing the right tests, creating a testing culture that sets the stage for successful testing among teams, prepping for tests, testing with greater efficiency, and other important insights to streamline your testing process and get better results in less time and, often, at a more affordable cost.
Click on a link below to jump to tips to a particular section:
1. Don’t treat quality assurance as the final development phase. “Quality assurance is not the last link in the development process. It is one step in the ongoing process of agile software development. Testing takes place in each iteration before the development components are implemented. Accordingly, software testing needs to be integrated as a regular and ongoing element in the everyday development process.” – Lauma Fey, 10 Software Testing Tips for Quality Assurance in Software Development, AOE; Twitter: @aoepeople
2. Encourage clarity in bug reporting. “Reporting bugs and requesting more information can create unnecessary overhead. A good bug report can save time by avoiding miscommunication or the need for additional communication. Similarly, a bad bug report can lead to a quick dismissal by a developer. Both of these can create problems.
3. Treat testing like a team effort. “Testing is a team effort. You’ll find keeping everyone in the loop from the beginning will save an enormous amount of time down the line.
“When you expose testers to a greater amount of the project, they will feel much more comfortable and confident in what their goals should be. A tester is only as efficient as their team.
“Your goal is to make sure everyone involved in the project has a solid understanding of the application. When everyone understands what the application entails, testers can effectively cover the test cases.
“Communicate with the test lead or manager to allow testers to be involved in the decision-making meetings. Giving testers access to early knowledge will allow them to prepare early test environments. This will avoid any unforeseen issues, preventing any delays or risks while also being cost-effective.” – Willie Tran, 7 Easy Ways To Be An Efficient Software Tester, Testlio; Twitter: @testlio
4. Use tools to make testing easy. “Most technical leads will be familiar with the challenge of getting developers into the habit of making code testable. Therefore, top of your list of objectives should be ‘ease of use.’ Tests should be easy to write, and more importantly, trivially easy to run, by your development team. Ideally, all developers should be able to run all tests, in a single click, right from in their IDE. No excuses!” – Adam Croxen, Mobile automation testing tips, App Developer Magazine; Twitter: @AppDeveloperMag
5. Find your “good enough” threshold. “Everyone wants perfect software, but budget constraints, business priorities, and resource capacity often make ‘perfect’ an impossible goal. But if perfection isn’t your goal, what is? Recognize that the goal of testing is to mitigate risk, not necessarily eliminate it. Your applications don’t need to be perfect — but they do need to support your business processes in time to leverage new opportunities without exposing companies to unnecessary or untenable risk. Therefore, your definition of quality may vary by application. As you initiate a project, get the right roles involved to ask the right questions: What constitutes perfect versus good enough versus unacceptable?
6. Your user documentation should be tested, too. “User manuals are indivisible from software. There’s no software simple to the point where it doesn’t need a user guide. End users are people who can fall under certain categories and be united by the notion of target audience, but, nevertheless, they are still just a bunch of unique human beings. So, some functionality that is clear to one person is rocket science to another. This proves two points: yes, we all need technical documentation so our product is used properly and, yes, this documentation should be approached from many angles and tested thoroughly to be understood by everyone.” – ClickHelp Team, Testing of User Documentation, TestMatick; Twitter: @TestMatick
7. Keep open lines of communication between testing teams. “Opening up the communication lines between the testing teams can do wonders for making the testing smooth. Communications allow the team to compare results and share effective solutions to problems faced during the test. This will also ensure clear assignment of each task. All members of the team should get updated with the current status of the test.” – Tommy Wyher, Top Software testing tips and tricks you should know, uTest; Twitter: @uTest
8. Automation is good, but it doesn’t fix poor test design. “Test design must take into consideration all the areas of testing to be performed, but it should also identify high-risk areas or other specific areas where test automation would add the most value rather than leaving such decisions to be made ad hoc once development is in later stages.” – 10 Tips to Get Started with Automated Testing, Optimus Information; Twitter: @optimusinfo
9. Testing is about reducing risk. “Testing, at its core, is really about reducing risk.
“The goal of testing software is not to find bugs or to make software better. It’s to reduce the risk by proactively finding and helping eliminate problems that would most greatly impact the customer using the software. Impact can happen with the frequency of an error or undesired functionality, or it can be because of the severity of the problem.
“If you had a bug in your accounting software that caused it to freeze up for a second or two whenever a value higher than $1,000 was entered, it would not have a huge impact. However, that would be a high enough frequency to be very annoying to the customer.
“On the other hand, if you had a bug in the accounting software that caused all of the data to become corrupted every 1,000th time the data was saved, that would have a huge impact but at a very low frequency.
“The reason I define software testing in this way is that — as any tester will tell you — you can never find all the bugs or defects in a piece of software and you can never test every possible input into the software (for any non-trivial application).” – John Sonmez, What Software Developers Should Know About Testing and QA, DZone; Twitter: @jsonmez
10. Think outside of the box. “More and more often we have to deal with assuring quality of various IoT developments. They require testers to become real users for some time and try the most unthinkable scenarios. What we recommend is to start thinking out of the box.
“How can a professional manual tester who runs routine tests regularly become more creative? There are some useful pieces of advice that might be of help to any tester:
11. Don’t rely solely on written communication, particularly for virtual teams. “Especially in virtual teams often the only point of interaction between developers and testers are bug tracking system, yet it is especially the written word that causes misunderstandings and leads to pointless extra work. Regular calls and actually talking to each other can work miracles here.” – Andrea, Successful Software Testing – Communication is Everything, Xceptance; Twitter: @Xceptance
12. Develop “rules of thumb” – and document them. “As testers, we often use rules of thumb throughout a project. For example, we sometimes use a total number of expected defects during test planning and then compare actual defects per hour found versus what we would expect, during test execution. Each of these rules of thumb aids us in managing the information we deal with as testers and QA managers.
“It would be nice (and useful) to have a collection of these rules of thumb in one place, each documented with examples.” – Ray Vizzone, Software Testing and Quality Assurance Rules of Thumb, got bugs?
13. Conduct code reviews. “Four eyes see more than two. That’s why you should let other developers review your source code on a regular basis. Pair programming, on the other hand, a technique where two developers write code together for longer periods, isn’t for everyone and is often not needed. But complicated, important or security related code greatly benefits from code reviews and will improve your code quality a lot.” – Dennis Gurock, 12 Practical Tips for Building Bug-Free Software, Gurock Quality Hub; Twitter: @gurock
14. Manage defects in code during development, particularly for complex code. “Rather than rely on traditional QA testing methods, Developers and development managers should also be able to quickly and easily manage the defects in their code – especially where code is complex. This includes prioritizing defects based upon impact and filtering defect information to view only what’s relevant to them. Once the defects have been prioritized, developers should be able to automatically find all of the places the defect exists across projects and code branches – thus minimizing duplication of efforts. Then they should be able to collaborate with other developers to share triage information across distributed teams and geographic boundaries.” – Chris Adlard, Five Tips to Make Software Testing Easier, Database Trends, and Applications; Twitter: @dbtrends
15. Report findings in the context of business value. “Focus on the data that is being communicated back to stakeholders, from your findings as part of testing – the data should be in context of ‘how’ the behavior observed is detrimental to the objective of the feature or application being developed.” – Mush Honda, 9 Steps to Becoming a Great QA Lead, KMS Technology; Twitter: @kmstechnology
16. Engage the end user. “Probably the most important person in the whole process, yet many times we may be tempted to keep them at arm’s length; you should involve the customer actively. Have them give frequent feedback on the product for future improvement and development; software developers who respond quickly to customer feedback are generally more successful.” – 5 Tips for Developing an Effective Software Quality Testing and Assurance Culture, Techno FAQ; Twitter: @Techno_FAQ
17. Always keep learning. “[The] IT field changes; way [faster] than some of us would like.
“If you are not constantly updating your skills, you could get irrelevant, obsolete and outdated. In a world of lay-off paranoia, it is a good idea to rise above it all, gain immunity and feel secure. The best way to do so is to make learning a habit.” – Swati Seela, How Can Testers Embrace Learning and Keep the Spark Alive?, Testing Excellence; Twitter: @TestingExcel
18. Bug summaries must be thorough. “Most customers including your managers, developers, and peers will read the summary first when they review a bug. This is especially true when they have more bugs to review.
“The simple reason is that they don’t have enough time to go into details of every bug, so having a short and concise summary will surely help to grab an idea of what the problem is about and how important it is.
“You can have a short and concise summary by telling exactly what problem you found and in what condition.” – Thanh Huynh, LogiGEAR Magazine; Twitter: @logigear
19. Use Test Maturity Model integration. “The software industry does not operate in a zero-defect environment, and, arguably, it never will. In the face of this truism, numerous techniques to reduce the number and severity of defects in software have been developed, with the ultimate, albeit unobtainable, goal of defect elimination. Such optimistic thinking has led to significant improvements in software quality over the past decade, notwithstanding increased software complexity and customer demands.
“One such defect elimination approach is maturity models. Broadly, these are structures which state where an organization sits on a maturity scale, where its failings lie and what should be done to improve the situation using process improvement frameworks. The archetypal maturity model is the Capability Maturity Model Integration (CMMI)2, in addition to its predecessor, the Capability Maturity Model (CMM).” – Dr. Mark Rice, Test process assessment: climbing the maturity ladder, Software Testing News; Twitter: @testmagazine
20. Always start with a product map. “Early on in the project you should spend some time exploring the software, and try to model the features and requirements of the product. A graphical model (for example, a mind map) can provide a concise, easy-to-understand representation of the product, and the modeling process is likely to help you uncover features that you may not previously have been aware of.” – ChengVoon Tong, Top 3 tips for software testing a mature product, Redgate; Twitter: @redgate
21. Getting testers involved from the start means you can eliminate many errors even before reaching the development stage. “When testers start working on the project from the very beginning, they make sure that many errors are identified and eliminated even before the development phase. Writing test scripts, quality testers assist developers that can later use these scripts for making product creation easier. Thus, involving testers into work at the first stages of development has a range of advantages: helping the team to understand customers’ goals, saving a lot of time, minimizing expenses, and optimizing the approach to testing.” – Mark, Top 7 Tips for Choosing an Outsourcing Software Testing Team, The Merkle; Twitter: @themerklenews
22. Choose flexible test management tools that can adapt to your needs. “No two businesses are the same which might mean a particular tool is best-suited for a situation different to yours. Keeping this in mind, you should look for a test management tool which not only fits your day-to-day testing needs today but should also offer flexibility if your testing approach changes course in the future.” – Sanjay Zalavadia, 5 Most Important Features to Look for in Test Management Tools, Quick Software Testing; Twitter: @quickswtesting
23. Create sample test data if needed. “Depending on your testing environment you may need to CREATE Test Data (Most of the times) or at least identify a suitable test data for your test cases (if the test data is already created).
“Typically test data is created in-sync with the test case it is intended to be used for.
“Test Data can be Generated –
“Typically sample data should be generated before you begin test execution because it is difficult to perform test data management. Since in many testing environments creating test data takes many pre-steps or test environment configurations which are very time-consuming. Also If test data generation is done while you are in test execution phase, you may exceed your testing deadline.” – Tips and Tricks to Generate Test Data, Guru 99; Twitter: @guru99com
24. Aim for stability. “Stability is always important; your tests must always run and spit out the correct results. What good is having a test suite if it’s giving you false positives and negatives?” – John Howard, Tips & Tricks for creating a great Automated Testing Suite, uTest; Twitter: @uTest
25. Make sure developers have the test cases. “It is considered a good practice if tester gives his test cases to the developer to verify that all the important functionalities are developed properly before he releases the application for further testing. It ensures that re-work would be minimum since most important part of the application is taken care by the developer himself.” – Software Testing Tips And Tricks For Testing Any Application, Software Testing Class
26. Follow a proven process for functional testing. “Functional testing reviews each aspect of a piece of software to make sure it works (aka functions) correctly. Quite simply, functional testing looks at what software is supposed to do and makes sure it actually does that. So while functional testing looks at an application’s ability to execute, non-functional testing looks at its overall performance (e.g. by testing scalability, reliability, security, and compatibility).
“When conducting functional tests, you typically need to follow a process that looks something like this:
“Following this method, if the expected results and the actual results match, then you can conclude that the software functions properly and the test has passed. If they do not match (assuming you properly understand what the outcome should have been and used the correct input), then there is an issue with the software.” – Functional Testing Types – 25 Best Practices, Tips & More!, QA Symphony; Twitter: @QASymphony
27. Understand the data flow. “When you know how the data travels inside your application, you are better able to analyze the impact of component failures and security issues. Hence, recognize how the data is used within the application early on in order to report bugs and defects faster.” – Eight Tips to Be More Effective in Agile Software Testing, MSys Technologies; Twitter: @MSys_Tech
28. Write your tests for the correct features to cut your maintenance costs. “What’s the easiest test to maintain? The one you didn’t write.
“UI automation is hard. It’s a difficult domain to work in, the tests are slower to write than other tests, they’re slower to run, and they’re harder to keep working. If you want to keep your maintenance costs as low as possible, carefully consider what you’re writing your UI tests for.
“Focus your UI automation efforts on high-value features. Talk with your stakeholders and product owners. Find out what keeps them awake at night. I’ll bet it’s not whether or not the right shade of gray is applied to your contact form. I’ll bet it’s whether customers’ orders are being billed correctly. I’ll bet it’s whether sensitive privacy or financial information is at risk of being exposed to inappropriate visitors to your site.
“Automate tests around critical business value cases, not around shiny look-and-feel aspects of your application.
“Write your tests for the correct features. It will cut your maintenance costs dramatically.” – 10 Tips on How to Dramatically Reduce Test Maintenance, Telerik; Twitter: @Telerik
29. Channel an attacker for security testing. “Try to get into the mindset of a potential attacker. Just as you try to emulate the end user when software testing, with security testing you want to emulate an attacker. It’s fair to assume that they’ll seek entry via the path of least resistance. Start with the most common methods and attack scenarios. But it’s important to remember that nothing’s off the table because an attacker will do anything that will get them the data they want.” – Simon Hill, 8 tips for security testing web applications, Crowdsourced Testing; Twitter: @crowdsourcingqa
30. For apps, including the device in your testing plan is imperative. “An application that comes packaged on a consumer-grade laptop or notebook for a police squad car will not withstand the rigors of high-speed chases and constant bangs and knocks. Part of the application testing strategy, if you are developing for situations like this, should include the testing of the robustness of the device itself in adverse operating conditions. If you fail to include the device in your test plan, the app might be great — but it might also crash at a critical moment if the end device fails.” – Mary Shacklett, 10 tips for testing apps for the real world, TechRepublic; Twitter: @TechRepublic
31. Test-writing methodologies and concepts must be grasped before using automated tools to “turn the crank.” “When I hear about these new testing tools, I generally view them as new methods to turn the crank in testing. Anything can execute a test plan, after all, there’s no fundamental reason why a human needs to run through a test plan versus a machine. Both are capable of turning the crank. There’s also no fundamental reason why a human needs to write a test plan either. Well, other than machine learning hasn’t gotten that good yet.
“The part many of these tools seem to leave out is how these tests get written. The methodologies and concepts need to be grasped before you start turning the crank. Extracting anything useful from automated testing requires a robust set of test cases. You need to have clear goals – launch the app, poke this set of buttons, get this result. This is true regardless of which method is used.” – Kirk Chambers, QA tips and tricks: Why a clear and robust test plan is essential, Possible Mobile; Twitter: @POSSIBLEmobile
32. Avoid cross-browser variation. “On a new project, you might be tempted to use a slew of emerging browser capabilities. You will often need to use feature detection so that visitors with older browsers get a usable fallback. This means that you need to test the same feature across browsers with different expectations of what is correct.
“It can be easy to get carried away using the latest tech, but a significant part of your audience may be using older, less capable browsers. Sometimes it is better to use a well-established approach for everybody.
“By using newer browser features with inconsistent support, you are deliberately introducing cross–browser variation. We know from the Browser Wars of the 1990s that this comes at a cost.
“Pick the technologies you use with care. Restrict your choice of newer features to those that will have the biggest net benefit to the user.” – Jim Newberry, 31 Ways to Spend Less Time on Manual Cross–Browser Testing, Tinned Fruit; Twitter: @froots101
33. Define entry and exit points. “Understand your software application being tested completely. Here, we do take care of when and how the testing of a particular testing phase will start and end. So, this will help us to decide how and which automation testing framework can be involved for a particular testing stage.” – Manish Verma, Top Software Testing Best Practices and Automation Strategy, Software Testing Mentor; Twitter: @swtmentor
34. Run a pilot project before full-scale automation testing tool adoption. “Generally, a pilot project is kick started by preparing a business case describing the objectives of the project and outlining the methodology how the project shall be carried out. A realistic time plan along with metrics for the determination of the success is an essential part of the business case. For instance, the testing engineer may like to reduce the time to run the regression tests from a week to a day. Actually, applying the ‘don’t be overly optimistic’ rule, it may be better to set a target such as reducing the time for 20% of the tests by a factor of 50%. This may result in a five-day regression test taking four and a half days, but might be a much easier target to hit.
“The pilot project must not be either too short or too long, may be from 2 to 3 months. Subsequent phases of the pilot project could extend this time beyond 3 months but each phase should have measurable objectives. If the pilot stretches for a longer period without significant results, it would cast a shadow of doubts on the viability of the overall test automation. It is better to accrue smaller benefits in the beginning may be in bits and pieces, being less risky rather than gaining much larger benefits that are projected later.” – Importance of doing a Pilot Project before Full Scale Automation Tool Roll Out, Software Testing Genius
35. For testing mobile apps, emulators can be useful, but they can’t perfectly replicate a real-world operating system. “Some tech experts use emulators for application testing. And it is good because an emulator is a powerful tool that makes app testing easier and cheaper. However, emulators lack many features inherent only to real operating systems. Considering Murphy’s Law, any missing feature in the emulator that CAN go wrong in the real environment, WILL go wrong and cause troubles. So, before release, test an application using target OSs on physical mobile devices.
“Moreover, it is necessary to check how your application works on different versions of the target operating system. For example, if your application is intended to work on iOS 9, then try 9.0, 9.1, 9.2, etc.” – Mobile App Testing Tips & Tricks, Skelia; Twitter: @Skelia_company
36. Don’t underestimate the impact of maintenance overhead. “This one is particularly tricky. People often do not realize the cost of maintaining an automated testing infrastructure. If you are writing test scripts for a rapidly changing application, you should gather all the information that you need and then take some time to come up with an estimate for this overhead. Having a solid testing setup really makes the difference here: fixing broken tests is faster when you have clean, readable test scripts with little to no duplicated code. Following a pattern such as PageObject can help you build such a setup.” – Giovanni Rago, Top 5 Mistakes That Can Sabotage a Successful Test Automation Project, SauceLabs; Twitter: @saucelabs
37. Test the instructions. “If a test has too many twists and turns, you’re testing users, not the website. Ask someone else on your team to try the test (not just read the steps) and have them note any unclear or confusing instructions. Run a pilot test and see if you get the intended results.
“Save big picture questions for the summary, when test participants have completed all tasks and have a moment to reflect.
“Tip: Request the same test participants for later rounds. This allows you to test the experience of repeat visitors and find out whether you’ve addressed their feedback.” – 12 Tips for Top Test Results, User Testing; Twitter: @usertesting
38. Consider the complete, end-to-end user journey. “A user journey is a series of steps which represent a scenario in which a user might interact with a system. Typically, a user journey has a starting point, i.e. an entry point into the system, a series of transitions from one state to another and a set of triggers which cause the transitions.
“User journeys can help you identify customer behavior and how the users use the system or how they could potentially use the system.
“When we are creating user journeys, we need to be thinking about:
“The important part here, is that a User Journey is a ‘mental’ and ‘lived’ experience. The journey is deeply linked to ’emotions’ and these emotions usually have a bearing on the users perception of quality.
“Whilst some of the above factors can be accounted for when writing automated tests, we certainly cannot know about user’s emotions, it is for this reason you cannot automate a user journey.” – Amir Ghahrai, Can You Really Automate a User Journey?, Testing Excellence
39. User personas are the foundation of successful software testing. “Do you know what’s the most important part about any existing User Story? Users that will potentially be behind it. Stories we are talking about must be aimed to describe how people will actually use your app. Therefore appropriate stories should be designed from their perspective. User Stories should also capture precise and accurate pieces of information like why and how would a certain person log in the app. Not more, nor less.” – Complete Guide Through Supreme User Story Creation, TestFort QA Journal; Twitter: @Testfort_inc
40. Embrace exploratory testing. “We are all accustomed to reading books about projects that include complete specifications, iterations, test plans, and other benefits of a formal development process. But usually we just get pathetic hints of documentation in a real life setting. Sometimes a tester will hear such the phrase, ‘Hey, let’s test this!’ What should you do when such a shaky moment arrives at your doorstep?
“The answer is simple – you need to learn!
“There is one such testing technique that is called ‘Exploratory Testing,’ which can actually turn out to be your life vest. The essence of this technology is testing during the time which the project is being studied. All deeper analysis of the application’s functionality will help us understand what we need to check and how we can proceed. It also reveals all the week sides of the application. Although many people are skeptical about this technique, even in projects where the tester has thoroughly documented his work. This technique, can however, in many cases, bring good results. After all, real people are not robots, and their actions are not scripted.” – Eugene Korobka, 6 important Software Testing Tips from our QA team, Rozdoum; Twitter: @rozdoum
41. Don’t skip load testing. “Why is load testing so important? The world is a big place, and even if your application is brand new and you’re still trying to grow your user base, chances are more than one person will try to use it at any given time. If you’re not able to handle those users and that traffic, your company and application isn’t able to put your best foot forward. Spotty behavior and flaky availability can give people the impression that your application isn’t polished and professional enough to meet their needs, potentially causing them to look for a solution elsewhere.
“Through load testing, and making improvements and changes based on the results of that load testing, you can be better prepared for your users and give them the best possible experience.” – Why You Should Be Load Testing Your Application, Test Talk; Twitter: @te52app
42. Triggering bugs requires a perfect storm, so some bugs will inevitably be discovered in the wild. “Sometimes triggering a bug takes the perfect storm of the right (or wrong?) web browser, browser version, OS, screen dimensions, device…because testing can never cover everything, it’s possible that you’ll never hit that specific bug-triggering combination. When that happens, a bug may slip through to production and stay hidden until a user discovers it ‘in the wild.'” – Cullyn Thomson, 4 Reasons Bugs Are Missed, QA Intelligence; Twitter: @CullynT
43. Write logical acceptance tests — and do it early. “During the release planning meeting, capture acceptance criteria and immediately add them as logical test cases linked to the product backlog item. This will help the team to understand the item and clarify the discussion. An even more important benefit of this tip is that it helps testers be involved and be important at the early stages of the software cycle.” – Clemens Reijnen, 5 Tips for Getting Software Testing Done in the Scrum Sprint, Methods & Tools; Twitter: @methodsandtools
44. Make sure you understand the risks. “When planning testing, whether it’s a long term plan or a short one for a single test session, you’d better try to keep in mind the risks involved with the features under test. It helps you organize your time and efforts and gives a quick feedback on the riskier parts that may compromise the functionality of the product.” – Belen Arancibia, 10 Tools and Tips for Better Testing, Belatrix; Twitter: @BelatrixSF
45. Test for usability. “Yes, we are testing the functionality, but basic usability issues could be easily caught and submitted without even applying the usability standards and special checks.
46. Don’t cheat on performance tests. “In the real world users may spend anywhere from a few minutes on a typical website up to a few hours on a SaaS type web application. For example, perhaps the application you’re going to test needs to support 5,000 concurrent users that have an average visit length of 20 minutes. In the course of the peak hour the site is expected to serve 1 million page views.
“Rather than use 5,000 virtual users to generate the load over the course of an hour, you figure you’ll just use 500 virtual users and drop your session length down to two minutes… essentially cutting everything by a factor of ten. You will use less virtual users to generate the same number of page views. Many performance testers are doing this with no idea of how it actually translates to in load on the downstream systems. Well, here is the bad news… at multiple points in the infrastructure this is going to result in, you guessed it, about ten times as much load as there should be.
“It has a load balancer at the top, some web servers, some application servers, and a database cluster. There are typically firewalls in front of and in-between a few of the tiers. Here is a short list of some of the unnatural behaviors that can occur in the environment as a result of cheating the performance test cases:
47. Adopt an Agile testing mindset. “Historically, the role of the software tester was mostly to sit within a team of testers, often producing large documents such as test strategy and test plans as well as detailed test scripts. This method of working also implied that the testers are generally abstracted from the whole software development process and only come in at the later stages when the software was already developed.
“Nowadays, testers within an agile context, are required to be multi-skilled, technical, collaborative and have an agile mindset. Testers are under tremendous pressure to release applications more quickly, and companies are pushing testers to make changes in their mindset, from skillsets to coding, to understanding how the business functions and dealing with customers. Testers must evolve.” – Amir Ghahrai, Traditional Tester vs Agile Tester – What are the Differences?, Testing Excellence
48. Emphasize code quality. “Quality is not a universal value. It is defined by standards, specifications, numbers, factors and different parameters. Hence, when a company wants to develop a high-quality software system, it considers a great number of aspects. Code quality takes one of the leading positions in the list.
“Software analysis experts agree that code quality has a remarkable growth of attention and demand these days. They confirm that continuous development of a software system makes the source code significantly complicated after numerous updates. Therefore, the team has to analyse the code on a continual basis to keep the code base in a good maintainable state. This will prevent uncovered technical debts, system crashes and expensive fixes.” – Sergey Terekhov, Defining and tracking the code quality, Software Testing News; Twitter: @testmagazine
49. Utilize smoke testing. “Smoke Tests are a kind of basic, non-extensive software testing practice, where you put the code developed so far through fundamental, ‘happy path’ use cases to see if the system breaks.
“If it does, you go back to fix the system because it is in no way, shape or form ready for more extensive and scientific testing. And if it doesn’t, you know you’re on track and that the fundamental features the system is designed to provide, work.
“That’s smoke testing in a nutshell for you, my friend. It’s as simple as – at any given point in time – putting the product built thus far through a rudimentary series of happy path tests, to help bring out the simple yet critical bugs.” – Ulf Eriksson, 11 Quick Tips to Master Smoke Testing, ReQtest; Twitter: @ReQtester
50. Run an agile beta test. “The single most defining feature of agile beta tests is the very short period of time available for the beta testing phase. Companies that ascribe to the agile method ‘release early, release often,’ so you need to gather feedback from users quickly in order to keep everything on track.” – Jon Perino, Tips for Tackling Agile Beta Testing, Centercode; Twitter: @Centercode
51. Regression testing is a crucial step. “Regression testing involves testing the entire application (or at least the critical features) to ensure that new features or bug fixes haven’t inadvertently caused bugs to appear in other areas of the application.
“Because of its scope, regression testing is typically a process that involves automated tests, or at least some level of scripted manual tests to ensure that the key components of the application are tested.” – Mike Sparks, Software Testing for Hidden Bugs, Test Talk; Twitter: @te52app, @mdpsparks
52. Apply tests during the requirements analysis phase for better results. “First of all, software testing process is based on the software development process. Software development life cycle (sdlc) includes the following steps:
“As it shown in the list above, we should perform the required tests is the fourth stage of the life cycle. But usually, if the main goal is to get a high-quality software and minimize the cost of bug-fixing, we can apply tests during the requirements analysis phase. The earlier you start the tests, the better results you get.” – Oksana Levkovskaya, Software Testing Life Cycle (STLC): Benefits and Major Testing Steps, XB Software; Twitter: @xbsoftware
53. Ensure maximum test coverage. “Breaking your Application Under Test (AUT) in to smaller functional modules will help you to cover the maximum testing applications also if possible break these modules into smaller parts and here is an example to do so.
“E.g: Let’s assume you have divided your website application in modules and accepting user information is one of the modules. You can break this User information screen into smaller parts for writing test cases: Parts like UI testing, security testing, functional testing of the User information form etc. Apply all form field type and size tests, negative and validation tests on input fields and write all such test cases for maximum coverage.” – SiliconIndia, 20 Top Practical Testing Tips A Tester Should Know, SiliconIndia QA City; Twitter: @SiliconIndia
54. Do you need to test your API? “Testing API is like testing any other interface into the software. You have to make sure that it is bug-free before shipping.
“It resembles testing on the UI level but instead of just using data input and output, API tester makes calls to the API, receives output and puts down the actual result as opposed to the expected one. You can perform it using special test solutions (for instance, Postman) or as API testers frequently have to do, write API test code.
“The purpose of API test code is to issue a request to the API, output and note down the expected, actual results, and the time within which the response was delivered.” – API Testing – What? Why? How?, TestFort QA Journal; Twitter: @Testfort_inc
55. Find difficult bugs by experimenting with unusual behaviors. “After completing all the planned test cases there is a need to allocate some time to test the system functionality randomly, trying to create some unusual situations or behaviors.” – Natalia Vasylyna, Tips and Tricks to Detect “Difficult” Bugs, QA TestLab; Twitter: @QATestLab
56. Web services apps can be tested in isolated components. “More websites are being built using web services. These provide an opportunity for testers to test the web application in isolated components rather than a full blown integrated web application.
The benefits of testing web services in isolation are:
57. If a test (case) can be specified in a rule – that MUST be automated. “Automation code is software – thus, obviously is built on some kind of specification. Most GUI automation (QTP, Selenium) is typically built based on so-called ‘test cases’ written in human language (say English). It is the first question that a automation guy will ask while starting automation – ‘where are the test cases?.’ In dev world – automation takes a different meaning. In TDD style automation (if you call TDD tests as automation) – test is itself a specification. A product requirement is expressed as a failing test to start with. The approach of BDD throws this context to other boundary, specify tests in the form of expected behavior. So, automated tests are based on specification that is a human language but expressed in business terms (mainly) and with a fixed format (Given-when-then).” – Shrini Kulkarni, Two important lessons for success of Test Automation, Thinking Tester; Twitter: @shrinkik
58. Unscripted exploratory tests are one of the best ways for testers to examine usability. “When it comes to exploratory and interface testing, humans still beat machines by a long shot. While we’re making big strides with machine learning, having a human tester poke around a product to see what they discover is still one of the best ways to truly test the quality of a piece of software. After all, users are real people, so why not test with real people, too?
“These unscripted exploratory tests can mean the difference between shipping a product that should work fine, and a product that actually works. Usability can be a serious roadblock to adoption, and testing a feature for acceptance is a critical aspect of QA. Manual testing is critical because it helps you test the product from the perspective of a user, making sure that by the time it hits your customers, it’s ready for them.” – Ashley Dotterweich, Is manual QA a poor use of time?, Rainforest QA Blog; Twitter: @rainforestqa
59. Recognize that automation can have errors. “Like any piece of code, your automation will contain errors (and fail). An error filled automation script may be misinterpreted as failed functionality in your tested application, or (even worse) your automation script will interpret an error as a correct functionality. Manually testing your core, critical-path functionality ensures that your test case is passing from a user perspective, with no room for misinterpretation.” – 8 Reasons Why Manual Testing is Still EXTREMELY Important, 3Qi Labs; Twitter: @3qilabs
60. Each function added to a model is a target for tests. “In particular, I like to test the complete behaviour of an action from the user’s point of view. This is what BDD preaches and it is the process on which I rely for creating tests. With this principle I’m not going to test the specific function which activates a button, I’m going to test the final state of the app after the user presses the button.” – Fernando González, Some Helpful Tips & Tricks for iOS Testing, LateralView, Medium; Twitter: @lateralview
61. Unit test every time you need to minimize risk. “Unit test your product every time you need to minimise the risk and possibility of future problems. Unit testing is best utilised to smooth out the rougher edges of software development and is relatively cheap to perform when compared with, for example, the cost of delivering a broken build for user acceptance testing. Unit tests will help to identify problems during the early stages of the development cycle, before they reach the customer and the testing team. When problems are uncovered during code design and implementation, they’re likely to be fixed faster and at less cost. Each completed unit test brings you closer to a more robust and reliable system.” – Andrew Smith, 10 Unit Testing Tips You Should Follow In Every Language, Ministry of Testing; Twitter: @ministryoftest
62. After functional testing, conduct integration testing. “Checking the data flow between the modules or interfaces is known as Integration testing.
“In Integration testing we check if the data created in one module is reflected or transferred or shown in other respective modules.” – Types of Integration Testing in Software Testing, OnlineQA.com
63. An automated vulnerability scanner can be helpful for streamlining security testing. “A good commercial option is Burp Scanner; there are also free options such as OWASP’s ZAP and Google’s RatProxy. These work by routing the HTTP traffic to and from an application through a proxy, and then resending the requests with various attack attempts replacing the original values. This can be an effective way of finding certain classes of vulnerability in a short amount of time, but it is important to understand (and make sure that your stakeholders understand) that this is not a magic bullet. The tool is naive, and has no knowledge of the applications business logic – it is simply replaying requests and checking the responses. There are many types of vulnerability that can not and will not be found with this strategy, and use of a scanning tool absolutely does not replace the need for manual security testing.
“Automated tools, even expensive ones, find only relatively simple vulnerabilities and they usually come up with a lot of ‘noise,’ or false positives. You need to know enough about security vulnerabilities to be able to evaluate each finding of the automated tool. Taking a scanner report and sending it unverified to the developers is the worst possible thing one could do.” – Mark Hrynczak, 13 Steps to Learn & Perfect Security Testing in your Org, Atlassian Blog; Twitter: @Atlassian
64. Address signup and login issues. “This may seem like a no-brainer, but if users cannot easily access your application, your efforts will have been wasted. If your app or mobile site requires password and username (not recommended), pay close attention to the fields and make sure that it’s easy for users to enter their information.” – The Essential Guide to Mobile App Testing, uTest; Twitter: @uTest
65. If you have a stand-alone mobile app or a mobile app that complements a desktop app, consider how different connections will impact performance. “A desktop is immobile. It sits in one area and stay there, more or less, for the life of its use. Connected by wire, the connection is stable and usually fast. A mobile device is, well, mobile. The user is constantly moving from place to place, and from one coverage area to another. You have to make sure that different local connections won’t affect the performance of your mobile application.” – Steven Machtelinckx, The Testing Challenges You Face When Your App Goes Mobile, TestingMinded
66. It’s like they always say: if you fail to plan, you plan to fail. Or in this case, you plan to be inefficient. “It is necessary to have test plan written by experience person like QA lead or manager. While creating test plan you need follow an organized approach to make it good test plan. The good test plan must cover Scope of testing, test objectives, budget limitations, deadlines, test execution schedule, risks identifications and more.” – 15 Tips on How to make your software testing more efficient, Software Testing Class
67. Snoop on your competition to discover common mistakes. “When planning your testing activities, look at the competition for inspiration – the cheapest mistakes to fix are the ones already made by other people. Although it might seem logical that people won’t openly disclose information about their mistakes, it’s actually quite easy to get this data if you know where to look.
“Teams working in regulated industries typically have to submit detailed reports on problems caught by users in the field. Such reports are kept by the regulators and can typically be accessed in their archives. Past regulatory reports are a priceless treasure trove of information on what typically goes wrong, especially because of the huge financial and reputation impact of incidents that are escalated to such a level.
“For teams that do not work in regulated environments, similar sources of data could be news websites or even social media networks. Users today are quite vocal when they encounter problems, and a quick search for competing products on Facebook or Twitter might uncover quite a few interesting testing ideas.
“Lastly, most companies today operate free online support forums for their customers. If your competitors have a publicly available bug tracking system or a discussion forum for customers, sign up and monitor it. Look for categories of problems that people typically inquire about and try to translate them to your product, to get more testing ideas.” – Gojko Adzic, To improve testing, snoop on the competition, Gojko.net; Twitter: @gojkoadzic
68. Instead of writing a multitude of test cases, focus on writing better ones. “It’s really tempting to have a lot of test cases running when you’re trying to identify the bugs in your programming. But rather than have a lot of half-baked test cases, you should write fewer, but more effective ones.
“Read the requirements of the software, break these tests into sets and subsets, look at similar test cases, and practice, practice, practice.
“You’ll be writing better test cases in no time.” -, Aditi Consulting; Twitter: @TopTechStaffing
69. Focus on high-priority bugs. “High Priority Bugs should be prioritized on testing. These bugs have greater impact on the system and usually, it takes up more time in terms of testing. Mainly due to the complexity of the bug or perhaps the level of significance of it to the end-users.” – Kevin Clay Badilla, Tips for Effective Software Testing, Ideyatech; Twitter: @ideyatech
70. Conducting user testing? Make sure you have the “right” users. “Suppose, you are recruiting users for testing a ‘yet to be released’ mobile yoga app that caters to Ashtanga Yoga aspirants. There are several formats of yoga in the market, especially in the western world. Hence, it is important to note that many Ashtanga Yoga practitioners believe that theirs is the most authentic form of yoga ever. Which users from this large community should we consider for user testing of this particular yoga app? Who do we recruit? How do we recruit? On what basis?
“Identifying the right kind of users is a challenging task. Many organizations follow the ‘hallway testing’ approach where users are randomly chosen as though there were walking in the hallway. These users may not be the best possible sample given diversity factors like geographies, culture, age group, profession, tech-savvy-ness and so forth. It is always good to know who are the users and what are their key characteristics. Without this information, we might just react like horses with blinkers on.
“In above mentioned context, consumers of this app are yoga practitioners, teachers, students and general public. These people may or may not be the users we are looking for. Few of them may not even know how to use a mobile app. Some might be extremely tech-savvy and represent a fairly good sample. Recruiting users depends on asking the right questions depending on the context of the product. The user testing team can design a ‘User Recruitment Questionnaire’ that helps to screen users and shortlist the most suitable candidates.” – Parimala Hariprasad, Recruiting Users for User Testing, An Aspiring UX Alchemist; Twitter: @CuriousTester
71. Do you need independent testing staff? “While all projects will benefit from testing, some projects may not require independent test staff to succeed.
“Which projects may not need independent test staff? The answer depends on the size and context of the project, the risks, the development methodology, the skill and experience of the developers, and other factors. For instance, if the project is a short-term, small, low-risk project, with highly experienced programmers utilizing thorough unit testing or test-first development, then test engineers may not be required for the project to succeed.
“In some cases, an IT organization may be too small or new to have a testing staff even if the situation calls for it. In these circumstances, it may be appropriate to instead use contractors or outsourcing, or adjust the project management and development approach (by switching to more senior developers and test-first development, for example). Inexperienced managers sometimes gamble on the success of a project by skipping thorough testing or having programmers do post-development functional testing of their own work, a decidedly high-risk gamble.
“For non-trivial-size projects or projects with non-trivial risks, a testing staff is usually necessary. As in any business, the use of personnel with specialized skills enhances an organization’s ability to be successful in large, complex, or difficult tasks. It allows for both a) deeper and stronger skills and b) the contribution of differing perspectives. For example, programmers typically have the perspective of ‘what are the technical issues in making this functionality work?’. A test engineer typically has the perspective of ‘what might go wrong with this functionality, and how can we ensure it meets expectations?’. A technical person who can be highly effective in approaching tasks from both of those perspectives is rare, which is why, sooner or later, organizations bring in test specialists.” – Software QA and Testing Frequently-Asked-Questions, Part 1, SoftwareQATest.com
72. Automated testing can save both time and money. “It’s been found time and again that the automated method of testing software is much more effective and efficient, and even in the short-term, a cheaper choice than setting humans in front of computers. With automated testing, every possible input and usage combination is tested out in every possible combination, multiple times, and in multiple environments (operating systems, operating system versions, and computer hardware). By taking the extra time to automate testing in this manner, developers and testers alike can be assured that any bugs found will allow for solutions that make the software compatible for all end users, regardless of what type of computer and operating system they use. Adaptive diagnostic reasoning and the other components that make up automated testing software solutions is cost-effective and efficient, and you’ll want to utilize it prior to releasing your software to the general public.” – Software Testing Tips for your small/big Business, Sky Tech Geek; Twitter: @skytechgeek
73. Prioritize automation based on the tests that will need to be run most often. “When choosing tests to automate, prioritize tests that will need to be run many times during the project. Some common candidates for automation are:
“By letting automation handle these basic functionality tests, you’ll save the most time and effort.” – Yolanda Hyman, 7 Automated QA Testing Tips for the Manual QA Tester, Atlantic BT; Twitter: @atlanticbt
74. You should also look at tests with repeatable execution as candidates for automation. “You shouldn’t try to automate everything. In fact, not everything is automatable. When planning what test cases to automate here are some things to look for:
“The more repetitive the execution is, the better candidate a test is for automation testing. However, every situation is different.” – Joe Colantonio, Automation Testing Resources & Best Practices, Joe Colantonio; Twitter: @jcolantonio
75. Divide and conquer. “There are almost no real complex tasks, as long as you are willing to look for ways to break them into smaller and simpler components.
“Many times I meet QA managers who explain to me how they manage their tests using a small number of (very long) excel sheets or wiki pages. When I ask them why do they work this way they explain to me that they started with small documents that grew over time…
“One of the first pieces of advice I give these managers is to divide and conquer. By breaking down their very long and complex testing procedures into smaller and more modular test cases, they can gain flexibility and achieve faster and more accurate coverage.
“But this advice is not only good for the size of test cases. If you look into any testing tasks and break it down into smaller testing tasks then you will be able to manage your team more efficiently and provide better visibility to your internal customers.” – Joel Montvelisky, 5 simple tips to keep testing simple, PractiTest; Twitter: @PractiTest
76. Do you know who’s using your app? “There are several ways testers can find out who is using an application and how. One approach that is becoming more commonplace is analyzing the application’s production logs.
“Logs are lists of lines of text output from an application in a given environment, such as a test server or production server. They can be helpful for testing purposes because they provide real feedback and insight into an application as it’s being used, as well as information that describes or can even help solve bugs.
“Each line of a log corresponds to some event or occurrence in the application. A log line could be informational (‘A user successfully logged in at ‘1:00 PM ES”), a warning (‘The current number of users is 90 percent of the total allowed concurrent users’), or an error (‘A valid user login failed unexpectedly’). Log entries can be output from the application itself (‘The number of logged-in users at a given time has reached a hard-coded limit’) or from the application’s environment or the system running the application (‘The server has run out of memory and cannot allow any more users to log in’). Most logging systems provide a timestamp for each log entry, often to the millisecond, and each log entry follows some standard format. This can provide useful insight into the question ‘Who’s using this application?'” – Josh Grant, Who’s Using Your App? Examine Logs for Testing Insight, StickyMinds; Twitter: @StickyMinds
77. Clear your browser cache. “When testing the application, it’s always better to clear the cookies/cache of the browser unless it needs to be there while testing.” – Mohd Azeem, Tips for Finding and Filing Issues When QA Testing, 3 Pillar Global; Twitter: @3PillarGlobal
78. If you’re running a beta test, avoid an open beta. “Open betas don’t work. You either get too many testers (think Netscape) in which case you can’t get good data from the testers, or too few reports from the existing testers.” – Joel Spolsky, Top Twelve Tips for Running a Beta Test, Joel on Software; Twitter: @spolsky
79. Use dedicated testers. “As with any type of software, bugs and defects can result in frustrated users who may choose to stop using the software. Complicating matters is the fact that collaborative research frequently results in users that are geographically distributed; yelling over a cubicle wall or going to the next office to discuss a bug may no longer be an option. In the worst case, subtle bugs in simulation or data processing components could ultimately lead to the recall of research results. No one wants that!
“Many mature corporate software development departments include dedicated test groups. These groups are typically involved in integration, performance, usability, and system-level testing. Given that developers should certainly test their own code at the functional/feature level and have ultimate responsibility for the quality of the code they create, having test engineers finding bugs that should have been caught at the development level is very expensive.” – Scott Henwood, 3 Tips to Help Your Team Build the Best Software for Scientific Research, CANARIE; Twitter: @CANARIE_Inc
80. Remember the Law of Demeter. “The Law of Demeter applies the principle of the least knowledge of software to promote loose coupling between units – which is always a design goal when developing software.
“The Law of Demeter can be stated as a series of rules:
81. Test functionality first, user experience second. “The core functionality is the main draw for any app and it has to be rock solid. People seek out apps to perform specific functions. Incomplete or inadequate functionality will result in abandonment, so make sure that the main functions are fully implemented and tested before you move on.” – Vu Pham, Top 10 Tips for Testing Mobile Apps, Developer.com; Twitter: @DeveloperCom
82. Exploratory testing has its place, but it also has some cons. “In exploratory testing, testers may interact with the application in whatever way they want and use the information the application provides to react, change course, and generally explore the application’s functionality without restraint. It may seem ad hoc to some, but in the hands of a skilled and experienced exploratory tester, this technique can prove powerful. Advocates argue that exploratory testing allows the full power of the human brain to be brought to bear on finding bugs and verifying functionality without preconceived restrictions.
“The drawback to exploratory testing is that testers risk wasting a great deal of time wandering around an application looking for things to test and trying to find bugs. The lack of preparation, structure, and guidance can lead to many unproductive hours and retesting the same functionality over and over. One can easily see that completely ad hoc testing is clearly not the best way to go about testing. Testers who learn about inputs, software environments, and the other things that can be varied during a test pass will be better equipped to explore their application with purpose and intent. This knowledge will help them test better and smarter and maximize their chances of uncovering serious design and implementation flaws.” – Exploratory Software Testing, Microsoft Developer Network; Twitter: @Microsoft
83. Use Black Box testing when valuable or necessary. “Black box testing techniques, also known as a type of behavioral testing, offer development teams the opportunity to examine software without necessitating a deep understanding of the code used to build it. The style of testing looks at the inputs and outputs of the software under test but does not examine the internal workings of the product. The code itself is treated as if it were hidden under a black box.
“By separating the user and developer perspectives, black box testing allows testers to more efficiently validate large bodies of code with a deep understanding of how it was built.” – Jeni Kyuchukova, 8 Black Box Testing Techniques to Boost QA Success Rates, MentorMate; Twitter: @MentorMate
84. Testing in production is important. “When you mention ‘testing in production’ you might recall the days when developers snuck releases past the QA team in hopes of keeping the application up to date, but in reality it only caused a buggy mess. And users were the ones who suffered. For this reason, most businesses avoid testing in production altogether because it’s too risky for the end user.
“But there are problems with not testing in production, too. Test environments are rarely built out to the same level as production environments, so they can never really achieve the scale that you’d see in ‘real-life.’ Plus, testing environments can easily get stale and out-of-date – and as a result you aren’t testing what you ought to be.” – Tim Hinds, Don’t Do It the Wrong Way: Tips for Testing in Production, Neotys; Twitter: @Neotys
85. A testing brain is invaluable in DevOps. “Testing maturity is a key differentiator for the success of DevOps. Even if organizations can automate their integrations, builds, and delivery processes but they still struggle to manage test orchestration and automation. Testing brains play a critical role to achieve this with their expertise in test design, test automation and test case development with DevOps. Irrespective of what DevOps processes, models and tools organizations use, testing is a vital part of the overall DevOps process — not only to ensure code changes work as expected and integrate well — but to ensure the requirement changes do break the functionality.” – How DevOps Transformed Software Testing, Cigniti; Twitter: @cigniti
86. Ask the right questions. “Ask the right questions. Don’t just ask for the sake of asking. Try to understand the context and dependencies, then ask the questions that will give you deeper insights, help you understand, and enable you to build the right test cases.” – Peter Spitzer, as quoted by Chelsea Frischknecht, Think Like Your Grandma: Testing Tips from Peter Spitzer, 2013 Test Engineer of the Year, Tricentis; Twitter: @Tricentis
87. Avoid test traps such as running out of test ideas. “This is by far the most common problem that a tester can run into while on a project. How many times have you been in a situation where you didn’t know what else to test and how? I call this phenomenon as ‘tester’s block syndrome’ [a condition, associated with testing as a profession, in which a tester may lose the ability to find new bugs and defects in the software that (s)he is testing]. If you’re curious, which you should be (if you are or aim to become a good tester), then you can read more about it in the article titled The Se7en Deadly Sins in ‘Software Testing’ that I wrote a while back.
“How to overcome this trap?
89. Use “good enough” testing as early as possible. “What’s the best load testing strategy—to invest in a realistic test or take a quick-and-dirty approach?
“Many testers aim for realism, but setting up a realistic simulation can take a lot of time and effort. This can significantly delay testing, leading to serious risks. As Kent Beck and Cynthia Andres observe in Extreme Programming Explained, catching problems early costs less than fixing them at the end of the development lifecycle.
“The other option is to use ‘good enough’ testing as early as possible. I would argue that in many cases, this approach produces better outcomes. We can spend 20 percent of our typical effort on the test configuration and still learn 80 percent of what we want to know—and we can find problems when they’re still cheap and easy to fix.” – Ragnar Lonn, When should I start load testing?, TechBeacon; Twitter: @TechBeaconCOM
90. Assign severity to defects. “Severity can be defined as how severe the defect is to the system and how badly it will affect the functionality. For example, an application crash on clicking a button is severe to the system. So its severity will be high. Whereas a spelling/grammatical error will not have much impact on the overall functionality. So its severity will be low.
“Levels:
“Although this varies from company to company, there are 4 levels of severity.
“Important concepts:
91. Leverage user experience elements to improve software testing. “Tests based on requirements still fail user expectations because requirements describe system specifications whereas user expectations are best represented through user-centric design artifacts. Exploratory testing is a technique that shifts focus from system-centric checking to user-centric testing. To be effective, exploratory tests have to rely on the user-centric artifacts that capture the user behavior.
“Exploratory testing as opposed to ad-hoc testing is a focused, well-defined and controlled testing approach that time-boxes test iterations and cycles using scenarios for reference. Exploratory testers rely on hunches, biases, conjectures, intuition, personal experience and heuristics while continuously learning from the system behavior. User experience (UX) design process tries to uncover similar aspects of user behavior that motivates users of the system that are the basis for user expectations.” – Venkat Moncompu, Leveraging user experience design elements to improve software testing, WestMonroe; Twitter: @WestMonroe
92. Screenshots, logs, and videos are your best proof-points. “Screenshots, logs, and video are a tester’s best proof-points.
“Unfortunately, server communication logs are not as easy to handle as client logs. They are usually added more for the developer’s convenience when debugging communications with server than for the tester’s benefit.
93. Don’t just test — get to the root cause of bugs and failures. “Do not ignore the test result. The final test result may be ‘pass’ or ‘fail’ but troubleshooting the root cause of ‘fail’ will lead you to the solution of the problem. Testers will be respected if they not only log the bugs but also provide solutions.” – Vijay Shinde, Top 20 practical software testing tips you should read before testing any application, Software Testing Help; Twitter: @vijayshinde
94. Watch for unexpected behavior. “It’s common sense to test an app for expected functionality and valid conditions, but it is also helpful to test for invalid conditions and unexpected behavior. For example, you’ll always want to test for potential points where software might fail or crash but you should also take a close look at how the software is performing when no observable bugs seem to be occurring. This can help you find issues you might otherwise overlook.” – Best Practical Software Testing Tips, SQA Solution; Twitter: @sqa_solution
95. Eliminate technical issues during development that can impact user experience. “During software development, you must complete rigorous testing to eliminate all technical issues. Nothing slows a customer down more than a technical issue. According to a Kissmetrics report, 25% of visitors leave a website within four seconds due to slow load time, and page abandonment increases as load time increases.
“Technical issues can destroy a business. So when developing software, be certain that all the bugs are worked out and operations run smoothly to ensure an optimal user experience. While working with one of our larger clients in the energy space, we found a number of technical issues in later stages of development. This created the need to revisit some earlier development stages to course correct. Luckily, our second reiteration was complete, the software was rid of bugs, and the UX experience was clean.” – Scott Stiner, Five User Experience Tips For Software Developers, Forbes; Twitter: @Forbes
96. Identify bottlenecks. “If you’re experiencing slow .NET application performance, the best thing you can do is identify the bottleneck by measuring the speed of your site with database profiling, tracing, and looking at your logs.” – Boris Dzhingarov, 4 Tips to Improve Your .NET Application Performance, TG Daily; Twitter: @tgdaily
97. Be diplomatic in bug reports. “Even if you are brimming with confidence about authenticity of the bug detected by you, avoid writing a bug report which would reflect as if you are trying to pass your verdict on the genuinity of the bug. In every probability this could initiate a controversy which would reflect your superiority complex as a tester. Your main aim should be to keep your bug report conclusive supporting your bug plus the sole motive must be to get the bug closed ultimately. Try to use diplomacy in bug report, instead of using authoritative statements in favor of your bug thereby making your bug report unpleasant, best way is to be suggestive. Such an approach shall always be taken in good spirit.” – Nine Tips for an Effective Bug Reporting, Software Testing Genius; Twitter: @CertnTesting
98. Speed up the development cycle with consistent feedback. “So this consistent state of change requires us to put continuous feedback at the core of our projects and project efforts. Being agile also means providing touch points for continuous feedback.
“Though it’s nothing new, Feedback is key. Continuously asking for feedback throughout the entire project requires a feedback culture where people are pushed to evaluate what they are doing on a daily basis.” – Thomas Peham, Why No One Talks About Agile Testing!, DZone; Twitter: @DZone
99. Perform repeated tests with different test environments, and then try to find results patterns. “Perform repeated tests with the different test environment.
“Try to find out the resulting pattern and then compare your results with those patterns.
“When you think that you have completed most of the test conditions and when you think you are tired somewhat then do some monkey testing.
“Use your previous test data pattern to analyze the current set of tests.” – How to find a bug in an application? Tips and Tricks, Software Testing Help; Twitter: @VijayShinde
100. Practice pattern recognition. “This trick is basically to enhance your alertness in finding the bug. For instance, when you have to compare to pieces of similar code and come up with small bugs which might go unnoticed, you will able to draw conclusions in no time.
“For a small piece, it won’t make much difference, but when it comes to a lot of information and lengthy code, it is very helpful.” – How to Improve Your Manual Testing Skills?, Testbytes; Twitter: @Testbytes
101. Keep on testing. “The most important thing is to keep on testing. This is only plausible if you have been keeping that ‘eye’ to test. This is another way to say to look at things from a different angle.” – Tips and Tricks for Mobile App Testing and Quality Assurance, Evolutionate; Twitter: @Cuelogic
Software testing is a creative yet challenging task. It does not solely revolve around QA personnel and testers, developers must always test their code before merging, branching, or pushing it to production. Good testing practices always depend on one’s skill and experience. To achieve bug-free codes, use an error monitoring solution, such as Retrace.
Also, try Stackify’s free code profiler, Prefix, to write better code on your workstation. Prefix works with .NET, Java, PHP, Node.js, Ruby, and Python.
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to [email protected]
