Day 7 - Make sure you get the training you need to use the tool as it was designed to be used. Go back to your management, even if you find a webinar or something online that you can take that’s going to help start you off in the right direction. Ensure that you can tie that training back to the vendor or some trusted source…. THat’s an excellent place to start and something I would highly recommend to folks.
Day 10 - Start to get the whole team to solve testing problems, SO, instead of saying this is a testing problem and this is my problem, use those retrospectives to say, hey, we have this testing problem , how are we going to solve it. Then learn to use the 5 Whys …. to get to the real problem, solve it.
Day 16 - Imagine you’re facing a huge testing challenge that’s been bugging you for a while. Now picture this: you take this challenge to you entire delivery team and say, hey, we’re in this together, let’s put our minds together and find some innovative ways to solve this problem.By collaborating with your team and thinking out of the box, you can come up with some powerful experiments that can help make your testing problems smaller. So don’t hesitate to reach out to your team and seek their help in tackling your biggest testing hurdles.
Day 17 - I think that the most important thing in most software products is that you decompose your system into smaller parts and test them individually. Once you start to split up your big system into smaller parts, many things will become easier. They will become easier to test. It will be faster to run your automated tests as well, because you don’t have to run your entire suite for all your subsystems. You can just run the tests for the subsystem that changed.[Also] everyone should read Eric Evans’ book Domain-Driven Design, I think that’s one of the best books out there.
Day 22 - Prioritize the mean time to diagnosis as a key metric for you testing process. This means ensuring that when a test fails, you can quickly identify why it failed, preferably within a minute or two, without having to rerun the test or go through length debugging processes. To achieve this, you should intentionally try to make your tests fail during development by manipulating the operating system or changing comparisons to ensure that you understand what a failure looks like and how to diagnose it.This practice will not only help you write more effective tests but also save time and increase efficiency in the testing process. Finally, it is important to note that while full TDD may not be necessary, testing practices should always include the intentional creation of failing tests and quick diagnostic procedures to ensure the highest quality of code.
Day 23 - Run your tests early and run them often. Don’t wait until the last minute to check if everything works. By incorporating testing into your CI/CD pipeline, you’ll receive crucial feedback quickly and be able to catch issues before they escalate. After all, you’ve invested a lot of time writing tests, so don’t let that effort go to waste by not running them frequently.Keep your tests updated and schedule regular runs so you can catch any issues and have that safety net to rely on.
Day 24 - To improve your testing efforts, it’s essential to be mindful of why you’re performing each activity. Don’t just blindly follow best practices without considering whether they actually provide value to your team. Even if a particular activity is helpful, ask yourself if it’s the most efficient use of your time and resources. Take the time to periodically reassess what you’re doing and why. Why are you invested in this process? Are there better options available? By doing so, you can ensure that you’re optimizing your testing efforts and achieving the best possible outcomes for your team.
Day 25 - Testers should use their analytical skills to ask the right questions at the right time to see the big picture. Testers should focus on two main questions: are we building the right product and are we building the product right. They should also aim to build relationships with different stakeholders by understanding their needs and coming across as subject matter experts.Testers can add value y being knowledgeable about the whole system and helping different teams with their needs, such as the sales team, operations team, and infosec team. When moving into a leadership role, testers should focus on building trust, communicating effectively, and prioritizing work based on the big picture.
Day 26 - Automation is not a silver bullet.A lot of teams, when they start doing automation, they get dragged away and they get too much into the frameworks and … their automation does super-duper things, but they lose the focus or the intention of the automation, which is actually to help in testing. [Automation] should supplement your testing efforts, not replace it.
Day 37 - To succeed in test automation, it’s critical to approach it as a software development initiative. This means that if you’re building a framework and you lack programming experience, it’s important to practice programming and gain basic program design skills, This doesn’t necessarily require obtaining a computer science degree, but rather learning from your mistakes and constantly pushing the envelope.Don’t be afraid to fail, as mistakes and failures ar essential for learning and improving, With this in mind, it’s crucial to have a strong foundation and understanding of how software and programs are put together. This knowledge will help you create sustainable, maintainable, and supportable software that can withstand the test of time.So start by embracing test automation as a software development initiative, learn to program, practice, and keep pushing the boundaries to make your efforts a success,
Day 40 - To take your team’s test automation efforts to the next level, it’s crucial to start with a holistic approach. Before diving into tools and technologies, take the time to assess your team’s goals and the unique factors influencing your environment.Consider the people around you, policies, and other forces that may be impacting your testing efforts. By understanding the bigger picture, you can make informed decisions that are more likely to succeed.Don’t rush into implementing tools without first understanding the full scope of the situation. ONly then can you accurately determine the best path forward.
Day 45 - Asking yourself why every time you do something is crucial. Why? Well, it helps you understand why you chose that particular path in the first place. As passionate humans, it can be hard to hear criticism of our work, especially when it comes to our favorite frameworks. That’s why finding mentors who can provide constructive feedback is so important.To evaluate the quality of test automation scripts, I use a scorecard with six key areas. First, is it maintainable? Second, is it relevant to the business? Third, does it have clear traceability? Forth, is it reusable? Fifth, is it management and scalable? And sixth, is it accessible across the company?But that’s not all. The script should also be robust, portable, and provide actionable insights with dynamic data adapters. Can you use it to diagnose issues and provide real information to developers?Overall, it’s important to consider factors such as platform technology, data source, test type, test approach, element ID technology, continuous build integration, and maintenance. Bu using a scorecard approach, you can ensure your scripts meet all of these criteria and provide the most value to your team.
Day 46 - When you’re choosing tools or when you’re trying to automate, think about what is important for the business and not what is important for your resume. This is something I see happening often in our industry. Remember that whatever adds the most business value is what is going to take you higher in your organization. And also, it’s going to help the business that you’re actually employed with.
Day 47 - Set and meet growth targets every quarter, I would say, would be my piece of advice. Learn something new that’s important to your career. So, for example, if you’re a black box tester and you don’t know how to program, learn in the next three months how to write scripts. And then three months after that, learn how to program…. As things continue to evolve, it’s going to be important to keep up.
Day 50 - I think the most significant difference I see between testers and the results they achieve is based on how many conversations they have with the people around them. Even if you’re the most awesome tester ever, if you’re not talking to your developers, product owners, and business analysts about what they’re doing and why, your testing will be less effective. You haven’t taken input about what other people have already tested, why this thing was designed the way it was, how customers expect this thing to behave, and what information from testing will be valuable. Without those conversations, you increase the risk of delivering stuff from testing that people find irrelevant.So the biggest piece of real advice that I would give to a tester is to go talk to people, and do it more than you think you should have to. Actively seek out what other people are doing and why. - Katrina Clokie (CTO / Author of A Practical Guide to Testing in Devops)
Day 56 - Please think about maintainability when you write any tests. That’s the number-one thing. A lot of people write tests that only they will understand, or they don’t think of anyone else. If you’re giving the test to somebody else, will they understand it? People forget about that. So think about how other people are going to use it before you write anything. - Anil Kadimisetty (Head of Engineering)
Day 63 - If you want to excel in software development, make a habit of reading about best practices and incorporating them into your work as much as possible. This investment in yourself will pay off handsomely over time.While technology is constantly evolving and becoming outdated, the fundamental principles of software development have a much longer lifespan. By honing your skills and expertise in this area, you’ll be well-equipped to adapt to new technologies and stay ahead of the curve.So keep up with the latest best practices and make them a regular part of your development routine. Your future self will thank you for it! - Vladimir Khorikov (Pluralsight Author)
Day 71 - My approach to better understanding of solidifying my knowledge of anything is a process of consuming information, building with it or working with it, and then teaching about it.
So my piece of advice to you to solidify your testing capabilities is to consume information about it. But don’t stop there. You should start implementing what you learn, whether that’s in projects at work or personal projects for practice. In that process of practice, you will learn a lot. I recommend that you share the things you learn with other people. And if you feel uncomfortable sharing it, you should at least write a blog post and keep it to yourself.
But do something to try and teach it, because that is where you will solidify your understanding of it and realize whether or not you actually understand it when you start to try and teach it.
Day 73 - For mobile testing, make sure to utilize each layer of the mobile testing pyramid. Use desktop browsers with mobile simulation for extensive functional testing and responsive design. test mobile simulators and emulators for functional testing, user flows, and visuals. Focus on usability testing and real-life conditions for real devices. For instance, perform testing with different network conditions and integrate with GPS and background apps. It’s important to test under various scenarios to ensure the app works well in different environments.
Day 74 - Two things that I think automation engineers should aways consider are, first, having a great synchronization strategy. There are four synchronization methods that every tester should have in their toolbox: checking if something exists, checking if something does not exist, waiting for something to exist, and waiting for something to not exist.
The second one is related to object identification. When it comes to locators, I tend to standardize on two or two properties at most. I can usually come up with a great locator with just two properties. I recommend avoiding anything that has to do with the look and feel of the application, such as a class name. Although it’s popular to use CSS class names in locators, I think it’s the last thing you should try to use. Try to find an ID or something else that’s more reliable.
Day 119 - If I had one piece of advice to give, it would be kind of old-school, which is to keep your tests atomic and autonomous if they are UI tests, meaning test one thing and one thing only. You can do multiple assertions on that one thing, but try to take the data and the site into a state that you need to open on the page that you want to open on. Take a single action, make a few assertions to make sure that thing went correctly, and then close out the browser and start the next test. It should take under 30 seconds, probably under 15. If it’s done right, the other thing is to keep them autonomous, which means that any test can run independently of any other test, without interfering with or being affected by other tests. ~ Marcus Merrell (VP at Sauce Labs)
Day 120 - Your automation should focus on the goals of the business. Test automation goals should be in line with what the business is looking for at the end of the day. It’s the business value of a test that makes a project successful. And if your automated test is always failing and no one is paying attention to removing it, it’s not a test anymore; it’s just noise, and it’s not adding any value to the business at that point. ~ Hima Bindu Petti (Senior Software Engineer)
Day 127 - I believe that test automation should involve everyone on the team, not just testers. If testing is solely the responsibility of testers, it will always be a step behind the developers. However, when developers are involved in test automation, you gain the rigor of code reviews and the ability to version tests alongside the code. Therefore, I think it’s essential that tests aren’t owned solely by testers but by the entire team and that they’re visible and subject to developer rigor. ~ James Farrier (Founder of Appsurify)
Day 130 - My piece of advice is to care about your infrastructure. Automation is more than just writing scripts and executing them. It’s everything about it, including where it runs. So go to a whiteboard and draw out all the little boxes - this is the machine that our scripts execute on, this is where the scripts execute against, this is the machine that controls that execution, and thee are the people that have the keys to these various machines. How are they configured? Once you have that map or illustration drawn out, you’ll be amazed at how complicated your actual infrastructure is. And that should be enough to scare you into looking at how to manage it better. ~ Adam Goucher (Director of Software)
Day 132 - The only scaling benefit you get when testing micro-services is if you can force-release the independence of your service from everything else in the organization.Testing is a critical component of that. You need to be able to test your service independently of anything else so that you can release it. Service virtualization is a great way of doing that, and the open source tool Mountebank is a great option for service virtualization. I highly recommend testing it out. ~ Bandon Byars (Thoughtworks Head of Technology)
Day 134 - If I were to give specific advice for anyone considering beginning automation, do not start with a tool. The point here is to say if you have a process that’s not running very well, it’s not gonna be running any better when you automate it. So spend some time analyzing to determine what works and what doesn’t. How can you optimize this particular process in the way that it has to accommodate my business needs within my organization? Only when you have that well in control should you start looking at automating it. If you automate stuff that’s not working very well, it’s gonna keep working not very well, it’s just gonna do it faster. It will cause more pain than when you did it manually. ~ Sune Engsig (Senior Product Evangelist)
Day 156 - Design your code with testability in mind right from the beginning. This means keeping your logic separate, having small, modular components, and building in test hooks. By doing this, you can write your tests right from the beginning, even for small components, and know that you have successful code written when your unit tests pass.
It’s essential to get everyone on the team to participate and collaborate in this process, but it there’s someone who doesn’t want to participate, it’s challenging to move them. Hence, it’s important to create a culture where everyone sees the benefit of writing tests and the positive outcomes that result from it. ~ Jeanine Rust (Software Test Professional)
Day 163 - It’s important to remember that when managing test operations, recognize that there is no perfect solution.
The key is to strike a balance between control and speed, accepting that some trade-offs are necessary. Embrace adaptability to address issues and continuously improve your testing process quickly.
To achieve this balance, consider these steps:
Shit left: Aim to catch bugs early in the development process by integrating testing into earlier software lifecycle stages.
Federate and fragment: Delegate responsibilities to individual teams and developers, allowing them to manage their tests and take ownership of any issues that arise.
Be selective: Focus on running specific tests for the changes made to minimize flakiness and ensure more accurate results.
Use available tools: Don’t hesitate to use third-party tools like Testim to help manage and scale your test operations. They can save time and resources while still providing necessary functionality.
Accept imperfection: Understand that no solution will be perfect and that trade-offs and inevitable. Find a balance between control and speed that works bests for your team and project
Finally, remain open to learning, adjusting, and evolving your approach to test operations as new challenges and opportunities arise. By embracing balance and adaptability, you can create a more efficient and effective testing process that meets your organization’s needs. ~ Maor Frankel (Principal Software Engineer at Microsoft)
Day 170 - The best thing I can say is to look at where your pain points are. Every software system has its own set of annoyances, so when you’re examining the systems you work with, ask yourself: where do I feel like I’m having to work against the system? These are the best places to focus on to make improvements. This is true whether you’re a software engineer, SRE, DevOps tech, QA, or engineering manager. Everyone can benefit from identifying and addressing pain points. ~ Jamie Riedesel (Author of Software Telemetry)
Day 173 - I think the most actionable thing to do is to contemplate whether your software development lifecycle is efficient, because a lot of times people sit on their laurels and say it’s good enough because it’s hard. Trying to fix it yourself is a difficult problem. We tend to find that many companies haven’t really thought deeply about what their process would look like if it was more efficient. What if environments were ubiquitous? How would that change our ability to get products to our customers faster and ultimately grow faster? People just live with these noneffective ecosystems because getting out of it is really hard.
It took me a good two years to solve this problem at my prior company, and it took a lot of fortitude to go after it. If a product had existed in the market, it could have shrunk that two-year time span to a month or six weeks. Engineering leaders need to envision a better state and not just sit there and say it’s good enough because it is the way that it is. Once you’ve envisioned that better state, you’ve got two choices: build or buy. It’s a waste of money to build it in-house. ~ Tommy McClung (Co-founder of Release)
Day 210 - Keep your tester’s mindset when you’re building out your automated test cases. Ultimately, what you’re trying to do is not to automate the application, but to automate the testing of the application and to find bugs. So always keep a tester’s perspective when building out your automated tests and automation framework. Doing so will give the testers and the team the most flexibility in covering whatever scenarios and conditions they need to test. ~ Marcus Thomas (Founder of QUART Consulting Services)
Day 230 - Having a strategy for your automation is crucial. People often make the mistake of thinking they must automate everything, without a clear plan for what actually needs to be automated. The truth is, not everything requires automation. So it’s important to take the time to develop a well-thought-out strategy that outlines the objectives, priorities, and criteria for automation. This will help you avoid the trap of automating everything and ensure that your automation efforts are targeted and effective. ~ Sneha Viswalingam (Director of Quality Engineering)
Day 255 - My advice to take your test automation game to the next level is to look no further than utilizing patterns. The key is to learn from existing solutions and apply then in new and exciting scenarios. Don’t get bogged down with specific tools. Focus on general problems and create solutions that are adaptable to any situation.
But how do you find the perfect automation pattern for your unique problem? Think like a doctor! Use diagnostics (to learn more, check out testautomationpatterns.org) to ask general questions and use the answers to guide more specific ones. This approach will help you identify the most suitable automation pattern for your particular challenge.
And don’t forget to stay up to date with the latest patterns and automation tools. Automation is constantly evolving, so make sure you’re always in the know ~ Serettat Gamba (Author of A Journey through Test Automation Patterns)
Day 259 - I can’t overemphasize the important of faster feedback, teamwork, and collaboration in the software development process. To achieve this, it is essential to address thel east addressed area of iteration, making it faster by building an on-demand ephemeral environment solution. This solution should enable the parallelization of feature development, with every developer having an isolated environment for each branch, and integrate testers and stakeholders to provide feedback earlier in the process.
The higher-level construct of an environment should be elevated to provide an endpoint where developers can reach their applications and test everything else below it that should be automated. Building a culture of ownership, collaboration, and teamwork in software development can enhance performance and create a sense of belonging.
Therefore, it is crucial to invest in solutions that help improve the iteration process, enable faster feedback, and enhance teamwork and collaboration in the software development process. ~ Josh Thurman (Co-founder of Uffizzi)