Julia Atlygina and developer Alexander Ivkin came by our TestRail stand at the Atlasssian Conference. Imagine our surprise when we learned they had created a mobile application that enables users to view, execute and get reports on their tests from a linked TestRail instance!
As you’ll know if you spend much time listening to and engaging with the various testing communities, there is plenty of discussion about the important distinctions to be made between checking and testing activities. Checking is an activity to be performed using tools and automated tests; but for testing, we need a human mind. And it becoming increasingly important that the person carrying out that testing is able to adapt and think in a generalised fashion about the object of their testing.
I recall a project where we worked using a Waterfall approach, with the QA team only involved in the final stages of product development. As a result, our testing activities were confined mostly to scripted checking, without much time to think about the features we were testing deeply, since all the testing needed to be finished yesterday. We only had time to check the product according to its specification and ultimately, customers weren’t hugely impressed.
Over time, we analysed whether there were some ways we could improve our testing approach, trying to understand whether there were some activities we could skip or decrease. Since we were mostly spending our time on tedious checking activities without finding much scope for more useful testing that would leverage our knowledge and activity — I was curious to see where other teams were spending their time.
Asking around, I got the following answers in order of popularity:
- Documentation
- Communication
- Environment Preparation
- Checking
Did the same apply for my team?
Get TestRail FREE for 30 days!
Documentation
A resounding Yes! We spent a lot of time preparing test cases, plans and reports. Tedious work, and we weren’t convinced anyone was even reading it all! Obviously it’s important to use a great test management system [Flattery! – Ed.] One of my associates, he even went so far as to maintain a matrix with tool names and a ratio of time spent using them: When somebody asked to estimate a testing activity utilising a specific tool, he referred back to his matrix and calculated the estimated based on his historic recordings!
Be careful to choose the right tool for your work. Don’t waste time on pointless clicking and configuration.
Analysis & Communication
When we worked using a Waterfall methodology, we had a lot of specifications — but they were mostly out of date. We weren’t involved in planning and all our questions during the test phase were “too late!” This is the most important part of our work; especially on agile teams. Everybody needs to understand what is being done and why, since there is no comprehensive documentation.
Checking Features & Regression
Here we spent time not just on clicking buttons, but also on analysis and triaging bugs. This part can often be partly automated on different test levels. For manual tests we can use checklists, and the test engineer will have some freedom as to whether they concentrate on exploring the product rather than sticking to pre-scripted steps. We discovered that having somewhere to store our tests was important, making it easier to define a test plan, run tests, and check progress. Without a good test management system our team spent too much time here, just because it wasn’t easy to run tests or create reports and it was a nightmare for managers to understand the progress.
Something Always Goes Wrong
Something always goes wrong, especially with our “test karma”. A fix missed in the build, CI moved to another server or something else… We spent a lot of time solving problems, we should admit it.
I would like to share some more tips with you:
- Don’t add detailed instructions if the feature is not done yet. Use questions and checklists instead, and save time on updating docs. It was one of the most time-consuming things in our project: we tried to create great tests from starts, but it is impossible.
- Keep note of all thoughts and comments, right into your tests and tasks. Don’t miss details shared by the developers with you! All information might be useful at a later date, so make sure you have somewhere to put it.
- Use automation where you can to help perform checks faster, saving time for exploratory testing instead of checking. There are a lot of different services and plugins available, particularly for e.g. security like the 10 Web Security tools listed here.
- Choose the right tool for test management. Don’t waste your time on merging Google docs or Excel files. Test Rail is a great example! It is the most powerful and easy-to-use tool for your tests, helps you to store all tests in one place, share your progress with other during integration with issue tracking systems. [Agree! Checkout our free trial, here. – Ed.]
- Decrease the amount of time you spend on test execution. Make it as easy as possible to run your tests, using automation where you can.
- The status of testing should be transparent for everybody in the team. So, your managers will not bother you with questions.
Some of these problems can be easily resolved with MoQA, a brand new, fast, simple and beautiful mobile solution for running your tests. It is available for Android and iOs and it will help you to speed up your testing.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
3 Things MoQA can Help You With
- Test everywhere. In the hardware lab, on your developer computer, even during the boring meeting 🙂
- Test faster. Just swipe it! Test status will be set immediately.
- Always know the real progress. Check it at any time!
So, spend less time on checking and tedious work. Spend more time on real QA with TestRail and MoQA!
This is a special guest post from Julia Atlygina, Head of QA at ALM Works, inspirer in MoQA team. Julia has spent the last 8 years as a tester and is an active member of various IT communities as well as being an agile expert and lector.
