Tuesday, October 13, 2020

PNSQC 2020 Live Blog: Testing COVID-19 Models: Getting Important Work Done In A Hurry with Christian Wiswell




Now, this is interesting and timely :). I had wondered if there would be sessions specific to the biggest challenge we have faced in decades as far as health and public safety is concerned. Looks like I was not to be disappointed.
 



COVID-19 has disrupted a large number of things for a lot of people and the odds are high it will continue to do so for a long time. However, how are we able to make these determinations? How do we respond to these situations? How do we determine where to intervene? To do this, we need to use and refine computational models. I confess I have always wondered how these models are created and more to the point, how would we test these computational models?

To be frank, the idea of testing this is hard for me to get my head around. How do we determine if the model created will map to reality? It seems to me that being able to track data and getting actual results seems to be a constant chase for data. Christian points to the fact that getting a point for point confirmation is impossible. So how does this work?

The key to this is that going from exposure to infected state, to treatment time, to recovered state, is logged and is tracked. based on these values, statistical tests are created and run. These tests are run multiple times and they are tracked to see how they behave. In short, there is no genuinely "true" test, but there is a way to confirm that the results are predictable and consistent. It takes a lot of time and testing. Over time, we get used to how these tests run and we get a general example for how a disease behaves. COVID-19, however, acted in ways that these models were not totally prepared for. While we had warnings in November 2019, the modeling scenarios for other diseases were inadequate for the novel Coronavirus. It behaved differently enough where the software models were not up to the task, as well as finding the team in lockdown because of the spread of the disease (wow, that's a pressure I've never had to deal with).

Covasim is what it sounds like, it was a Covid simulator with custom code that Christian had not worked with before. there were unknown dependencies and properties for the code was going to take time to learn about. To start, there were a variety of parameters that could extend to support classes. One challenge was to be able to change the vocabulary so that code tokens were more easily spottable (such as mapping the variable n to "NumberofInitialParticipants"). the first test was a way to get data about the random seed). The test to confirm the random number being pulled before the random number was populated helped to determine if the tests could be repeatable. One of the most important things to look at was the "test exposure to infectiousness delay deviation scaling". In short, how long did it take from the time of exposure to the time of being infections, whether or not symptoms were showing? Over time, with more data and more tests, the confirmation that the general mean of the experiments and tracking data became more consistent. In general, it meant that more people would be able to be predicted as to when they would become infected and be infectious. 

One of the key things to realize is that you are never testing if the software is correct or behaves correctly, but whether or not the configuration is predictable and the model matches real-world behavior over time. It's also important to configure unrealistic scenarios so as to see if the outputs are either in line with the values provided of that the outliers are so out that the exceptions actually prove the rule.

I confess freely this level of testing is outside of my wheelhouse but I'm greatly appreciative for this talk. I've always wondered how these tests were determined. I now feel I have a better understanding of that, if only a little ;).      


PNSQC 2020 Live Blog: Generator-Based Testing: A State By State Approach with Chris Struble




Over the past several decades, we have seen a shift away from manual testing to automated test execution. While automation can help us take out a fair amount of the tedium of everyday testing, what we still deal with is test design at a manual level. Most of our tests have to be considered and have to be designed to be effective. Examples are good and testers are god at this but again, we are not terribly patient so we don't necessarily do a broad number of tests because, well, we are lazy.

  


What if, instead, we could generate test cases based on software coming up with more examples than we can provide? Testers create a description based on the tests they want to run. based on the data the tester provides, systems would then be able to generate additional test cases and generate multiple examples of tests we can run. I do some stuff like this currently and manage a number of for loops with a list of areas in want to focus on. that's a rudimentary level of this, but what Chris is describing goes considerably farther.

Our typical test case matrix focuses on Example-based testing (EBT). Test cases are manually designed one example at a time. we can then fill in parameters for those tests and then execute the tests we create. the problem is, of course, EBT can only test examples that are part of my matrix. It doesn't test for things I did not include.

