Software Quality Engineer in Agile
There are several popular software development methods used. The most commonly used recently is Agile with the Scrum methodology, Kanban and extreme programming in industrial technology. As a Software Quality Engineer in Ralali.com, I will share the story about the journey we take with this methodology for software testing:
1. Defined Test Case
If we use the Waterfall methodology, we define a test-case based on the FSD (Functional Specification Document) for a system that has been approved by the user and does not allow for major changes when the development is carried out. This is because testing can only start when the development is complete, a never-ending loop will happen because the development still continues by the developer, so it can not be delivered the testing phase.
While in Agile method, defining the test case is based on TRD (Technical Requirements Diagram) and is broken down into small parts that are possible to be done per sprint cycle so that the squad or development team is more flexible to adapt the changes as well as what happens in the software quality test, we can be defined test cases at the beginning based on TRD, sprint planning also discussions with the squad team but also allows to make changes to test scenarios and test cases if there are changes in the midst of development.
2. Testing
In Waterfall system, we do testing sequentially and after a whole development by the developer is complete we also need to define entry criteria and exit criteria for testing so we can do testing and also when testing is declared complete
If in Agile testing will be more flexible because we develop each part we can also only test the part of a feature, if it has become a single flow big feature we also can testing as a single scenario testing. We are also required to be more flexible with changes so that what we define at the beginning according to the TRD and then can change in the middle of development.
3. Feedback
Review or feedback is very necessary for Agile methodology so that we can improve the development process that is being carried out. We can discuss which features need intense supervision when going up to production. After the sprint cycle is done, every member gives suggestions in sprint retrospective based on the previous sprint, including: the good point from the previous sprint, the bad point and what should be improved.
In retrospective, we deliver the non-technical problems towards product improvement.
Overall, that’s all my sharing about my experience as a Software Quality engineers in Agile. If there is something you’d like to discuss, don’t hesitate to drop your comment in the column below. Thank you.
