Let’s leave out the comparisons. Explore how acceptance criteria and exploratory testing complement each other to enhance the software testing process. 

Acceptance criteria and exploratory testing are often compared in the QA community. The debate about which one is better is constant; just try googling it. 

On the other hand, there seems to be little discussion about how the two approaches shouldn’t be compared at all but rather used together. When we combine acceptance criteria and exploratory testing, we get the best of both (very different) worlds. 

In this article, we’ll explore the two testing types through definitions and practical use cases and then see how they can complement each other to improve our QA process.

Acceptance criteria are specific, measurable conditions that define when a project or task is considered complete and meets the set requirements. They ensure clarity, transparency, and alignment with client expectations. 

On the other hand, exploratory testing is a flexible and intuitive approach where testers spontaneously explore and test software without predefined scripts. They rely on their expertise and critical thinking to find defects and get an understanding of the software’s behavior.

My interest in the relationship between the two testing types was sparked by a piece of feedback I once got. The comment was that I didn’t engage in enough exploratory testing because the task in question had very detailed acceptance criteria. After discussing this with my team lead, we concluded that this is potentially a team-wide issue. We decided to pursue this theory further and find out what the exact scope was.

We organized a survey and asked our QA colleagues how often they engage in exploratory testing on tasks with acceptance criteria laid out in detail. Here’s what we learned: 

We were curious to know their opinions about the topic, so we also asked how detailed acceptance criteria and exploratory testing complement each other, whether there are any specific types of tasks where exploratory testing provides more value even if detailed acceptance criteria are in place, and what resources or support would make their exploratory testing more effective. 

The answers provided interesting insights, and we identified a couple of trends. What we learned helped us determine how exploratory testing and acceptance criteria team up in practice.

As we’ve learned, the combination of detailed acceptance criteria and exploratory testing is not just effective but also offers several different perspectives, providing an all-inclusive testing approach. 

Combining the two can enhance the quality of the product and ensure the success of our projects upon delivery.

There are specific scenarios where exploratory test sessions become not just valuable but essential in the process of testing software products. For example, if we are testing very complex features, dealing with frequently changing criteria, testing across different environments, handling different user interfaces, or facing critical bugs in the first round of testing, combining these approaches is a powerful tool for a well-rounded and complete software testing process.

With their diverse resources and support mechanisms, using exploratory testing on top of acceptance criteria can be further improved with the following:

These elements collectively contribute to a more effective and insightful exploratory testing process with acceptance criteria at its baseline.

Using this combined approach, we can create an environment that combines the strengths of scripted testing and unstructured exploration. With it, we are:

By carving in additional time for exploratory testing sessions, implementing a prioritization system, and conducting retrospectives at the end of every testing phase, we also add flexibility to our testing process. When we allow ourselves to be more adaptable, we can respond to each project’s unique demands, ultimately leading to more effective and customized testing results.

If you want to elevate your testing process, strengthening the communication channels within the project team and enhancing the skills and expertise of your testing team should be the first step. 

By providing opportunities for the exchange of experiences, the learnings of one team member benefit the entire team. When other people find themselves in a similar situation, they will have a better idea of what to do and how to do it. 

To create the environment for these types of discussions, you can randomly pair team members and schedule a weekly session for them. That way, everyone will be able to see what others are working on, what testing techniques they are using, and what new knowledge they have acquired. They will also have the opportunity to learn something new by testing a piece of software they never had. 

Enhancing the skills and expertise of our testing team contributes directly to the effectiveness of your testing processes.

In addition to the above, it is essential to promote continuous learning within a team. A skilled tester who is always working on upgrading their knowledge is a vital element for a strong testing strategy. To motivate testers to work on continuous skill improvement, you can: 

With a documentation repository, you can always point your team members to it to learn something new. When they are unburdened by time constraints, the learning can be more relaxing. A repository is also a place where all team members can share their experiences with certain tools, processes, ways of working, and other testing components at any time that suits them. 

Further, investing in external training opportunities, whether different conferences or certificates, is a great way for team members to gain valuable knowledge that can improve the testing process on the projects they are working on.

