We develop mainly under JEE and Java platforms and in C/C++ languages.
Would you like to know more? Contact us at
algomica@algomica.cz
HOW TO START TESTING?
This text is intended for those who are still unclear what testing is, how it is done, what its benefits are, and how it can be provided by an external company.
Gathering the documentation
When starting an test automation project (and any testing project in general), we need to gather the documentation first. This looks simple - everyone knows what the product (software) should do, right? However, it usually turns out soon that the software is being built under numerous assumptions, which are often not mentioned anywhere, because the creators of the software consider them too obvious to put them on paper. The effect is twofold: firstly, our testers get educated on these "obvious" assumptions, secondly, we ensure we put them on paper (because in the meantime they became obvious for the testers, too).
Becoming part of the development process
Meanwhile, we can start thinking of the testing strategy: How can we split the functionality into groups that can be tested separately? What are the dependencies among these parts? What can be automated and what can not? How can the product be made testable? How will we report errors? How will the fixes be tested? But - Hold on a second! Didn't we speak of testing strategy? Why do you start talking of reporting and fixes and testability? Yes, correct - this is the "storming phase" of the project, before any testing actually started. This is the time when the testing team need to step into what has been so far the territory of the developers only: the development process. Yet it is necessary to go through this phase: the testers need to set the expectations on what will they need from the developers and how the cooperation can be done.
Without the will for cooperation it will not work
Yes, testing is about co-operation, not about opposition to development. This is important: if you (a tester) find a bug (potentially a developer's mistake), the goal is to report and fix the bug, not to point on someone's mistakes. A tester can report a bug to the developer in a number of ways, from "Hey, it doesn't work again" to "Feature X causes the program to crash when setting A is on". Similarly, the developer can strike back by the terse "Fixed" or by "I have updated the DLL, please reload it, restart the application, and reload the data". As you can see, it's co-operation after all.
Establishing effective communication
Co-operation means good communication. How do a tester and a developer communicate about a bug when they are not sitting next to each other? What if there are hundreds of bugs? And what if there are several developers and several testers? Do you think emails are enough? Or are you tempted to create a shiny Excel sheet and send it around any time a bug is found or fixed? Or even make the Excel sheet shared on a network drive? You can certainly give it a try but if you want to save a few man-days of your people, you better have an issue-tracking (or also bug-tracking) system set up: create a project, register users, assign them roles, set up categories, severities, priorities and - you can start testing!
Test planning
Actually, it is not easy as that. As with any other project, you need a plan. You need to know the scope and time constraints, how many people will you need and, as with almost any other thing in life, what is the budget. This is leading us back to the strategy: now that the communication is set up, it remains to define how to split the functionality, how many tests we need, which of them can be automated, what will the phases be, when to re-test the fixes in the product etc. Things become more complex when the the product under test is a server application operating on a database which, on a production environment, contains a few gigabytes of precious historical data. In such cases, you have to think not only of the usual functional testing or perhaps usability and load testing, but also of stress testing, security testing, endurance, serviceability.
Testing at Algomica
Testing of software can be a complex task, which may require experience and suitable tools. At Algomica, we have both: We have successfully accomplished several testing projects, including challenging test automation projects. As for the tools, we offer bug tracking tools hosted on our servers for your disposal. Last but not least, we developed an in-house tool for testing of web applications.
Please feel free to contact us!