Test is something that is present in our daily lives of everyone that works with technologies, but, for some devs, when they listen the frase: "The QA is testing", they know that probably, they will receive a message at 5pm on Friday to fix a bug that he couldn't found. I've write this article to help you avoid it, or at lest, reduce it.
Summary
Why we need to test?
We already know that is important to test, but, why this is so important during the software development? Why my team needs a person to do it(QA, tester)? To understand it, we need to go back on the story.
After the industrial revolution , to be precise at 1914, our dear friend Henry Ford created the famous Fordism.
Fordism, a specific stage of economic development in the 20th century. Fordism is a term widely used to describe the system of mass production that was pioneered in the early 20th century by the Ford Motor Company.
The companies started to build a lot of things in a large scale, with this, the fear of lost quality during the fabrication appears.
So, the companies started to consider the "test" part of their production process.
After passing the years, the technology evolved and here we are, the generation where if you can't click in a single button, companies maybe can lost billions.
So, is clear that need to test the software in one moment before make it available for the users.
What I need to test?
Everything. Yes, everything. But, we know that this is impossible when you're developing something.
The easy way to start to think what you need to test is:
What is the most important feature that my software needs to delivery?
Probably, reading it, you already know what should work on your software, nice. But is it just it? You can think: "I already do it, but the bugs don't stop"
Let's get an example for web applications:
Suppose, that you have a website, where the user can do these three actions:
- Login
- Sign in
- Sign out
Okay, using the question above, we know the main functionality:
- The user should be able to log in, sign in and sign out
Sometimes, working with other QAs, we say that we need to think that the user is a 5-year-old child, with a keyboard or phone in their hands and using my application.
Yeah, we know that this probably won't happen, but with mindset, we can start to think in other scenarios.
We need to look at our application and start to ask different questions, like, what will happen to my application if:
- The user put a crazy input when doing login? What is the response that the user will have to inform that this input is incorrect?
- The user put the wrong password?
- The user clicks more than one time in these button
When we use the kid strategy(yeah, we'll use this term), we start to think not only about "how I need to code this", but in "how I can code it and the user have a good experience using my software?"
How I can test when developing something
Now that we know the importance of testing and how we can start to test something, we can start to think about how a developer can do it during the development.
In the previous example, we talked about a simple project, but, in real life, software has A LOT of functionalities, and, probably your backlog has a lot of tasks to do, so here are some tips to help you put this in practice in an easy way:
- Ask for examples: When you receive any task, ask for examples of how you can test it. Don't focus only on the basics, ask for different scenarios, what is going to be the responses, and if this can happen. I recommend searching for BDD(Behavior Driven Development) methodology, so you can use Gherkin language to track these scenarios.
Example of how you can use BDD and Gherkin:
Feature: Make login
Scenario: Make login with success
Given I want to make a login
When I input a valid user and password
Then I'm redirected to the home page
Scenario: Make login with an invalid user
Given I want to make a login
When I input an invalid user with a valid password
Then I receive the message 'wrong user'
- Use TDD (Test Driven Development) to write the code: this is a core of agile development practice and it consists of creating the test(unit test) first, writing the code to make this test pass, and refactor the code. This practice helps the team design their code well.
- Automated test for APIs, User Interface: Automated tests are a powerful strategy to make sure that everything is working as expected. Remember to use good practices when automating a feature, question if this test will be useful for the team, and if they can have fast results. You can take a look at the Test Pyramid model when creating this.
- Exploratory test: Basically is navigating through the application as a user. Is a good practice so you can understand how the software works, what you can improve on it, and what is not working.
But the most important of all of it, is to ask! When working with software development, no question is too silly.
This article was based on Agile Testing: A practical Guide for Testers and Agile Teams book and practices that I've noticed in my experience as a QA. I hope this content will be useful for you and for any questions, just reach me out!
Bisous, ร bientot ๐ ๐ผ
Top comments (11)
Avoid bugs at 5pm on Friday....don't agree to work on anything important after 11am on a Friday, ideally take the afternoon off! Ha ha!!
Anyone says they're about to work on something after 3pm on a Friday, especially in prod, we all post this in the team chats!
Nice!
Nice article!
Nice article!
Great article :)
Nice article! can't wait for more complex examples
Amazing article Alicia. I didn't understand the BDD until now, this was very helpful!!
Awesome Article!
Awesome content as always! I'm learning so much with your view of tests
Thanks! I'll talk more about it <3
๐๐ป๐๐ป๐๐ป
Some comments have been hidden by the post's author - find out more