People often go straight into comparing acceptance criteria and exploratory testing, failing to see their combined potential. As we’ve learned from our internal survey, our testers thankfully don’t feel constrained by acceptance criteria and often use both approaches. 

Combining the structure provided by acceptance criteria and the flexibility of exploratory testing makes the testing process more robust. When we add opportunities for team collaboration and professional improvement to the mix, we’ve laid the foundation of a strong testing process across projects. 

By applying this holistic approach to software testing, we get closer to a goal the testers, their company, and their clients share – better digital products with no bugs in sight.

In the world of software testing, there seems to be a constant debate about what is more effective – do you follow strict processes or allow room for improvisation?

Sooner or later, all QA engineers will find themselves at a crossroads. Is it better to structure your testing activities into a process or just go with the flow? The answer is not that straightforward, as both approaches include certain benefits. 

When you’re working on a large and complex project, missing even one test can have significant consequences. Adhering to a process ensures all tests are performed in a consistent manner, and all potential defects are covered. 

On the other hand, some will argue that adapting to changing circumstances is crucial for effective testing. When testers foster creativity and allow themselves to think outside the box, they can potentially discover more defects.

So which way is the right one? We’ll explore the pros and cons of both in more detail, so you can consider all the aspects when deciding what path to follow.

A process is defined as a system of rules, procedures, and standards that must be adhered to precisely and consistently in order to accomplish a particular purpose. 

From the QA perspective, it’s about being aware of the rules and specifications established by the framework and verifying that the development team complies with them. This includes tracking and evaluating development, identifying areas for growth, and providing comments to support the members in achieving their goals. 

By adhering to the established procedures, the QA team can help maintain quality standards and guarantee that the project is delivered on time and within budget.

The term improvisation describes our capacity to change with the times and react in a flexible and original way. 

Improvisation is crucial for dealing with unforeseen problems and changes that may occur during the development process. A QA team’s capacity for improvisation depends on their ability to change course mid-project and modify their strategy as necessary. 

This is evident in the way a team responds to adjustments in the project parameters. Maybe they are looking for possibilities to optimize procedures or come up with original solutions to issues that arise. By allowing themselves to improvise, a QA team can ensure that the project remains on track and achieves its objectives even in the face of unforeseen difficulties.

It’s important to realize that the choice between following strict processes and improvisation is not necessarily exclusive. You absolutely can combine both in your work to create a unique process that yields the best results. 

The best way of going about that is to allow space for improvisation but approach it with care. In other words, to formalize it.

For instance, if the development team improvises a solution to a certain issue, the QA team can assist by documenting what they’ve done and thus create a repeatable process that can be used going forward. 

One way of accomplishing this is writing test cases based on the improvised solution. It’s a way of guaranteeing that the solution is completely tested and potential problems are found and fixed. 

As a supplementary measure, the QA team might also want to conduct exploratory testing to find any unexpected behaviors that may have developed as a result of the improvisation.

Another method that helps formalize improvisation is organizing testing sessions with the development team. When the improvised actions are discussed and noted, the process can be well-documented and repeatable in the future.

By taking the necessary steps when allowing for improvisation, the QA team contributes to making the development process successful, efficient, and repeatable. When testers and developers work together from the earliest possible stages of the process, even the most improvisation-dependent projects can be given some structure so that product quality remains a top priority.

The balance between following a set of processes and improvisation in software testing is a complex one, and there is no one-size-fits-all solution. Both approaches have their pros and cons, and the most effective strategy may be to combine them both. 

Ultimately, choosing your approach will depend on the specific goals of the project at hand. It is important to consider all aspects and implications and make a decision that aligns with the project’s needs.

Finding your testing path on a specific project may be difficult, but it gets easier when you focus on the final destination — assuring that the end product is of great quality and completely defect-free.

Wanting to formalize my knowledge of software testing and establish a baseline understanding of the field, I decided to take the ISTQB Foundation Level exam.

As a software tester, I have always been interested in taking this well-known exam, but I never seemed to have enough time to really focus and study for it. However, I also knew that obtaining an ISTQB certification would be beneficial for my career, as it is widely recognized in the industry, and taking it demonstrates a commitment to professional development. 