Generator-based Testing (GBT) works by providing our descriptive tests to a system and that system can then take what we provide and create random tests that muck with the data or creates oddball examples (fuzz testing fits in this mold). 

I've had a dream since reading James Whittaker's book "How to Break Software" many years back. He has a first maxim that I have always loved, which is "look through the code and find every error message listed. Figure out what is meant to cause that error message to display, and then get that message to display through software interactions at least once." I'm paraphrasing but you get the idea. How cool would it be to be able to have a tool that would specifically look for error messages, determine where in the code those errors were supposed to display, and then give me a matrix of options related to automated tests that found be run to surface that error.

This is an interesting thought experiment and I confess not one I have given a lot of attention to. 

PNSQC 2020 Live Blog: Breaking Down Biases and Building Inclusive AI with Raj Subrameyer

 


All right, here we go with Day 2!

First of all, I want to give props to Joe Colantonio and everyone else for the management and efforts of yesterday to keep everything on track. For those who are wondering what it is like to do a conference totally online, it's not always seamless but Joe handled issues and problems like a pro.  Some things that have been interesting changes:

There is a Virtual Expo so if you want to see what vendors are showing and do so with your own time and focus, you can check out the Virtual expo by clicking here.

The question and answer is being handled through an app called Slido and that makes for a clean way to ask questions and interact with each speaker rather than have to try to manage a Zoom chat feed. Again, a neat approach and well presented.

So for today's opening keynote, it's exciting to see friends that I interact with getting to be keynote speakers. Raj Subrameyer and I have interacted together for several years. He was also a recent guest on the Testing Show podcast talking about Tech Burnout (to be clear, not the topic of today's talk). If you'd like to hear our interview with Raj, you can check that out by clicking this link here.



Raj's talk is focused on building Inclusive AI. Sounds scary, huh? Well, it doesn't need to be. He opens with using three movies (2001: a Space Odyssey, HER, and Ex Machina). What was interesting about these movies is that they were science fiction and now, they are science fact. the point is sci-fi has caught up with our present. The question we might want to ask is, is this a good thing? It all comes down to how you look at it. Are you using Siri or Alexa regularly? To be honest, I do not use these very often but I have worked with them, so I'm not a Luddite. Still, there is a small part of me that doesn't want to rely on these tools just yet. Is that a fear-based thing? A trust-based thing?  Maybe a little bit of both. Do I really want to have these AI systems listening in on me? Well, if I'm someone who uses apps like Google, Amazon, Facebook, Instagram, or TikTok (hey, don't judge) I'm already training these systems. Alexa is just a voice attached to a similar system.

let's face it, technology can be creepy. It can also be very interesting if we understand what is happening. AI systems are getting trained all of the time. facial recognition, text recognition, voice recognition, these all are tweaked in similar ways. As Tariq King explained in a talk last year at Testbash in San Francisco, it's not anything sinister or even terribly complex. Ultimately, it all comes down to agents that keep score. When an agent gets something right, they keep a counter of the number of times they have successfully guessed or provided the right answer. They likewise decrement counters when they get things wrong. Over time, the counter helps figure out what is right more times than not. It's not perfect, it's not even intuitive, but it's not really super-human or even all that complicated. we just tend to make it and treat it as such. 

Raj points out that the neural network inside of each of our brains has a number of synaptic connections that, when calculated, equals the number of stars in our galaxy (maybe more) and to quote James Burke, "everybody has one!" The most powerful computers still pale in comparison to the connectivity and plasticity of a single human brain (though interconnected systems can certainly match or exceed single brains).

AI can be classified as weak and strong. Most of the systems that we interact with currently are classified as Weak AI systems. Yes, they can be trained to give a response and they can perform specific steps. Systems like Deep Thought can play chess and beat the best human players, but that is still an example of Weak AI. In short, the system can brute force avenues and do it fast, but it can't really "think". Strong AI can think, and emote, and sympathize, and deal with situations in dynamic ways the way people do. So far, there are very few AI systems that can do that, if any, really.

