We’ve had another amazing RRUG meeting - the sixteenth one, and we’re sure there are many more to come. Once more, iRonin had the pleasure of sponsoring the event. This time, the presentations touched upon the often underestimated rake tasks, and the mistakes developers make that lead to very unhappy testers. Read on to learn more!
Rake tasks - a case study of neglect
If you attended the meeting, you know it was well worth it! The presentation by Mateusz was a compelling argument against undervaluing rake tasks, which is a common mistake during development. Mateusz brought our attention to the problems that result from this approach - problems which have a particular impact when the rake task in question is meant to be run on a production server to fix data affected by a bug or to conduct a non-trivial data migration.
Several crucial questions should be answered each time a rake task is required:
- How to inform the task executor about the current status of a rake task?
- What data does it affect and how to leave a trace of a data modification?
- How long will it run?
- What will happen if it’s run a second time?
- How does it affect the status of the production server?
These make it clear that a rake task is not a simple script to be run once and then forgotten. Each of the above questions was carefully considered, with particular attention paid to the results of building weak rake tasks and ways to avoid common pitfalls.
A tester’s ire is no laughing matter - it probably means there’s something wrong with your project
Testers are sometimes engaged in long-term, pitched battles with developers. This may sound like an exaggeration, but the sad truth is that developers often don’t follow practices that would help testers help them, and lead to a higher code quality. It’s also important to remember the client’s role in all this, which often comes down to providing good information.
It’s easy to negatively affect the development process. Sebstian, the author of the presentation, described how hardware issues, team miscommunication, a client’s approach and a lack of cooperation from users can make testing an uphill battle. He took a moment to focus on how various browser can cause issues, and why Android testing proves to be particularly difficult, due to the huge variety of devices and OS versions.
He also pointed to a number of problems with communication within teams that directly affect the time needed for certain tasks:
- the lack of communication when a developer doesn’t know how to replicate the occurrence of a bug,
- the lack of basic testing meant to prove that the code works after small changes have been introduced,
- the lack of reading comprehension when looking at problem descriptions.
He spoke about how common, simple mistakes lead to extra work and wasted resources, as issues that can be quickly fixed (often by making a change in a single place in the code!) are painstakingly described.
Sebastian also shared his thoughts on how difficult it is to reproduce bugs, when the details of their occurrence aren’t provided. This often has to do with the different approach the client and development team take to interacting with their app. There are bugs that can’t be reproduced because of differing browser states (cookies, plugins, blocked elements), or no information on the state of the device on which the bug was first encountered (for example, other installed apps can slow down everything else).
He ended his presentation with his views on the importance of good communication between developers and QA specialists, as well as the importance of asking clients to convey extremely accurate information on bugs, as this can have a direct effect on the speed with which these bugs can be fixed. Sebastian implored his audience to always check the code before handing it off for testing, and reminded them that testers’ job is to help deliver better software, and not to criticize developers’ work.
If these presentations and the topics covered during the previous meeting sound interesting, join us next time! We meet in Rzeszów and are always ready to invite newcomers.
Software development is a craft - and it requires expert knowledge.
Are your software development processes and practices optimal? We’d be happy to share our experience and help you improve them!
