exploratory testingsingle-v2.php

When you are a new tester in a QA company (yeah, like me), you may encounter several challenges in the first few working days. You need to learn the company's rules, go through the onboarding process, and meet with colleagues. It's not easy, you know. However, as soon as you learn it, the most difficult is yet to come. You may have your first project — a huge CRM with thousands of dependencies, modules, and components that you need to test quickly, but qualitatively. It’s fine if it has accurate documentation or mockups, but if not — it's time to use exploratory testing. In few words, this is a way to test software without any strict plan or previously developed strategy. You use your intuition, experience, and knowledge. Software testing goes step-by-step. Looks like you're exploring new lands, or you're a curious traveler in a new place. First, you study the product you are working on; its logic, business goals, and user expectations. Then you begin to understand the dependencies of the modules in the system and user view regarding the functionality of the product. And finally, you put everything together and explore the entire system with its smallest features, etc. Well, this is how I met the exploratory tests in practice. I’m used to getting complete product documentation before testing any software. There are some documented items, and they should be fully checked. Any actions should be planned earlier. Now I understand that sometimes there is not enough documentation. So you need to examine the software yourself. And finally, it could bring great results. How The Process Goes In most cases, I use exploratory “test tours”, which James A. Whittaker described in his book about this testing type. When embarking on a new project, I imagine myself as a traveler who discovers new lands and has to study it in a short time. Thus, I have to go through “test trips” and check the software according to their specific criteria. There are basic “test tours” that I most often use when testing software. Tours of the Business District: I study the basic ideas of the software, its business goals, etc. All that reflect its value to the business; The Intellectual Tour: I study the logic of the product and its behavior in a different condition; The Supermodel Tour: I'm trying to understand what impression the product makes on users. After that, I’ll check its visual appearance. The Rained-Out Tour: I check the behavior of the product in an ...

The quality assurance process aims to make sure a software solution will operate correctly, without unexpected issues at the both development and release stages. A tester's main responsibility is to find even the smallest bugs which could negatively affect an application’s seamless work. In most cases, testers need to explore all the parts of an application: its functionality, interoperability, usability, visual appearance, etc. No wonder, sometimes the testing process is compared with the exploration of new lands. Both of them have similar roads: there is something unknown, and it’s the tester’s job to explore the lay of the land. That, in essence, is what Exploratory Testing is. Usually, it is done without any documentation, but with a clear and precise “Software cartography” which should include previous experience of the explorer and all the information about a product (its features, functionality, the business idea, etc). In this article, we’re going to look closer at this testing type to see its advantages and benefits in the process of quality assurance. Exploratory Testing: How it’s Done and Why it Matters Essentially, exploratory testing is a software testing approach which is executed without any previously developed documentation, test cases, or checklists. Therefore, a tester creates and runs tests based on his knowledge regarding the product. Overall experience and extensive technical background of QA engineers also play a big role, helping them execute tests more accurately. This testing type is convenient because a tester does not need to spend much time and energy creating test documentation. At the same time, the testing process is more intuitive and fast. The tester can determine at what stage the exploratory testing can be used to bring the greatest benefit, thereby mixing that with other testing types. This can be a solid step for a deeper understanding of the product. Thus, in the future, this will allow QAs to create more practical and useful tests. Finally, it could improve software not only from a technical but also from a business point. Exploratory testing includes many approaches. A tester can methodically reproduce real user behavior or perform a series of operations that a real user would never do. The goal is to just “explore” until you run into a bug, confusing UX, or a functionality error. Exploratory testing can also serve as a final check of software quality, helping QAs to determine potential weaknesses and failures ...

Skill Exploration requires inspiration. This is something not every tester is capable of understanding. Skill is not enough for accurate and valuable tests which makes it quite hard to deal with. Skill may be learned and acquired with hard work and tons of practice. Kill is something anybody may be proud with. Skill is hard earned and that is exactly what’s making the wall between it and inspiration. I have worked hard to master testing methodologies. I have spent sleepless nights learning and practicing. I’m ready and there can’t possibly anything else I may require. Not after all that effort – most testers believe. But that is a false belief. Inspiration is learnable and will also come in after some practice as long as the tester in you is passionate about testing and believes that taking this path is of his (and your) best decisions no matter what. What do I mean under inspiration? I have been working as a testing consultant for quite a while. Over that time I have managed to meet various different teams of testers from different companies and startups. Do you know that testers that are presenting most value to the company stand out from the start? And after you really get to meet them (a couple of beers on a Friday night usually does the trick) you are beginning to notice that all of them have something in share. They are all artists who are passionate about what they are doing rather than simply making a living out of what they’re doing. And you can’t make art follow scripts, right? Inspiration is a hunch, an itch you can only scratch after doing what your subconscious tells you to. Where does this head? If you are asking about their greatest testing achieving all of them will say they had to avoid or even neglect scripts to find that particular pesky critical bug that was a pain in everybody’s neck. Go ahead, check it on yourself, ask your team lead the same and listen to what he has to say about it. But there is the other interesting side of the coin as well. You can never simply forget tests scripts and burst hands in the app under test in a way you are finding appropriate. You may lose a lot of priceless time without any results whatsoever. Scripts were not created without a reason. So, as I learned a while ago in quality assurance consulting both qualities mentioned above: skill and inspiration are necessary to make a good tester. And both may only be acquired within time and after practice. That’s seemingly the only right way to become a ...