Recently, I decided to finally take the plunge and give my best to pass the ISTQB Foundation Level exam, so I wanted to share my experiences in more detail. If you’re interested in taking this exam, whether you’re an experienced software tester or just starting a career in QA, this article will help you know what to expect.

First of all, a bit of background on ISTQB and the Foundation Level exam. The International Software Testing Qualifications Board (ISTQB) is a non-profit organization that provides a standardized framework for software testing certification. The Foundation Level exam is the entry-level exam in the ISTQB certification scheme and covers the fundamental concepts of software testing. This includes topics such as testing fundamentals, testing throughout the software life cycle, static testing, test design techniques, and tool support for testing.

To prepare for the exam, I used a combination of self-study and two Udemy courses. Another option that I explored, but ended up not pursuing, is preparing by taking a study course provided by a local training provider.

My self-study involved reading through the official ISTQB syllabus and studying the various topics covered in the exam. I found the syllabus to be comprehensive and well-organized, with clear learning objectives for each topic. 

For the ISTQB Foundation Level exam, in particular, self-study was a crucial part of exam preparation for me. The syllabus gives a thorough overview of the subjects examined and lists the learning goals for each subject, and that helped me plan my studying time. Basically, I planned my self-study according to the syllabus to make sure I didn’t miss anything. I would say it took me about one and a half months of periodical study to go through the syllabus. 

In addition to the ISTQB syllabus, I also made use of online resources such as practice exams and study guides to supplement my understanding of the material.

This can include studying from study materials, going through the course outline, and taking mock tests. Track your progress as you go along with your self-study to find out where you might need more time to think or revise.

I received significant support and direction from the Udemy courses I took as I studied for the ISTQB Foundation Level exam. I took one that covered the entire syllabus and another that was solely an example of the foundation exam. 

The course, which was presented by an expert software tester, provided insightful information and practical examples that made the content easier for me to comprehend. I discovered that self-study, along with the Udemy courses, was a really efficient approach to preparing for the exam. It took me about 30 hours to complete the courses.

Overall, the courses complimented my self-study and helped me to solidify my understanding of the material covered in the exam.

In addition to self-study and Udemy courses, attending a study course offered by a regional training provider is another option for getting ready for the ISTQB Foundation Level exam. While I did not personally take one, I did some research and discovered that there are such courses available in Croatia, where I live.

The three-day training normally covers the same topics as the ISTQB syllabus. Participants have the chance to learn from a seasoned software tester who can offer insightful commentary and practical examples to help put the lessons being taught into perspective.

You can register for the course in Croatia by sending an email to the regional training provider, who will then give you the course’s upcoming date. The course provider will immediately register you to take the ISTQB Foundation Level exam once you have finished the course.

However, it’s still possible to fully prepare for the exam on your own with a combination of self-study and online resources.

The exam itself is taken online and consists of 40 multiple-choice questions that have to be completed within 60 minutes. If English is not your first language, you get an additional 15 minutes. 

The questions covered a wide range of topics and required a thorough understanding of the material. I found the exam to be challenging but manageable, as I was well prepared.

Overall, I am happy to say that I was successful in passing the ISTQB Foundation Level exam. I found the studying process and taking the exam to be a rewarding experience, as it allowed me to solidify my knowledge of software testing and gave me a sense of accomplishment. I felt that the exam was a good representation of the material covered in the syllabus and required a deep understanding of the concepts, rather than just memorization. 

I would recommend the ISTQB Foundation Level exam to anyone looking to gain a foundational understanding of software testing or to enhance their career prospects in the field. If you feel you already possess a fundamental understanding, taking this exam may help you in getting rid of imposter syndrome.

Now that a few months have passed since getting certified, I can see the progress I’ve made in my work. I’ve been able to implement some of the things I learned on the projects I’m working on, and I feel more confident and able to tackle tasks that I may have struggled with before. 

Overall, I would say that the exam has helped me improve my skills and become a more valuable asset to my team – and other exam-takers seem to agree. This was a great experience for me and I am already working on becoming a certified ISTQB agile tester. I would highly recommend the ISTQB Foundation Level exam to anyone looking to get started in software testing or to advance their career in the field.

