Table of Contents |
Something that I really appreciate about my day-to-day work is how much it varies. Sure, there are some patterns to it, but the work I’m doing on any day frequently depends on where we are in the software development lifecycle.
One of the first things I do every day is a check-in with my team. This is a meeting where we talk about what we worked on the day before, what we’re planning to do that day, and then any roadblocks we’ve run into. This is a great way for me to know what everyone is doing and where I can help.
We have regular meetings to talk about the ideas in the backlog to help Jose, our Product Manager, understand the effort required for different ideas. Estimating how long it will take to build something can be challenging when the details are vague. But that’s okay; even rough estimates help him to weigh the development effort with the user value to plan the next iteration of ideas.
Early in an iteration, the developers start working on new code, and there are fewer things that demand my immediate attention, but that doesn’t mean I don’t have work to do. While there are no development tasks waiting for me to test them, it is the best time for me to look ahead and prepare. I write test cases based on the requirements and details from the developer. The test case specifies the inputs, conditions, procedures to test, and the expected results for a feature. This helps me structure the test plan that I’ll execute when the code is complete. I’ve started to write code to automate portions of my test. Because I’ve just started out, I’m not very fast at automation, but I’m getting better the more I practice. Learning automation is one of my favorite parts of the job!
In the middle of an iteration, development tasks start trickling into my queue as developers complete them. Testing something for the first time is called initial testing. It is likely I’ll come across some problems. Software is complex, and it doesn’t always work the first time. Depending on the problem, I might send a task back to the developer with notes on what to fix or report a new bug for them to fix in the future. Whatever the problem I find, it’s important to make sure we’re having the right conversations to address it appropriately.
As developers are wrapping up their development for the iteration, it’s time to get ready for delivery! Most of our initial testing passed. I’ll retest any tasks that were sent back to the developer; this is known as confirmation testing. It gives me a chance to make sure that everything was fixed and that it was fixed completely. It’s not unusual for miscommunication to occur around bugs, so it’s important to be thorough here. When features don’t work as expected, it is an opportunity to build relationships with the developers. I need to share what I’ve found in a non-judgmental way. Sometimes the issue is on my end with how I configured my test environment, but sometimes there is an issue with the code that the developer needs to fix it. Either way, assuming the best intentions and approaching the problem with an open mind will help us fix the problem more effectively.
Last but not least is regression testing. Regression testing is when I verify the major features or functionality of the product, not just what we developed in this iteration. This is important to make sure we didn’t accidentally break something. This is where my automation comes in handy because it reduces the amount of manual testing that I need to complete every iteration. Automation can’t catch everything, but it helps speed up the process.
This is a brief introduction to the different types of testing. In the next section, I’ll show you the details of how I set up a test plan.
Source: This tutorial was authored by DEVMOUNTAIN and Sophia Learning. Please see our Terms of Use.