Exploratory testing is an activity when testers are motivated in finding any piece of new information that may have value to your product under test. Exploratory testing is a process of discovery, learning and investigation. Basically testers are configuring and observing the product under test with the goal of recognizing a possible issue, etc.

Regression testing is essential as it aims to find failures in the product after code changes, support of new environment or product release. By regression testing, you also ensure user confidence assessing if the product’s new version is better than the previous one. Although many companies still ignore its necessity and fail to run product tests after the release, this testing stage should not be overlooked. Below are 5 accepted ways to perform regression testing of your product. 1. Run all existing tests This means that all the tests written and run before should be rerun after the release. However, especially if they all are manual, testers are going to have a huge pile of work. Probably you don’t have that much time and resources to be wasted. The fact that it’s impossible to perform 100% overall testing of the product also adds to this. 2. Run tests with high risk In this method you should take into consideration the tests presenting the most value to your business users. Mostly such tests are those having to do with functionality and the most frequent activities of the business users. It’s not excessive to also note that with product changes the key processes may vary as well. Allot 30-40% of total regression time for tests with high risk depending on other things that need testing. 3. Testing high-defect features You can as well tests high defect areas of the product, often highly complex areas. Usually complex is the feature that includes sophisticated calculations or integrates with other applications. The functionalities having many past defects also come within this set. 4. Exploratory testing It is about building test case design along with its execution. In the course of building and execution of these tests you can discover problems within the application that will drive your following tests. 5. Automation testing You may cut the test number to be run manually by automating them. For quick execution, use automation tools which reduce time for test running greatly. However, be sure that you’ve put aside some time for developing automation scripts. Also note that in case of environment changes they will need respective updates. Use these 5 methods to run regression testing and ensure the high quality of your product.

While doing exploratory testing it’s often difficult to decide what to start with since the opportunities abound. In order to do it effectively we offer testers to concentrate on the three starting points to keep in mind all the way through. 3 Things to remember: Don’t follow the documentation. Exploratory testing is something you can perform without any specification and scripted test cases. However, if such handy guides are at hand, it’s always tempting to resort to their instructions. This is the mindset you have to avoid. While checking in with the documentation, you tend to rely on their standpoints and assume the tactic of confirming that everything works as expected. Instead your role now is the opposite, because you have to find the points where the system fails. It’s better to do cross-reference using documentation afterwards. Without resorting to it you think broader, you may even unintentionally discover some undocumented implicit requirements, errors and inconsistencies in documentation etc. Question rather than verify. When there’s a need to test some feature, we are naturally inclined to make prove that it works properly. This inclination is likely to restrict our interaction with this feature and place in focus only its positive responses. Our mission here should start with breaking the traditional frame of mind and try to contradict the expected rather than verify it. While testing, ask yourself negative questions such as “In which case it wouldn’t work?” or “In which case it couldn’t work?” to question the expected order of things and test it properly. Be Persistent. Since the temptation to believe that everything works right is strong, we often give up our hunt for bugs after several tests indicating none. To test more thoroughly, here are some additional ideas to dig up more bugs: Explore the type, length, formats and other properties of complex input data. Test the product’s performance on computers with different capacity, in an environment under different data production quantities etc. See if it’s possible for malicious users to use the given feature or its parts in non-provided ways. Test it against different browsers, platforms, databases etc. Check if the actions performed by several users conflict. Test how the feature reacts to the missing external components. Try out how different users handle the feature and what can be improved for better usability. Check if non-English users ...

"Exploratory Testing" has few definitions: This is "test execution, test design and simultaneous learning." During exploring the product, the tester executes and designs tests. (by James Bach) It is such kind of testing attitude which is based on phased testing of requirements, followed by the documentation and design of test cases, followed by the performing of those test cases. (by Cem Kaner) The main distinctions between Ad hoc and exploratory testing Ad hoc testing usually involves unskilled, unfocused and random testing, which may be done by anyone, no matter what is her/his practical experience or skill level. Ad hoc testing is still pretty ineffectual against main part of defective systems, so it still can't uncover significant number of defects. In comparison exploratory testing is much more systematic. Exploratory testing process stages Mental model creation of the proper system functioning Tests design that would disprove the above mental model Observing the outcomes and execution of these tests Outcomes evaluation against the mental model Process repeating until the mental model is disproved or proved Simple learning and exploration before creating any mental models of the system's proper behavior may be involved in alternatively exploratory testing process. Exploratory testing usually has uninterrupted time slot of 1-2 hours particularly devoted to the application testing. A serious benefit in having a short time slot is that it is pretty simple to schedule, easy to report and control. Exploratory testing provides a tight feedback loop between test execution and design. It also offers a tight feedback between testers and developers when the quality of the product is concerned. Some situations are in a great need of exploratory testing When choice of the next test case to be run is based on previous tests results, but cannot be done in advance. When providing quick feedback on a product's quality is an immediate need. When the requirements are undefined or even don’t exist. Or when the initial stages of development are lead to instability. When tester detects a defect, but there is a necessity to explore the scope, variations and size of that defect to offer the best feedback for the developers When a lot of errors cannot be detected with the help of the scripted testing process