If you don’t plan ahead and implement a thorough process, QA can often become an afterthought, leading you to a release full of bugs, client complaints, and spending more time on the project than necessary. 

The importance of quality assurance is something everyone involved in the project needs to be aware of, both stakeholders and the project team. No product development process is complete without QA – it’s a crucial step that allows you to launch your product with full confidence, knowing it meets the required standards and customer expectations.

To avoid problems later on, you should aim to integrate quality assurance into your product development plan from day one. However, setting up a QA testing process for the first time can seem overwhelming, and you risk falling down a rabbit hole of unknowns and unanticipated complications. 

Whether you’re new to creating a QA process or you’re looking to improve an existing one, these suggestions will help you get started.

Since there is no universal formula that will work in every situation, one of the biggest challenges of setting up an effective QA process is designing the process itself. You need to think about the overall environment and take many factors into account:

Understanding these aspects can help you work around any constraints and make the most out of your team’s capabilities. It will allow you to align your process with the project’s needs and requirements and effectively prioritize your QA efforts.

For example, I recently worked on a project where I was able to improve the QA process just by thoroughly reviewing the task description and flow. I produced a document specifying the exact responsibilities of each team member working on the project. We discussed my propositions with the development team and the project manager, and we all agreed on the tasks required for each role and the bug-reporting procedure. 

Thanks to the adjustments we made, the QA team received clearly specified tasks, and the developers received thorough and precise bug reports. Everyone participating in the project was pleased with the clearer and more efficient workflow.

Anyone in QA can tell you that the majority of serious problems revealed close to the project’s delivery date arise due to poorly defined requirements and false assumptions. Stakeholders assess and approve requirements in the early planning stages of a project, and your team should have a procedure for establishing and disseminating acceptance criteria in place. This should be a regular part of the development process.

To ensure that everyone is aligned around the expected results, the development team also has to know exactly what “done” means. The whole team has to be on the same page about their definition of ready and definition of done.

The success of software testing is ensured by setting up a proper test environment. Any errors in this part of the process could result in additional expenses and delay. 

When setting up the testing environment, you should base it on the requirements for the client’s product, and it has to be the same on the server side and the client side. If you don’t test in a setting that is a perfect replica of the production environment, you will get erroneous results. 

Another way to ensure your product will work as expected with real users is to create a testing and staging environment. That way, you can feel more confident that each component performs as planned.

Most QA teams now work in an iterative fashion together with developers. As soon as a functionality is developed, it’s delivered to the quality assurance team. 

However, especially effective QA teams adopt a proactive instead of a reactive strategy. They monitor the development process and identify quality problems before they reach the production stage rather than dealing with them when the development is complete. Developers and QA specialists work together as part of a project team and should therefore be in charge of delivering certain KPIs.

QA automation testing is a long-term investment in productivity. Setting up a framework for long-term projects can take quite some time, even for an experienced QA automation tester, but it will save dozens of hours of work. 

The initial step in automated testing is feasibility analysis. The team first determines whether a test should be automated at all. This is followed by the choice of tools; QA engineers select tools and frameworks for the process once they’ve defined the types of tests they want to automate. This decision depends on the types of tests being automated, such as usability testing, cross-browser testing, and end-to-end testing. Each serves a different purpose, from ensuring smooth user interactions to verifying functionality across multiple environments.

For instance, if QA teams aim to automate end-to-end testing, they examine top end-to-end testing tools to determine which best fits their project needs. The right choice helps streamline workflows and improve overall test coverage.

Finally, there have to be metrics to gauge the level of automation for each process (the amount of caught faults, fixed bugs, escaped defects, etc.).

We’ve gone through a number of reasons why it’s important to work on a thorough and systematic quality assurance procedure. Saving clients’ time and money through early identification and correction of defects is just the basic one.

The QA testing process is not just QA’s business. Developers and project managers committed to the project’s success will recognize the value of testing products both before and after release. For maximum results, the entire project team should understand the process and feel confident participating in it. Better teamwork and communication ultimately improve project results. 

A well-defined procedure can ensure that the product satisfies client expectations and generates repeat business, and we advise including QA on every project. Once created, your process can be used as a template for future initiatives and contribute to creating a culture of quality assurance inside the company.

