Sometimes certain time-consuming activities software developers add to a project raise what seems like a fair question: “Do we really need to do all this?” The project budget is being burned up rapidly, and the release is still far off. Maybe these added activities are nothing more than trying to be trendy? Maybe you can cut them out and thus reduce both the budget and development time? Let’s consider these questions and whether those “extras” are really needed.
1) Clickable UI prototype
Where does software development start? First, you come up with an idea, then you describe it in the form of requirements, then the UI designer creates a visual representation of your future product. That would seem to be a sufficient set of input data for the development team. And now you may be offered another step: making a clickable UI prototype that will simulate the work of your product but not yet be real software. You might ask: Why waste time and money on this? UI designers are not the cheapest specialists.
The answer is that with interactive images, you can test the completeness of the requirements, the health of the workflow, and the ease of navigating between screens. At the same time, problems found can be easily and quickly fixed, unlike fixes in real code.
In summary, if you are offered only the design of the main pages without a clickable prototype, ask the vendor how the company will guarantee the completeness of the requirements and the usability of the future product.
2) Unit tests
You have started the development phase, but it’s not going as fast as you would like. You analyze the activities of developers and notice that part of their time is spent on creating unit tests. That is, the developers write additional code that tests the main code. But you have QA specialists in your team, so why invest in unit tests as well?
Automated tests have a great advantage: they are always run in an isolated environment and thus eliminate the human factor. This means we can expect a certain result for certain input parameters. If the method under test produces different results with the same input data, then a mistake has been made in the design of the system.
Unit tests help developers write code. After all, in addition to the main activity of programming, the developer must also check the correctness of the code. This can be done either through manual debugging or through automated tests. Most of the time, these two methods complement each other. Moreover, unit tests are run with each build and thus guarantee the correctness of the changes and, accordingly, the stability of the developed application.
So, if you are offered the opportunity to exclude unit tests from the scope of the project, ask how the vendor intends to ensure the correctness of the written code and the stability of software development.
3) Cross-code review
So, you’ve agreed on the need for unit tests and suddenly found that developers are also spending time on cross-code reviews; i.e., they visually check the changes made by their colleagues. Why waste time on this? After all, we have unit tests to guarantee stability and automatic code analysis tools to ensure compliance with modern approaches.
During a cross code review, two important things happen:
- Team members become familiar with the code created by their colleagues, which means they can easily maintain the entire system.
- Visual control allows you to unify the implementation of architectural approaches, the risk of spaghetti code is reduced. All of this leads to improved maintainability, which in turn will help you make changes faster and therefore more cheaply.
Thus, if your service provider is not going to do cross code review, just ask how they can ensure that the entire team follows the established architectural design, and how quickly any developer can fix a problem in any part of the system.
4) Independent QA
Well, everything is right on your project: there are requirements, a design, a clickable prototype, developers write unit tests and do cross-code reviews. Why pay for a separate QA team, then? After all, you hired professionals who do their job well; why check after them?
Probably the most useful thing about manual testing is chaotic testing. You can try to predict the behavior of a real person and even program some of their movements, but completely covering the application with automated tests is quite expensive. After all, the tests will also have to be changed with an actively developing system. Unit tests are good for checking the correctness of algorithms, or you can cover repetitive problems with a more complex integration test. But in general, manual testing helps simulate the work of a real user and not only reveals obvious errors in algorithms or workflow, but also helps improve usability.
Thus, if your vendor convinces you that their programmers are professionals and a separate QA team is not needed, ask if they are ready to guarantee a certain quality of software when it is released.
5) Test cases
Okay, we already have both unit tests and manual testing; so now, why do we need to spend time maintaining test documentation, in particular test cases? The main purpose of test cases is to prepare test data and describe the steps by which a certain result is expected. That is, a QA specialist will not need to look for input parameters every time and think whether the result is correct — all of this is reflected in the documentation. Moreover, a new member of the team can quickly get acquainted with the project, because test cases are a kind of how-to.
As your product evolves, making changes becomes more and more risky. Having test cases helps reduce problems. However, there is a downside: with the increase in the functionality of the system, the number of tests also grows, which means that executing those tests takes more and more time. To reduce complexity and streamline the development process, test cases are grouped by both the tested component and the level of coverage, namely:
- Smoke tests — run each time a build is delivered to the QA team, to confirm that the core functionality is working and the build is basically testable.
- Minimal Acceptance Tests (MAT) — usually this subset includes frequent cases and tests with a positive scenario. That is, we test the most-used functionality by doing the “right” things.
- Acceptance Tests (AT) — This subset typically includes rare cases and negative scenario tests. Thus, we are testing how the system will behave if the user performs “wrong” actions. For example, how the system reacts when the user tries to save incorrect data. Acceptance testing determines how ready a build is for release.
When the QA team executes tests at a certain level of coverage, they will also run tests at a lower level. So, during MAT-testing, Smoke tests are also checked, and at the AT stage, all tests of the system are executed.
In summary, if your service provider does not maintain test documentation, ask how they can ensure that the software has been fully tested before release.
Conclusion
If you are developing a product in which quality and speed of support are important, then the above practices don’t burn the budget in vain; in fact, they can actually help save it. The cost of finding a bug late in some systems may be extremely high, not to mention the consequences of correcting it, in speed and quality.
DigitalMara has over 10 years of experience in developing complex and high-quality systems. Our team is guided not only by past experience, but also by mature processes within the company. Have you already started development with another vendor, but find yourself unhappy with its progress? Come to us; we will give you a free consultation on how to quickly release your product to the market. We can provide you with a full-fledged development service, as well as separate services for UI / UX design, an architectural audit, and independent testing of your software system.
