May 15, 2017 / by Ekaterina Budnikov / SEO & QA manager / @KatjaBudnikov
The STAREAST Virtual Conference is a conference which you can watch from your home or work desk. You can watch some keynotes and other sessions from the STAREAST Software Testing Conference via livestream and learn about the latest testing solutions and experiences of companies with testing.
Keynote: the power of doubt: becoming a software sceptic
Zeger Van Hese was talking about the fact that we, especially testers, are expected to be certain and are not supposed to show weakness, to be insecure or not to know something. He actually thinks, that we should embrace scepticism and also be sceptical of ourselves, so that we can have a more balanced view of things. Everything should be questioned and one should ask himself: “What if I’m wrong?” Do you really know what will be affected when you change something? If you want to be a good tester, you should maintain uncertainty and try everything to disprove that something works. Only then you can find every bug in your system. The best way is to ask questions and to question the answers - so try to ask yourself what led you to the interpretations you made.
Keynote: What really happens when you deliver software quickly
Sally Goble first talked about the change in the model of software delivery. Earlier there were DVDs, CDs or even floppy disks with the software. You had to buy it in an actual store with physical money. The delivery was once a year, therefore the software had to be perfect. Then the internet arrived and got popular and now software gets delivered electronically. The cycle isn’t once a year anymore, but once a month, a week or even a day. Some software also has continuous delivery. This all leads to a change in software testing as well, as QA sometimes gets to be a bottleneck. Manual regression is too slow, so that automation is necessary and you have to reduce the efforts that are needed. Maybe you could even change to spotting anomalies rather than checking every little detail. You should try to reduce your effort for testing to a bare minimum. This can be reached, when you minimize the risk of deploys (for example by using feature switches, canary releases, deploys of single features) and with good monitoring and alerting. Critial things still should be tested on a regular basis so that you can guarantee uptime of your product all the time.
Keynote: Step aside: Stop leading from the front
Bob Galen talked about different styles of leading like from the front, the side, the back, pushing or pullling leadership. He said that you could be the type of leader whose motto is “at my signal unleash hell” but it would be more productive if you break the ice and create a space for problemsolving and collaboration. There should be space for learning, growth, discovery, passion and creativity. You should not be push-based (tell, command, decide, pressure, make decisions), but rather be pull-based (mentor, coach, guide, ask questions, keep balance, explore options). You should build a safe environment, which means that it is safe to:
- try new things
- say no
- show vulnerability
- tell the truth
- not know
- ask for help
Sometimes you have great followers who are obediant, servant, humble and loyal. This could even result in servant leadership, which means that this follower will try to help people to perform as highly as possible and to share the power. He will put the needs of others first and help them to develop. Therefore you should listen to your team and try to understand each and everyone instead of just replying to them. Active listening is the key to being a good team leader.
DevOps: Testing tomorrow’s release today
Jason Benfield started by talking about the change in the way software development teams work. Before there was the waterfall model with standardized tools and waterfall releases. But then teams started changing from just having specialists as team members to being crossfunctional teams. Now the teams are more and more agile, which means:
- more communication
- accelerated releases
- being able to adjust things
- being able to respond more frequently to market expectations
Therefore teams started to move to DevOps. That means they define pipelines, check in their code, deploy the code to a test environment, execute automated tests and examine the results.The challenges of continuous delivery have to be solved by automated tests and lifecycles, leverage of developer assets, reuse of scripts across tests, integration of all tests into the CI and by building a feedback loop at the pipeline level. The testing and monitoring has to be an important part of this progress, so that you are able to see how healthy everything is.
Unlock testing productivity by mastering test data management
Matthew Yeh and Brett Stevens were talking about test data mangement as data is somehow like the new oil. The data delivery to developer and testing teams might be a bottleneck. It might take minutes for the data to proceed through the data supply chain from the request to the fulfillment. Modern data platforms should be fast, simple and secure. Often there is redundant data in non-production environment which has to be avoided. This can, for example, be done by sharing data blocks to non-production instead of just copying everything. With a self service you can have quicker and more internal testing cycles.
Test automation at the speed of agile: making it work every build
Danny McKeown started by showing the test automation pyramid. At the bottom you have the unit tests (e.g. Jenkins: build, deploy, test) which are the basis. Then you have API tests (e.g. cloud connectivity, database, web service, non-UI regression) and finally the UI tests (e.g. regression, sanity, release). If you want to be able to scale, you should run tests in parallel to save time, auto build-deploy-tests are needed and you ideally should have continuous delivery/integration. Even the definition of done should already include automation. Integrated, scalable and parallel continuous testing should look like this:
- job submission (IT platform)
- transpose job (web & API server)
- data center (DB)
- execute job (virtual machine)
- target environment ((non) production)
Keynote: Navigating the nuances of detailed test strategy creation
Randy Rice criticises that there are no standards for test strategies. As things don’t always work out as planned and every project you encounter has its own factors (and changes will impact these factors), your tests also might not work as expected. As there are new risks, the project might change and the results of defects might affect your project, you have to be able to make the right adjustments at the right time. Overall you should have focus, a direction, a big picture view and you should search for certainty. You always have to have in mind, that there are several nuances of test design, which are:
- test basis
If you keep all that in mind and have some different plans in mind, you should be able to find a strategy for testing that suits your project.