#Day_01
Agile Test Plan
How to create a light weight test plan which goes handy with agile development (5W1H):
1. Why - purpose of the feature/user story
2. Who - actual user journeys
3. What - in/out of scope
4. Where - environment details
5. When - timelines/priority
6. How - test design and execution
#Day_02
User journeys
User journeys can help in testing in many ways:
- Visualising the customer experience
- Understanding the customer pathways
- Uncovering and prioritise real pain points and roadblocks
- Increasing empathy for the customer
Here is my tip to create a user journey map:
Example: AS A <persona>, I WANT <feature> , FOR <Business Value>
Stages: Decide - Travel - Experience - Explore - Return
<Decide> What are the various ways to use this feature (entry points)?
<Travel> How to use this feature in real time?
<Experience> How did I feel after using the feature (consider the feelings of different personas if applicable)?
<Explore> Can I do something more? If yes how?
<Return> Can I return back to starting point?
#Day_03
Characteristics of Test artifacts
Test artifacts should be easily understandable for anyone. As a tester, we need to collaborate with different stakeholders. What's is obvious to tester may not be obvious to others. Test artifacts are like time capsules, we never know when those will be opened for consumption and by whom. It doesn't matter what type of artifact we create, it can be a product understanding map, a test design, a defect report, or test automation code. A defect report with no precondition and clear steps to reproduce can be of no use for anyone and most likely to get rejected. Similarly, automation code should be expressive so that it is easily readable, understandable and maintainable (PIE principle - Program Intently and Expressively).
#Day_04
Github as source of learning
Github is a great source of useful resources not just related to coding. Sharing few of my favorites here:
1) https://lnkd.in/gndwvMNh
2) https://lnkd.in/gTDh7gbp
3) https://lnkd.in/gPQMbrTb
4) https://lnkd.in/gPY5cEU7
5) https://lnkd.in/gkv3NkpV
#Day_05
Error messages
Keeping an eye on error messages can be a life saver. We can broadly classify errors into three categories:
- Code related (due to exceptions, due to memory allocation, missing attributes or key values etc)
- Environment related (server or database not available, browser not supported etc)
- User related (incorrect credentials, insufficient permissions etc)
Here are my tips for keeping a balance when testing error messages:
- Showing complete stack trace in error message should be avoided and replaced with meaningful error message to avoid confusion.
- Error messages should be contextual. For example: "File upload failed!!" message is incomplete from both user as well as developer point of view. Adding more details with help the developer to debug the issue while user can be notified why file upload was unsuccessful.
- We also need to keep an eye on the nature of information provided in the error message for example it should not contain secure information like exact internal file path in the server or any other sensitive information which can be vulnerable.
- If the error is a known issue and needs more time to fix, probable workaround could be provided in the error message to unblock the user until the fix is ready and deployed.
#Day_06
Tools for daily productivity
Tools from different categories can be very handy for collaboration specially when we work remotely. Here is my tools categories checklist which I do not want to miss in a day to day work:
1) Video conferencing
2) File storage/sharing
3) Messaging
4) Project management
5) Calendar management
6) Mind mapping
7) White boarding
8) Screen capture/video recording
9) Notes taking
10)Wiki pages
#Day_07
Security
While creating security testing strategy for cloud native application, do not miss to consider the 4C's of Cloud-Native Security.
- Code -> Application layer security (code scanners)
- Container -> Image security (from known source or trusted registry)
- Cluster -> Kubernetes components (Role based access control)
- Cloud -> Infrastructure security by the service provider
#Day_08
Select right candidate for automation
Picking tests for automation is tricky and tempting when we have lot many combinations to cover from both happy and unhappy/edge paths. Here are my tips to keep a balance:
- Focus on creating a robust automated tests which can give quick feedback instead of false positive. Automate key business requirement examples from UI and delegate remaining combinations to the layer below (in this case API or DB as applicable) so that we get good coverage and faster feedback.
- Follow layered architecture so that changes from the application side has less impact on the tests in the business layer which can be written using DSL.
- Pick up a strategy as per the nature of the tests, for example tests with async events may need special attention. Some ways of handling those could be reducing the waiting time in test environment, use polling mechanism in the check instead of static wait or monitoring intermediate event generated and validate it instead of opening another application like opening the mail box or sms which may leads to error or timeout.
- Do not add automated tests to validate all the data accessible via UI for example all the entries in a drop down or all the records in a table. Automate it as per user action for a specific user journey and validate the state change in the application. Data can be validated in separate tests using source vs destination comparison making APIs/DB calls in much better and faster way.
- Adhere to the test pyramid when selecting any test for automation. Make sure we have good amount of tests automated as per the different layers of the pyramid like more unit and integration tests without ignoring critical end to end tests.
#Day_09
Understanding the real stories behind each Defect
Every defect tells a story if we want to listen to. The story could be about:
- Pain points and frustrations
- Feelings
- Comparison with similar products
- Gaps in different environments
- Impact and consequences
- Frequency of reoccurrence
A well maintained and classified defects repository can be a good source of learning for the product team. It can also help predicting and preventing similar defects in the future.
#Day_10
Criticise new ideas but not the people behind the idea.
It is essential that we brainstorm while doing testing very frequently in order to avoid missing obvious defects. Everybody feels at ease when the entire team discusses new ideas to get insight into the pros and cons and take a collective decision on how to proceed. Prior to accepting anything, it might be a good idea to agree on what best means in a particular context. For example if someone in the team suggested a low code automation tool to improve productivity and reduce the time to market, we should not just blindly dismiss the idea due to the cost associated with the tool or the less experience person in the team suggested the idea. We should explore and find out how that tool can actually help by taking an expert advice, taking a trial and doing a POC. We never now there might be light at the end of the tunnel without actually getting into the tunnel. In any situation, there is no absolute best, so the reason for making a particular decision should be explored, understood and accepted so that no one felt left out if they had an idea. Always remember one thing an idea can change the world, may not be the entire world but definitely the small world that matters most to us.
#Day_11
Let business make a decision but keep the records and reasoning behind it.
An engineer's log or note can be very handy in long run. Although we do add most of the things necessary in release notes, but that is not enough knowing the business decisions made behind the scene. The decisions I am referring can be anything as listed below and more:
- Tech Stack changed from relational database to document database.
- Business flow changed and new user type added with new set of access roles.
- Data migration from on Prem to Cloud is needed.
- Cross browser testing is eating up most of the regression time.
- Not to fix some known issue due to time and budget constrains.
Keeping track of each business decisions with date, what and why factors - can be handy to the project team as well as customers. This can be in any format like a simple journal or wiki page with relevant details and/or email conversations added.
#Day_12
Some quick equations related to Automation :-)
1. Automation != <Selenium> or <Rest Assured> or <Postman>
2. Test Automation != Automated Testing
3. BDD != <Cucumber>
4. TDD != <TestNG> or <PyTest> or <NUnit>
5. One tool or framework != Enough for all testing needs
6. Automation != <Regression testing>
7. Automation != <Easy>
8. Automation != Alternative of functional exploratory testing
9. Automation != <No investment> or <No Maintenance>
10. Automation != One stop solution for all testing problems
#Day_13
Up skilling on coding
Coding is a nice to have skill for any software tester but unfortunately that does not come naturally for everyone. If you are someone who is trying to learn coding/automation but feeling like giving up after sometime here are some tips which can help you:
1) Revisit the purpose - Why you have started learning that skill? Keep this written somewhere you can easy see daily basis.
2) Find out the best learning approach - Books, blogs, videos or instructor led courses. Remember one thing, the best approach for someone else might not be the best one for you.
3) Prepare a plan - Create a step by step learning plan with planned and actual start and end dates. It can be as customised as you like to and keep it maintained.
4) Discipline and consistency - Fix a dedicated time slot which works for you - morning/afternoon/evening/night and not miss that for any reason except emergencies.
5) Cut down distractions - To start coding and building logic you just need pen, paper and quiet room. Once you have your your code ready on paper, you can run it using any online IDE. You can move to IDE any time you feel you are comfortable with basics.
6) Read code - Learn a concept, solve few problems and then try to understand the solution written by someone else for the same problem from any open sources like blog or github. You will get more confidence if you can understand someone else's code.
7) Find a buddy - It’s easy to give up when someone who don’t believe in you, who misleads you, or always discourage you tells you to give up. Find a buddy who encourages you or be part of your success journey.
8) Reward yourself - Every small milestones count, reward yourself for all big or small wins.
9) Measure progress but do not compare yourself with others - Take your own time and make sure you are progressing. If your friend has learnt it in one week does not mean you will also be able to the same in same time.
10) Keep your backup plan ready - If after trying everything you are not satisfied with your progress, start exploring your backup plan. This should not be the end, but the beginning of another career journey you love to have.
#Day_14
Backup/Restore
Since today is world backup day (https://lnkd.in/gn_4Gs2k), I am sharing few tips to keep in mind before doing backup and recovery testing.
1) Knowing the data to be backed up well :
- The nature (3 Vs - Volume, Velocity and Variety)
- The Importance (High/Medium/Low)
-The Security and Protection policies
2) Know where the data is residing :
- Physical servers/devices
- VMs
- Cloud
3) Knowing the data retention policies:
- What to retain and what not
- How long to retain
- Archival policy
4) Know the cost of down time :
- Impact/consequences on both internal/external customers.
5) Versioning
- Storage requirements
- Number of versions to be maintained
6) Backup frequency
- Rate of changes and criticality of data
7) Scheduling automated back up process
- Tools selection
- Trials and POCs
8) Restore testing and validation strategies
9) Documentation of the entire process
10) Notifications and alerts - both in success and failure situations.
#Day_15
Usage of Regular Expressions
Regular expressions are very useful in testing. Here are some real time scenarios where we can use regular expressions:
1) Finding errors and exceptions and counting occurrences of any value/pattern in log files.
2) Validating user input fields with patterns like url, phone number, email, SSN number, Zip code, Date and time, Credit card number etc.
3) To split files containing delimited data.
4) Can be used in Maven pom.xml file.
5) Can be used in text editors/IDEs to find and replace values.
6) Can be used in writing test assertion.
7) Can be used in database queries
8) Can be used in writing xpath/css selector.
#Day_16
Give Others a chance to solve problems.
Problem solving is both tempting and difficult to resist at times. But sometimes you should hold yourself back and offer an hints to solve a problem rather than diving in right away, particularly if you are mentoring someone.
- Giving an indication of the problem, but not the complete solution, can help the other person find it on their own.
- The person is likely to learn more than simply the solution.
- Next time, if a similar problem arises, they will figure it out on their own without asking for assistance again.
- Sometimes, the person will come up with an inventive and effective solution to the problem that we had not even considered. It will benefit both parties by allowing them to learn something new.
- If multiple levels of hints failed to help much, it's ok to explain the solution in detail. The right level of guidance at the right time can save time and energy as it is not necessary that two individuals think the same way at the same time.
#Day_17
Choose technology based on need
Some problems can be very well fixed keeping good processes in place than using technology.
Automated tests are failing due to dynamic identifiers.
- Do not rush to fix those using another technical strategy, instead take help from development team to provide unique ids and make that part of DOD in the story.
Product is very buggy
- Do not think about adding more tests is the first step to solve. Perform a root cause analysis and find out the best way of preventing most obvious defects early in the life cycle.
Too many code commits in a day
- Fix a dedicated time by discussing with your team when you can run your automated tests with less impact due to the incremental changes. The test engineers will get enough time to debug and analyse test failures before next day's execution.
Last minutes changes in code
- Pair up with the developer, validate the fix together. In case any new regression issue found, fix those then and there, instead of doing it in silos and going back and forth. This will help is saving time as well as makes the process much faster.
#Day_18
Keep asking why until you understand the root of the issue.
Do not accept answer unit you are able to unblock your mind.
- This works in my system and should work in yours too - Why?
- Clear the browser cache and reboot your machine it should work - Why?
- Client want it in this way only - Why?
- This will never happen in production -Why?
- This is how it is designed - Why?
Explore what is relevant as per your understanding on the product you are testing. Your question may give the team a new prospective they have not thought before. Do not judge your question before asking.
#Day_19
Git Explorer
Version control is always an integral part of software development. Beginners may find Git commands confusing at times. Here is a link to an online git explorer which is very handy for knowing the usage of commonly used git commands - https://gitexplorer.com/ .
#Day_20
Assertion Best Practices
In order to establish a good test coverage, it is necessary to keep the test code easily maintainable and readable. This allows the developers to add new tests and perform refactoring without fear of breaking anything which was working before. Here are my tips for making the automated tests validation more effective and maintainable:
- Follow AAA (Arrange - Act - Assert) pattern.
- Keep your logic out of the assertion statement , use pre-calculated values.
- Each test should be atomic. Add just one assert in each test method.
- Avoid inter dependencies between tests.
- Add assertions in the business facing layer of your testing framework , not the application facing layer (page objects).
- Add relevant error message in assertion for example instead of Assert.AreEqual(<Expected>, <Actual>), use Assert.AreEqual(<Expected>, <Actual>, <Error Message>)
- Assert requirements, not implementation details.
- Avoid using too much logic with loops and conditions which makes the tests harder to grasp and more error-prone. Use fluent assertion libraries like AssertJ which can do the heavy lifting in this case.
- Avoid assertTrue() and assertFalse() which may produces cryptic failure messages.
- Use helper functions for doing pre and post setup, creating data and complex assertions.
#Day_21
Learn, Unlearn and Relearn
The process of unlearning involves giving up things that are not relevant for us anymore, which can be harder than the learning itself at times. Here goes my tips on the same:
- Unlearning can be related to assumptions, skills or habits. Set your end goal by asking relevant questions.
- Once decided , there should not be any room for going back. Be ready to come-out from your comfort zone if needed.
- Be Open minded and ready to paint the new blank canvas with your creativity.
- Be ready to take risk, deal with complexities and face unpredictability.
- Put yourself on some challenge which motivates you. (#21days21tips is a good example of setting up a habit of sharing knowledge consistently for 21 days)
-Keep yourself upto date with the knowledge that is relevant to your success.
- Self retrospect to measure your progress.
- Find a buddy to challenge, support and motivate you.