When you are a QA set out to test an app made in Flutter, you’ll quickly realize there aren’t many sources of information available. Googling will get you scarce tips and tricks or well-established testing methods.

Working in Quality Assurance at a company with a very active Flutter team, I’ve done my share of testing and gained some valuable insights.

Let’s start with the basics. Flutter is an open-source user interface software development kit created by Google. It is used to build cross-platform solutions for Android, iOS, Linux, macOS, Windows, and the web from a single codebase. Flutter’s programming language is Dart, and the apps often make use of its more advanced features.

Flutter is commonly used for mobile app development. Both Android and iOS apps can share the same codebase, eliminating the need for separate native development. Couldn’t we do the same with React Native, you’re asking? Yes, but RN uses device-specific interface components, and many of them are platform-specific, which results in a significantly larger codebase than needed.

If you compare stars on GitHub, Flutter has a larger community than React Native, a case in point.

The very foundation of Flutter is that almost everything in the program is a widget. There are no distinct controllers, views, or layouts like in other frameworks. The widget is a unifying building block that covers almost every aspect of Flutter development. It can be anything from a single button to a full pop-up panel.

Flutter widgets are created with a modern framework based on React. They make up the entire UI and indicate how their present configuration and status should appear in the display. 

The composition method is superior to inheritance. The composition-based technique is used when widgets are made up of smaller widgets. You can use the Flutter API to mix numerous widgets to get the exact behavior you want.

The widget tree concept is essentially a ranked widget implementation that represents user interface components. These widgets can be stateless or stateful, and the distinction is determined by the state of the widget. It’s a handy tool for managing app states.

When it comes to web and desktop apps, compiling the Flutter source code into a native Windows, macOS, or Linux desktop program is possible with desktop support. Flutter’s desktop support extends to plugins as well, allowing you to install existing plugins for Windows, macOS, and Linux. However, to be considered fully compatible, a Flutter app mustn’t include any platform-specific implementations. 

Flutter provides a more customized UI than native platforms. However, it’s also slower, which means that screen jerks and terrible animations are possible. If the app needs to communicate with the device frequently, it’s probably not an ideal fit for Flutter. Flutter is best used for producing apps with a visually pleasing interface.

I’ve had experience with several Flutter apps, most of them fit in the same category, and the expectations were similar. Not much communication with the device was required, the app needed to be very UI-friendly and the overall testing experience was very pleasant.

However, once I tested a Flutter app that communicated with the device and biometrics a lot, and that one was a challenge to test because of some of Flutter’s limitations. You should keep this in mind when creating a testing plan for a Flutter app, it often depends on the app’s category. 

Flutter is focused on assisting developers in making their apps more accessible. It contains first-class framework support for accessibility on top of what the underlying operating system provides. This includes things like fonts in bold, readers for screens, and adequate contrast. I would also advocate for automated accessibility scanners in addition to testing for these specific topics.

Widget book is an open-source tool for creating Flutter UI widgets and pages. It can be very useful for QA because developers can implement it within the app. We can see every widget in the app, interact with it separately, and see any of the possible widget states. With the widget book, you do not have to verify everything in the design file, because the developer gave you a “shortcut”.

While testing Flutter apps I noticed some bugs appeared more often than others. Maybe we could have talked about Flutter-specific problems some time ago, but today it’s hard to pinpoint the exact issues that come in the package. What we can do is point out the places where Flutter is most likely to break so you can pay more attention to them while testing.

These places are all related to the app’s communication with the device. Keep an eye out for the following: 

The bug that personally bugged me the most was when the app often got stuck on the splash screen, which prevented me from testing it at all. It sometimes helped to reinstall the app or check the app’s permissions. I would definitely advise testing the UI on devices with punch hole displays because widgets can have some issues there, e.g. look broken, have a broken layout, or not be displayed at all.

Further, my impression is that Android does have a slightly higher number of issues with Flutter apps, which is one of the reasons you should test the app on both platforms. When it comes to mobile OS, Flutter apps are supported on Android API 19 & above and iOS 9 & above.

Automating the testing process on Flutter apps is possible, just like with any other mobile app. 

