for Your Solutions
Jump-start releases with bug-free production
based on metric-driven approach
We combine expertise and latest tech to deliver a top-notch product with improved ROI within time and budget.
Our Best QA Practices
Tech Stack We Love to Use
Open-source framework with browser automation and tools and libraries for functional tests.
Open-source tool for development automation of hybrid and native applications on iOS/ Android.
Benefits of QA with Mad Devs
Established in-house standards
Automation and agility of processes
Testing with current market conditions
Transparent and comprehensive reporting
Active customer involvement
QA Engineers - Are They Needed?
In some companies, the entire responsibility for the code lies on developers. It is believed that developers write the code, and they have to test it. Why then are QA engineers needed? And whether they are needed at all?We at Mad Devs aren't asking such questions. We adhere to the rule “people who wrote the code shall not test it”. We have QA engineers in our team, and we appreciate their job. While our developers cover everything in tests, they cannot find all the issues. The reason is simple: developers and QA engineers have different mindsets. They approach a product in different ways. Developers perceive the code as their creation, as a piece of art. It might prevent them from seeing faults.Let me give an example.Imagine that you have created something. It can be just anything, but in our case, we can take a blockchain app. If you have to test it, you check how it works, whether all the processes are performed smoothly, and similar. You aren't thinking of making it break down. Moreover, you don't want it to break down.While a quality assurance engineer does so. It is their job, and they were trained for it. The task of a QA engineer is to find or create conditions that may force your app to break down or work not as expected. They will try to find those combinations of conditions that will make the feature collapse. Moreover, QA engineers have all the needed tools to do so (here, I mean automated, not manual testing. While manual testing is required, we cannot deny that without automation, this work cannot be done at a proper level).
Test Documentation in Software Testing
Testing is an essential aspect of any product. Without testing, you cannot be sure of what you are giving the customer or the user. At any time, an unexpected problem may arise that is not obvious when looking at the code. But go a little bit beyond the intended use cases, and you can immediately see if there are problems with high load, big data, cyber-attacks, etc. And, of course, you don't want to discover these problems after the software has been launched, especially in feedback from real users. It is necessary to take testing and maintaining test documentation seriously to prevent this.So making a tester out of a customer or user is a terrible idea for various reasons. Some of them are obvious, and you don't have to be a prominent expert to see their seriousness. Some, on the contrary, may seem insignificant, but only in the process do you realize how important they are.
Why Do Software Bugs Occur?
So, software bugs: what are they and why do they occur? Most likely, you know the reply to the first question. We all deal with software in everyday life, and it happens that sometimes, a program doesn’t work as expected. In most cases, it is connected with a coding error called a bug.Why do the bugs appear though and why clients, even though they might hire an experienced team of developers, still have to pay for code with imperfections? Yep, it doesn’t always depend on a developer whether the product is going to function as expected. It depends on many factors, and you better learn more about them if you want to eliminate the possibility of bug occurrence.It happens sometimes that a client cannot specify what functionality the product shall have. It becomes especially problematic if the product is completely new and the developer cannot compare the requirements with those of similar products.When the requirements are changing constantly, it also causes bugs. For example, when one feature shall be removed, and it is linked to other software components, its removal will cause a bug if the issue is overlooked. Sometimes, fixing a bug in one component might result in a new bug in a different component. If the developer cannot anticipate such issues, the number of bugs might be increasing instead of dropping.