I'll use an example from my own musical life. I've recently been shopping for guitar amplifier heads, older ones. My all-time favorite guitar tone ever comes from the Marshall JMP amplifier head, which was popular in the early to mid-1970s. Additionally, I also very much like the Carvin X100B Series III amplifier head. A Weak AI would be able to compare specs of both amps and give me a readout of which amp may have the best reaction to fault tolerance or to sonic frequencies. It will not, however, be able to tell me which amplifier head "sounds better". That's a human judgment and it's not something that data will necessarily be able to provide an answer for.

We may be familiar with the study that was done where resumes were submitted using both typically "white" names and also resumes with "black names" (or traditionally seen as white or black names), the AI system was trained on the group of data and, interestingly, it would reject resumes with "black" names twice as often as it would "white" names. That definitely invites a question... how did the system "learn" to do that? Was it trained to do that purely based on the text in the resumes, or did some bias enter the system from the programmers? It's an interesting question and hey, I know what I think about this (hint: humans biased the system but I asked a Slido question, so let's see if it gets answered later ;) ).

Another thing to consider is that AI can be abused and it can also be fooled. In the world today with applications like Photoshop and video editing, deep fakes can be created. Provide enough deep fakes and systems can be trained with literally fake information and those systems can develop agent counts that are not based on reality. Scary but definitely feasible.

Ultimately, AI is as good as the data it is provided and the people that program the systems and the algorithms that train them. Systems can "learn" but again, learning is having a weighted count of something. the more it's "right", the higher the count, and the greater the odds that the "right" answer will actually be "right" in this case. Interesting stuff, to be sure but I'd argue that the odds of these systems coming together and replacing human intuition and interaction is quite a way away. that's not an invitation to be complacent, it's a recommendation to spend time to learn about these systems and how to better understand them and interact with them, and also that we have a responsibility to make sure that the systems we build are not just good quality but also fair to everyone.






Monday, October 12, 2020

PNSQC 2020 Live Blog: “Rethinking Test Automation” with Paul Gerrard


I just realized that the last time I saw Paul in person was back in 2014 at Eurostar in Dublin, Ireland. I was really looking forward to seeing him again after so long but alas, I guess this will have to do.

It's interesting to see that the notion of being surprised about the troubles related to testing automation has been with us since the nineties at least (and some could argue even longer as I remember having issues and dealing with oddities back in the early 90s as I was first learning about Tcl/Tk and Expect. We still struggle with defining what test automation can do for us. Sure, it can automate our tests but what does that really mean?




Tools are certainly evolving and look nothing like the tools we were using 30 years ago. Still, we are dealing with many of the same principles. The scientific method has not changed. I share Paul's criticism that we are still debating what test automation does and what testers do. the issue isn't whether or not our tests work, it's whether or not the tests we perform are actually gathering data that can be agreed to or refuted for hypotheses. As a tester, we want to either confirm or refute the hypothesis. At the end of the day, that is what every relevant test needs to do. We can gather data but can that data that we gather give us meaningful information to actually tell us if the software is working as expected? One could argue that assertions being true are passes... but are they? They are proving we are seeing something that we expect to see but is it actually proving a hypothesis, or merely a small part of it? In short, we need people to look over the tests and the output to see if it is really doing what it should be.   

Paul suggests that we need to move away from scripted tests to more modeled based tests. OK, but what does that actually mean and how do we actually do that? Paul makes the assertion that tools don't think, they support our thinking. What if we removed all of the logistics around testing? If stripped of our usual talismans, what would we do to actually test? rather than stumble through my verbiage, I'm stealing Paul's slide and posting it here:



