Iāve been asked to come up with a light weight document on testing best practices by our Head of Engineering. This document should cover every aspect of QA within our organisation including manual testing, automation testing, career development, team structures, process improvements, quality gatesā¦basically anything you can think of!
Currently testing is very much in itās infancy and we need to come up with a plan on what we want to achieve and how. I appreciate this doesnāt give much context but if anyone can offer some advice or links to resources that might help ensure I cover all of the bases that would be great!
There are no best practices - only good practices in context (Cem Kaner/James Bach - Context Driven Testing).
Testing is highly context driven: https://context-driven-testing.com/
No one knows your context, so no one could suggest to you anything specific.
Give people more info, they can tell you what worked in a similar context, then you take your own learnings and decisions from there.
Keith Klain was saying - donāt manage testing, manage risk, align testing to the business strategy.
Iād suggest you to evaluate the context youāre inā¦collect as much information as you can.
Make interviews with business stakeholders or representatives, check product history and itās problems, try to view potential risks and gaps in order to generalize a process problem. Then try to find solutions where testing could help, if testing could help. Sometimes the problem is somewhere elseā¦
Remember that testing is a technical empirical evaluation of a product done on behalf of stakeholders, with the scope of finding threats to the quality of a product;
If you want to progress the testing within the company long term, have a look at some heuristics of Huib Schoots:
@ipstefan thank you for the reply and links, I will be reading up on those over the weekend!
Iāve been given until Monday morning to come up with something so no time to interview stakeholders.
In short, I joined the company almost 5 years ago as the sole tester. Since then the test team have grown to 8 people (all manual testers) and 100+ developers. There was no testing when I started and only recently have some developers started writing unit tests (the culture was the first thing I thought needed tackling). There are no quality gates, the methodology being attempted is Agile SCRUM, dev teams often release to clients without testing so we have a high bug turnaround and there is minimal automated testing and no performance testing. We have a very flat structure in terms of test management (1 lead then 7 testers) but luckily a high staff retention rate within testing. I almost want to look at this as a blank canvass and approach things as though we are the first testers and we want to introduce QA from scratch.
The recent covid19 situation proves that Testing is necessary to overcome the future risk. Agree??
Letās come to the point
Similarly, our software or application also needs Best Testing practices to overcome future risk and that helps us to achieve the highest ROI.
Here I would like to share some of the best and top practices to ensure successful software testing projects.
I would more look at established practices- than ābestā. A practice is something that someone have to a certain degree. To the individual or team a practise can be more or less evolved. And as more teams apply practices they become community team practices - perhaps even industry codified (best) practices. And then they fade away due to better practices catching on.
What you can do, is to do a snapshot of where QA teams like yours seem to be wrt:
Getting testing to be part of DoR and DoD
building in Observability and Testability
working from Modern Testing Principles
working visually and collaboratively
It turns out you can actually visualize trends and relationships between practices and map their evolution. I have some experiments in wardley mapping for this purpose. see for instance Characteristics Change or To Transform Testing
Perhaps read this book - they have another good take on how to align to what you and the Head of Engineering are looking for:
I donāt know your context, but Iām pretty confident that these statements are not true.
Testing is learning about a product through exploration - unless the programmers and business people were robots or people completely uninterested in their work, I would say they did (and still do) some form of testing. It may be highly tactical and full of room for improvements, but there is something there.
@jesper thanks for the comment, makes a lot of sense when you say practices are established but may not have evolved within a team or organisation. I think where I am the practices are less evolved due to a number of different factors. Also like the approach youāve suggested to evolve those practices and will be purchasing the book!
@joaofarias I think thatās a fair point. There would have been testing but very little. There were no unit tests being written, no integrated tests and no automated tests. I believe the extent of testing was manual testing by the devās covering a very small area of the code change. Other than that there was nothing else!
Been thinking all day where might the best place to drop in a small nugget I found today. It is a random nugget though. Iāll give it to you @jamesking , even though Iām a bit late and hopefully you will also update us on how your plan presentation did go.
I do like the idea of lightweight, āmission-statementā kind of weight. And I sincerely hope that you presented testing practice as a journey with many stops and direction changes, but one that is a key part of the SDLC. A journey that feeds back improvements more quickly as automation helps extend itās reach, and one that gives more relevant direction, as the quality journey deepens. But here you go https://how.complexsystems.fail/
It wasnāt a presentation but a very simple bullet point list of things the test team would like see in the organisation under the heading of testing best practices. Despite the short timescale and urgency to prepare the list I still donāt know if the list has been read!
An erroneous application is not only expensive and time-consuming but also degrades the companyās reputation and results in business loss. Following some testing practices by QA Team can help in avoiding the aforementioned pitfalls.
An organization can ensure the implementation of these testing practices on qa outsourcing as well.
1. Choosing release criteria: Before entering into a testing cycle, a tester should have a clear understanding of what features are to be tested.
2. Execution of Regression suites: Regression testing should be carried out to make sure that the new feature does not break the existing functionality.
3. Focus on end-user experience: The application should be tested from the end userās perspective, for example in terms of UI, functionality, user-friendliness.
4. Quality Test cases: Test cases should be descriptive, independent, and have test data added.
5. Scope of Testing: Devices and browser configurations should be known to a tester before indulging in testing
6. Sanity Testing: Sanity testing should be carried out in production post feature release
There are some good answers here already on which practices you could use for testing. Hopefully, they will give you concrete points to make in your document . But, Iād like to add that the ābest practicesā depend on your situation or context.
I am not being facetious or dismissive here. Consider driving for example. The best practices in driving depend on your context. Of course, there are some well established practices that most drivers could benefit from, regardless of context. Examples of well established practices for driving can be to check your seat belt, indicator or blinker lights, fuel, mirrors; show your lane change lights etc. However, the ābest practicesā for driving will be different for driving in a city (of developed country vs under developed country), in steep hills, in desert, in snow, as police car chasing a vehicle etc. For example, in snow, you have to accelerate and brake differently as compared to a city. Lane change practices are not needed if you are off-road.
@anon68517856 yes that makes sense and I agree. There are general/fundamental practices that could be adopted regardless of context and then there are practices that are very much context driven. My hope in raising this question was to focus on those practices that are considered to be general/fundamental, such as āitās a good practice to test prior to deploying to productionā, and then to build on these fundamental practices with the context driven practices.