Testing Flutter apps, you basically learn from experience since there are hardly any resources available at the moment. What I’ve personally learned is that at the core, it isn’t that different from testing native apps. Some bugs do tend to pop up more than others, and I tried to shed some light on these. 

Hopefully, sources of information tackling QA issues, in particular, will follow the trend.  

It’s almost amusing how so many developers see software testers as troublemakers. Of course, who could blame them – nobody likes hearing about their child’s flaws, and pointing out flaws is quite literally our job.

Like artists and critics, developers and testers are said to be in a perpetual state of conflict. They can’t live without one another, but they also can’t seem to get along.

Both sides share a common goal of creating the best possible digital product despite the ongoing animosity. That is why it is vital to alleviate that sensation and work on improving the relationship to everyone’s benefit. I have a couple of ideas for achieving a healthy, trustworthy collaboration between testers and developers, but first, we need to get some things out of the way.

Testers have a reputation for being rebellious. It’s a character feature that helps them be good at their job because they don’t accept things at face value and don’t mind saying something is off when they see it.

When asked what we like about testing, a typical response is that we like to “break” software. It sounds like we enjoy crushing up a developer’s hard work and tossing it back in their face. However, it’s code. It exists precisely as it is. Sometimes there are issues, and sometimes we stumble upon them.

In most companies, developers and testers are two separate teams with their own leaders, supervisors, pay structures, and probably office locations. These two teams need to work together to produce quality software, though. If they come closer and create a common culture with shared goals, it can do wonders for the project.

Before testers start their work, both teams need to get together and ensure they’re on the same page. It’s important to discuss the code changes – what was changed, with what goal, and what the expectations are. Once a project is underway, teams should regularly check in to assess how development progresses and what testing has revealed. Working together regularly makes it easier to recognize the expertise and importance of another individual.

When dealing with an issue, it’s essential to change your perspective from “You have a bug” to “We have a bug.” That way, we are communicating as a team with the same goal.

In my opinion, the finest remedies to the reputed animosity between testers and developers are collaboration and teamwork. Building a strong, trusting, friendly relationship creates a safe environment where no questions are out of place, concerns are discussed freely, and both sides perform better.

There are some practical steps you can take to achieve that, and as a result, the whole process is smoother and more efficient.

Everyone in the team should be aware of what the testing plan is. It may seem obvious, but the first piece of crucial information to share is what version is to be tested (the best pick is usually the latest one).

The test documentation should include a list of features to be tested and test cases. Clearly stating the features that will undergo testing gives the project team a heads-up if some issues pop up during the process. Ask the developers to provide their opinion on the best way to test a feature they are working on and whether it’s related to another piece of code or a different product. Should some instructions or guidelines be added?

The developers hold a lot of answers, and you can get a lot of information simply by asking.

We set a good foundation for a comfortable communication environment when we share our testing plan. This way, developers will be more open to sharing their development process, be more descriptive in the project documentation, and make your job easier.

The old Croatian proverb sums it up – keep your issue-reporting manner positive; your goal is not to offend.

When we find bugs and issues with the software, it’s essential to communicate that right. Don’t question the developer’s skills or knowledge. The best way to go about it is to give as much information about the issue as possible. Think about it as returning a favor. They gave us all the information from their end so we could test better. Now we need to do the same, so they can have an easier time repairing what’s broken.

Always encourage a work environment where both parties communicate on time, provide constructive feedback, and support proactivity. And do it politely.

This article is written from a tester’s perspective and mainly focuses on what testers can do to have a better relationship with engineering. However, both sides are responsible for guaranteeing that the final product is at its finest.

Developers need to strive to produce the best possible code even before it goes into QA’s hands. Quality Assurance is a safety net, a just-in-case measure, not a detection mechanism for poorly written code. Both sides should be able to lean on one another but not take advantage of their position.

Developers and testers don’t have to have a harsh or unfriendly relationship. Understandably, developers can be emotionally invested in their hard work, and in case it doesn’t perform well, QA is the bearer of bad news.

Approaching a task with a new perspective and dismantling certain long-standing divisions between responsibilities can make all the difference. Hopefully, these tips will help you overcome some of the legacy difficulties. When you bridge the gap between two teams, all sorts of magic can happen.