The key here is that test automation misleads us, in that we think that tools are actually testing and they are not. What they are doing is mapping out the steps we walk through and capturing/applying the sets of data and results that we get based on the data and actions we provide. The left is the exploration, the right is the evaluation, the middle is the testing or the setting up so that we can test. Automation won't work if we don't have a clear understanding of what the system should do. Paul is emphasizing that the problem and the area we need to improve is not the execution of tests (our tools can do that quite adequately) but in test design and test planning. In short, we need better and more robust models. 

The old notion of the human brain is that it is brilliant random, unpredictable but slow and lazy. Machines are literal, unimaginative, but blindingly fast and able to do the same things over and over again. Combined, we have a formidable combination. 

So what do we want to see the future be for our tools? First of all, regression testing needs to look at impact-analysis. How can we determine what our proposed changes might do? How can we stop being overly reliant on testing as an anti-regression measure? How can we meaningfully prove functionality? Also, how do we determine the optimal set of tests without guessing?

Paul makes the case we need to understand the history of failures in our tests. Where can we identify patterns of changes? What are the best paths and data to help us locate failure-prone features? Manual testing will not be able to do this. Machine learning and AI will certainly get us closer to this goal.

In short, we need to move away from passive to active collaboration. We need to stop being the people at the end and work towards active collaboration. We need to be able and willing to provoke the requirements. we also need to create better mental models so that we can better understand how to guide our efforts.


PNSQC 2020 Live Blog: Full Stack Testing Is A Culture with Christina Thalayasingam



Yay! another new speaker. Christina has said that this is her first time speaking at PNSQC. To which I say, welcome, and thank you for joining us.

Full-stack is a term that I have heard used mostly with developers and over the years I have joked about the development of "full-stack testers" (I recall Mark Tomlinson having a spirited debate on that term some years back ;) ). Still, that is the core point of Christina's talk so what does it mean?



My first question is "do we want this to be in one person, or are we talking about the full stack being in the team as a whole?" Is it realistic to have a full stack tester? Can any tester know everything from top to bottom? Or are we looking at full-stack testing meaning any tester or the team of testers can attack any given testing challenge? 

As Christina points out in her abstract, there are several areas and types when it comes to Quality Assurance

Testing
Test Automation
Performance
CI/CD/CT
Usability
Accessibility

to be frank this is an interesting and exciting prospect. It reminds me that I should probably review Alaister Scott's "Pride and Paradev" as that was one of his goals, to help encourage testers to branch out and become broader jacks of all trades. Basically, it comes down to any tester being able to tackle any testing challenge anywhere up and down the development stack. It is unlikely one tester is going to be able to completely cover everything out of the gate. However, it's a good bet if you have a team of three to six testers, you may well have one full-stack tester combined. From there, make a commitment to developing the team to spread that knowledge so that everyone can be competitive. Of course, the odds of getting all six team members to be equal across the board for all skills is probably not reasonable but it's a great goal to reach for. My guess is, even if you don't completely make it, there's a great chance the team will be far more formidable than they were previously :).

PNSQC 2020 Live Blog: Communication Is Key: Lessons Learned From Testing In Healthcare Technology with Rachael Lovallo



As we consider communication challenges, what would we do if those challenges didn't just end up being an issue of finding or missing bugs but potentially being an issue that could spell the difference between life or death? Did that get your attention? Yeah, it got mine, too.



Rachael Lovallo focuses her quality initiatives on the emergency healthcare industry. As she clearly stated at the beginning "we can’t afford bugs, as they could endanger real humans". 

Make bugs as bullet-proof and reproducible as possible. 

This may seem obvious but I would guess that missing anything or being vague would be something that would cause anxiety in this particular environment. By making sure that we identify all of the aspects that point to the bug, a reliable reproduction strategy, and an expected behavior or output to compare with is critical.

Talk to people writing the code you test

Again, seems evident but how many of us really communicate about the code that we are testing? How much of it do we really know inside and out?  How confident would we be to be able to go through and read the code and know exactly what it is doing? I know for myself that I wouldn't be able to do that all on my own,

