RRUG #16 - Rzeszów Ruby User Group meeting recap

iRonin IT Team - Experts in software development
conference, events, iRonin, rails, ruby

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!

Author's Bio
iRonin IT Team

Experts in software development

We are a 100% remote team of software development experts, providing web & mobile application development and DevOps services for international clients.

Similar articles
Wroclove.rb 2022 - nasze wrażenia
Wroclove.rb 2022 - nasze wrażenia
Za nami 4-ta edycja Wroclove.rb, w której uczestniczymy jako iRonin! W tym roku po raz pierwszy na scenie jako prelegent wystąpił nasz CTO - Paweł Dąbrowski

Bulletproof your development with remote team augmentation

Read how
This page is best viewed in portrait mode
Our websites and web services use cookies. We use cookies and collected data to enhance your experience, provide additional communication channels, improve marketing materials and enhance our offer. IRONIN SP. Z O.O. SP. K. is committed to protecting all the data that we collect or process in any way, especially data of personal nature. By accepting these terms you agree to our usage of cookies and processing your data, according to our Privacy Policy, and you declare that your browser settings reflect your preferences. Read more You have the right to revoke this agreement at any time, based on the terms of our Privacy Policy. You can change cookies settings in your browser. If you do not agree with us using cookies and processing your data, please change your cookies settings in your web browser and reject these terms. You can find more information about cookies, your data privacy This site uses cookies. By continuing to browse the site, you are agreeing to our use of cookies. data processing, and your rights in our Privacy Policy.