Takeaways from Day 2 of #TestingUY
Day 2 of TestingUy, this was a great experience and all the kudos to the organizing team ❤
S01 : “Testing like the old days”
Maybe we got lost in translation but the main point of this talk was to provide tester concepts they can take as a mission so the can evolve in the agile world and keep their job :D
- Definition of Ready: how soon you can start testing “something”, you call it user story or prototype but make sure you can start testing before having live code.
- TDD: pair with developers and start writing code through tests!
- BDD: make sure to include the expected behavior of the app into the code.
- UX testing: paper prototyping, scenarios swim lanes. It’s all about User Experience this days.
- Code Reviews: As a tester you can go through the code with or without the developer so you can catch error on flows.
- Value Stream Mapping: Make sure there’s a value output from your team’s work in terms of business goals.
- Continuous Deployment: Get ready to ship, very frequently.
- DDD: Make sure your team is development the right thing and understanding the business in and outs.
S02: Exploratory Testing
Session focused on when and how exploratory is a better a choice compare to other testing techniques. Some scenarios where exploratory testing is a better choice involve having poor or non-existing documentation. As why choosing exploratory if far more interesting as where:
- You can quickly create a base knowledge of the product among the team
- Quick Feedback
- Colateral issues are spotted more quickly
- You can create documentation on the go.
- Identification of poorly known or documented functionality.
- Low cost
- You can always perform exploratory test.
The good exploratory tester likes the risk and uncertainty and really knows how to take notes of his/her observations.
Session was heavily based on James Bach´s approach to Exploratory Testing, so you better check this paper up.
S04: Software Testing in Devops
Devops is pretty in the mainstream, we might as well adapt to join the party. Basically our part here is to own testing and collaborate with dev and ops team to reduce the time to market and have feedback from real users.
How to integrate testing into a DevOps context?
S05: Performance Testing
Session focused on four elements for performance testing:
- Cloud: services we can use to host our services and advantages we can take from them like load balancing, since it’s pretty much pay-as-you-go but you have to find out which configurations would do it for your context.
- CDN: Content Delivery Network, we can think of it as having geolocalized cache server that deliver resources like images so loading time “feels” faster
- CI/CD: Integrate unit performance testing to be ready to go live!. Test services and APIs timely.
- HTTP2: use it! Internet was made upon HTTP1 which support text and images, nowadays Internet is all about Web Apps that need lots of sockets and connections and deliver tons of resources which makes HTTP1 to keep up with this changing approach. HTTP2 is a binary protocol that runs natively under https and one the most interesting point IMO it’s server push capability (sort of deliver resources by chunks as you need them).
S06: Visual Testing
This is a shared pain with evolving software or working all the way up from wireframes to actual live “pages” also when dealing with redesigns.
We have only 2 eyes and limited amount of time/resources to check up on visuals and don´t forget of cross browser testing.
Session aimed to take a look at some available tools to help with the comparing among versions and browsers of visual elements.
Some tools to look into: CrossBrowser, Specter, PixelPerfect, Applitools.
S07: Mocking as a tool for software testing
The bottom line message of this session was: “Do not wait for B to be done so can start testing and discover bugs on A, B and the integration between A and B” (for a model where A expects a response from B)
Tools to look of interest: Mockito, Restito, SoapUI, JustMock
S08: Large Scale Test Automation
What happens when you’re involved in a large scale development with multiple dev teams that cover different parts of the main app and each team uses their own dev and test stack…. CHAOS!
How to find a shed of light on this context?
- Group teams by business line
- Name a Responsible Automator per grouping
- Create a unique channel for communication among all teams
- Practice and encourage cross-testing/training
- Encourage Collaboration
- Set a unique Framework for Automation
S09: Challenges and Benefits of implementing a framework in the process of test automation
Basically this session was a report on experience, so to the meaty tips:
- Understand the context of the actual product
- Understand how manual testing is performed, you must learn from that experience in order to conceptualized your automated effort
- Come up with a strategy that satisfies the context needs. Perhaps you don’t really need automated checks on visuals but you really need automated checks on backend
- Which tests are automatable vs time to have them ready and the value of that activity
- Is your team prepare to automate? Meaning: skillset.
- Things Automation Framework has to have: Base Clases, Data Management, Reporting Capabilities, Versioning, Standards.
S10: Testing is also part of the revolution
Since IoT is taking over Internet and pretty much our lives, we testers have to get ready to this new paradigm.
Main message: start creating your heuristics by checking news, mostly about things that connect to the internet being hacked.
KeyNote: A Ridiculously Introduction to Rapid Software Testing
Do you think as testing as gathering your specs, design test cases and then executing them? Think again.
Also if you think you can only the built product you might be loosing pretty interesting chances to test things like: the mockup of the product, some document describing the product, a diagram that models the product, a product similar to this product, somebody’s idea about the product.
Testing is the process of evaluation a product by learning about it through exploration and experimentation
We question and get questioned a lot about our work, but are those questions really important or is it just a lack of confidence/trust?. Michael proposes that we have carry only two as fundamental questions about testing:
- Is there a problem here? Is your product making sense for who is intended to be?. We can only test for the presence of problems , we can not assure there won’t be any.
- Are we okay with this? Stakeholders want to know what’s going on with the project so we have to build trust with our reporting otherwise we’ll get boring questions all of them including metrics. What Stakeholder really want to know is wether there are problems that are threatening the on-time successful completion of project or not.
The whole premise of Rapid Software Testing is to test efficiently with low cost with an open mind. Treat testing as an activity rather than just on the artifacts or metrics, those thing don’t matter if you build and demonstrate trustworthy results and reports.
I really loved this idea of testing being like telling stories and really makes sense if you can put in simple words what you’re doing and by that help your team spot problems are achieving business goals or value, you´re doing great job :)
Some food for though and homework for us, tester ;)