Ask for a second set of eyes on your work

Oh, I can so relate to this! As someone who basically deals with data transformations at the moment and the methods involved in that covers so many tools and points of contact that it just isn't possible for me to know where everything is and what I should be looking at. Fortunately, the development team I work with are great about showing me the areas I need to hit and to also recognize where I find areas of friction or that are less than optimal for being able to complete tasks. By getting them to walk the workflows and steps with me I am able to uncover with them ways to make the overall flow work better.

PNSQC 2020 Live Blog: Of Machines and Men with Iryna Suprun

As is often the case at PNSQC, several of the talks are from people I have not seen speak before. Iryna Surpum is focusing her talk on areas of AI and Machine Learning. As we start her talk, we look at the fact that there are few tools available where AI and Machine Learning are prominent and prevalent for individual users. Some hallmarks of AI-based tools and what is being marketed are Codeless script generation, the ability to self heal with changes to the environment, meaning the script can collect data about elements of the application itself, and the ability of Natural Language Processing to be able to convert the documentation to actual tests (this is a new one to me, so hey, I'm intrigued). 

Iryna Suprun
Comparison of Visual Output and the expected design is becoming more sophisticated. More tools are supporting these features and additional levels of comparison are being applied (not just pixel to pixel comparison these days). 

So while we have these changes coming (or already here, how can we leverage these tools or learn how to use them in the first place?

Example tools to try out for these comparisons were, Testim, Mabl, and TestCraft. What did they provide? All three allowed for a Quick Start so that they could learn and be able to automate the same basic initial test case. All of the tools had recording implemented, which allows for initial set cases to be created (testCraft had a few extra steps to be set up and utilized so not quite as easily started as the other two). Modifying and inserting/deleting steps was relatively fast.
So what challenges were discovered/associated with these tools? as could be expected, the Codeless Script Generation (Recording) is good to get started but its usefulness diminishes the more complex the test cases become. This is to be expected, IMO, as this has been the same issue with most automation tools that promise an easy entry. It's a place to start but getting further will require proficiency and experience beyond what the recorder can provide. Self-healing is a useful feature but we are still at a point where we have to be somewhat explicit as to what is actually being healed. thus calling it self-healing may still be a misnomer, though that is the goal. So how about self-generated tests? what data is actually being used to create these self-generated cases? This didn't seem to be very self-evident (again, this is me listening, so I may be misinterpreting this). An example is to check to see that links work and are pointing to literally legitimate end links. that tests to see that a link exists and can be followed but that doesn't automatically mean that the link is useful to the workflow or that it will validate that the link is relevant. People still need to make sure that the links go somewhere that makes sense. 
So even though we keep hearing that AI And Machine learning are on the horizon and are even here changing the landscape, there's still a lot of underlying knowledge needed to make these tools work effectively. There's definitely a lot of promise here and there's an interesting future to look forward to but we do not have anything close toa magic want to wave yet. In other words, the idea that AI is going to replace human testers might be a possibility at some point but that promise/scare is not quite ready for prime time yet. Don't be complacent, take the time to learn about how these tools can help us and how we can then leverage out brains for more interesting testing work.
 

PNSQC 2020 Live Blog: Capacity To Execute with John Cvetko

The first talk of the afternoon is being given by John Cvetko. The main point of John's talk is to look at the desire of an organization to change from a Waterfall development methodology to an Agile development methodology. for many of us, it may seem slightly odd that there are still Waterfall SDLC's out there but rest assured there certainly are, lots more than we might like to think. John focused on the considerations needed to make the changes necessary to make the move from Waterfall to agile.

The example organization had multiple release trains (36 release trains in total) and part of the initial process was to create a hybrid release train. They didn't go all in or replace every single release train. Rather, they took on the Agile transformation within a few release trains. They took an isolated and low risk approach so that no more than 20% of the projects would be affected. the Agile transition even with this focus and need was still going to be a challenge and that the implementation of Agile was going to require an entirely different way of thinking.   




This gets us to the title of the talk. The “capacity to execute” is the most important aspect, in short,"Plan your work and work your plan". More to the point, there's more need for planning to make a transition effect. Whether the approach is to make a huge sea change, or smaller waves or bubble up changes, there has to be the ability to plan and execute effectively. 

There are a variety of metrics that are looked at (an example is ISO 25010 Software Quality Standard) and which quality characteristics were chosen to determine the level of focus of the transition. 

By focusing on Scope, Schedule, Budget, and Quality, we as an organization can make a real determination as to what the transition will be able to focus on and to what extent. Just because we want to make the change doesn't mean we will be able to automatically get there just because we want to. Often the business context, the company culture, and the revenue and cash on hand will help influence those paths. 

There is often a Culture Clash that may occur when each team works to try to make these transitions. thus the intentions and plans to execute are doubly important at this time. 

Make no mistake, these are tricky and challenging transitions. It may very well prove to be worth it but it just as likely will not be easy.
 

PNSQC 2020 Live Blog: Software Performance And Load Testing Utilizing JMeter with Anna Sharpe

 

this is number two of the fast-paced talks this hour. Performance testing is often seen as a black art and an area that requires specialized skills. To be sure, doing performance testing at a high level on a regular basis will require special skills and often use tools that are specific and need to be set up in a way that everyone knows about.

However, that may be overkill for what an immediate team needs as well as to run smaller levels of stress tests that are not as all-encompassing. Another challenge is that, if you don't have performance testing skills, you may find it a challenge to getting those skills or getting people to give you the time to train on those skills. The good news is that you can start doing performance testing with a small amount of data and practice getting a handle on the skills that you want to learn. JMeter is a great place to start with this. It's free, it has a small footprint (relatively speaking) and it is friendly to running on smaller, more isolated environments.



JMeter is a well used and well-known tool that has a broad user community and active developer support. JMeter can also work with tools like Fiddler and Charles Proxy to help construct tests and control the responses. 

If at all possible, run your performance and load tests during off-peak hours if possible and especially to make sure not to run these tools on the actual production environment. If you have to use the production environment, do so at a time that coincides with a maintenance window or otherwise runs at a time when customers are not actively using the system. If you have a confirmed level of response that the server is meant to provide (say, 30 active users) a good rule of thumb is to try to run a load test based on the expected load of the system, at least at first. If the system doesn't fall over or requests don't fail, you may want to bump p the number of concurrent users./threads and see how performance changes.

This is a good reminder that testing with JMeter need not be a big involved process and can actually be fun. 
 

PNSQC 2020 Live Blog: Human Centric User Acceptance Testing with Rebecca Long @Amaya30


The next couple of talk are set as quick briefs, so there are two speakers in  an hour-long block Rebecca Long is the first speaker and focusing on  User Acceptance Testing (UAT). What is the primary focus of UAT and more to the point, what does Human-Centric UAT look like? 


For starters, there are ways to be inclusive in the way that we look at our users. Our users are all individuals that have specific needs and ways to be addressed and validated. In addition to focusing on the product being a tool for users to access and interact with, we need to consider what ways we might be inadvertently making those users uncomfortable or put off. In today's world of immediate downloads and use, if we alienate our customers, unless they are locked into/forced to use an application, they will just as likely remove it and never let you know why.



As I tend to focus on Accessibility issues, this is certainly an area where we want to consider this level of focus in our UAT efforts. Above and beyond this are also ways that people wish to refer to themselves and identify. Being inclusive allows for a minimum of friction or complete lack of friction if possible. By taking the time to look at these areas we will help to encourage as many people as possible to use our products and actively engage with us.

Additionally, it's important to realize that these efforts are not one size fits all nor are they one and done efforts. People are complicated and they can be difficult to manage and interact with. Making the effort to include as many people as possible will help make a baseline that includes as many as possible and thus will be usable by as many as possible