Meetup And Learn, Agile Myths And Test Integration Using Python
This week was Testival #54 hosted by ReversingLabs. This reports what I learned on that MeetUp. We demystified Agile Process myths and legends and learned how Python libraries could effectively be used in integration system testing.
Zeljko gave the general introduction for Testival meetup concept in front of 30+ participants. The meetup was in English because we had international participants. Testival speakers are entitled to Testival goodie bag and WebCamp conference ticket. Every participant introduced itself with a few words about themselves.
Then it was time to present our event host, ReversingLabs. Andrej explained what is their core business, finding malicious code in a significant number of files. Think when you are sending a file via Gmail. Gmail automatically checks that file for security threats. That is also a ReversingLabs business domain. If you are interested in solving testing problems for this domain, feel free to apply for their opened QA positions.
#1 Viktor Kvaternjak (ReversingLabs) — Rapid mocking of complex services
Viktor presented Python codebase for a couple integration tests with external systems. One feature of their product is to send out an email notification to the user that has information about threat alerts. Integration with email service is the very usual case for any application. The integration test for this feature could be done manually using application UI or could be automated using Python libraries. For sending an email, Victor is using the Django email package. Email service is mocked using Python smptd and asyncore libraries. First is an email server, the second one enables you to receive emails asynchronously. A tester needs to know the basics of the SMTP protocol, and everything else is taken care of by smptd library.
The second feature that Viktor tests using automation is SNMP — Simple Network Management Protocol. This is somewhat old technology, but very efficient. It is used to provide information about service status using trap, SNMP messages that contain various service information. From the presentation, I learned than min.io is an open-source Amazon S3 object storage alternative. Integration tests are using Python Flask for REST API implementation.
#2 Marko Bjelac: Behaviour-driven development: A recipe
As Marko has excellent experience in the Agile process life cycle, he shared his experience with us. In typical software development, we have a developer (dev), business analyst (BA) and QA (Quality Assistance). In Agile, those are firmly connected, and in Waterfall, they are separated. In Agile, we should slice user stories to small chunks, and every tale is described using Gherkin, given, when, then notifications. These are called feature files and represent static documentation, static because it could be executed by the machine. In Agile, all team communication is face to face, and work is done in pairs. At that point in the presentation, we started the discussion Agile vs. Waterfall. And this is the best part of Testival meetups!
We usually think that Waterfall is terrible, and Agile is good. The problem is that participants typically know what is Agile, but they lack knowledge of other project lifecycles. So they go with Agile because they heard of somebody else that this is the best project lifecycle (monkey issue). But Agile is not a silver bullet project life cycle, and waterfall is not the werewolf of project cycles.
The waterfall is a serial life cycle. When you have a little technical risk, low schedule risk, a stable project team, and no requirements risk, you should consider the waterfall lifecycle. And it is the wrong perception that testing comes at the end of the waterfall. You can still use BDD and TDD practices and start testing as soon as possible.
On the other spectrum is agile. You have a high schedule, project team, and requirements risks. You lower them in the one-week iteration. The main difference between the Agile and Waterfall lifecycle is the requirements set. In Agile it is in constant flux, wherein Waterfall is hardcoded at the beginning of the project. You are in contact with the customer (or its surrogate) on a daily basis.
This is why we use Waterfall in the Space-X project, and Agile is perfect for Facebook. And do not forget that in between Agile and Waterfall we have incremental and iterative life-cycle processes.
Zeljko gave the only five-minute talk, it was about Software Testing Antipatterns.
As my meetup photos are low quality, here is Zeljko’s event facebook album.
Originally published at https://blog.tentamen.eu on November 14, 2019.