If you are a tester you probably routinely look at software or a system and try to determine what is the worst thing that can happen? What if there was an alien invasion, or if the server overheated due to a defective cooling fan and the redundant fan failed also? What if all of the nodes in a cluster fail except for one? What if the datatype in the code can’t handle the size or the type of data stored in the database field that it is reading from?
There are so many scenarios to think up and so little time to test them all that you need to focus energy where it is most beneficial for the customers. I can say that prior to this week I have rarely seen a case in my almost two decades testing where the application couldn’t handle data from the database. Typically the database is more restrictive than the application or exactly matched, not the other way around where the app is more restrictive than the database.
How do you even test for that? The answer is that you cannot always do it. Can someone test for it on the team? Most certainly, down at the lowest level in the application, the code, is the best place to test boundaries, to model production data and then try the average data, then maybe even add a factor to it in order to check that there is some growing room. Is that factor 1.1, 10, 100? It all depends on your system and the expected growth of data over the period of time that the application is expected to go without updates to specfically address size or compatibility of data between the application and DB.
Can a tester assist with this data model from production to determine the average dataset and the growth of data in the application over time? Yes they can and they should so that they can use that information to better understand the customer and their usage and also to ensure that the application can scale and remain performing to expectations and also reliable. Testers should also share this information with others on their team and even all the teams, because the more that everyone knows the more that they can add code to protect against certain exceptions or take into account this information to bolster the design or implementation which leads to a better product in the end.
So next time you have the chance to talk about some new feature or changes to an existing one bring data and have a discussion about the customer, how they will use it, and how much the data set will grow over a period of time and how the performance or functionality may be impacted by this growth. The more we ask what is the worst that can happen with the whole team, the better software we will build and the more reliable and performing it will be even in adverse conditions.
Wednesday, September 5, 2018
Tuesday, April 10, 2018
My first attempt at depicting the benefits of continuous testing
Everyone says that a picture is worth a thousand words, how about a time lapse movie, is it worth many times a thousand words?
We all know that defects that are found late in the development cycle regardless of methodology used are much more costly to fix than those found as close to the customer request or requirements as possible. This is where continuous testing comes in to save the day. Everything step in the development process has a testing phase, write a requirement and then test it to make sure it will deliver what the customer desires or values. Design the architecture, then test it to make sure that it is appropriate for the needs of the feature. Implement the first lines of code and test it to make sure at the unit level everything is returning as expected. Once committed to the branch or trunk then the continuous integration process can run those previously local unit tests and then deploy the build and do additional integration and functional automation testing. When builds are pushed to the pre-prod and even the production environments there should be tests run to ensure that everything is working just as it did in the first environment. In production there should be system health tests and other monitoring to ensure that the system is working as expected and to help identify problems early before customers start calling.
Monday, March 19, 2018
Spring is coming
The past nearly three months have flown by since the new year and Spring is now nearly upon us. In that time I have held many meetings with those interested to share things such as accelerating defect triage to daily, automation frameworks and scalability, leveraging Docker to make automation scalable and more stable, how to improve team communication, and the last presentation was on how developers can contribute to quality. The attendance at each of these meetings is highly variable and is somewhat disappointing. I do however know that people are watching the recordings. In one instance the meeting recording was locked with a password and a few reached out to ask for the password:) Maybe that was just a test?
During this time I have developed a Continuous Testing program that helps to spread testing throughout the lifecycle and it also shares the responsibility for testing from the testers to the whole team. Making sure that the right people are in meetings and discussions about team scope is one of the most important things to drive teams to change. The more that everyone on the team talks, the less lines of code that are written based on unvalidated assumptions from the requirements and the more tests that are executed whether scripted (unit, integration or functional) or exploratory.
Also I have run through some ROI calculations, why would anyone want to change what they are currently doing if we are doing "well enough" now? Well the answer is simple there is a return on investments being made in changing processes, training people and removing organizational impediments. For instance the reduction of time for a hardening sprint can translate into hundreds of thousands of dollars of savings, not that the money is not spent, but it can be redeployed to build features, rather than test and harden the previously completed sprints.
Again as testing slips out of sprints in a multiple sprint release cycle it is easy to let testing "slip right" out of the sprint, but the correct mechanism to improve quality and reduce waste in product development is to "shift left". Shifting left is when each phase of the product development cycle includes testing, from the requirements to the support of the application in production, tests should be executed throughout, whether table top requirements refinement exercises with the 3 amigos (product, dev, test representatives) or unit tests, or integration tests, or functional automation, or even exploratory testing. All of these things add value by reducing rework later.
This is where I was heading in my strategy and when I attended the two day TISQA conference locally in Chapel Hill, NC at the end of February I was excited to be right on par with some of the industries best thought leaders. I returned from the conference and reviewed my nearly complete "Get to Great Quality" presentation that I was building as the explanation of my testing strategy for product development and I made only a handful of minor updates! My strategy was spot on with what multiple companies had already done and were sharing so that others could get to the level that they were already at.
I would meet with executives the following week after the conference, a meeting that was on the calendar for over a month and had already been moved once. I was as ready as ever and had so many facts and industry comparisons and also peer review from some of my most trusted leads from my business unit. Unfortunately the one thing that I had failed to work on was my delivery and also my negotiation skills. While my presentation on the future strategy went well and I maintained the attention of those in attendance I was left without the result that I wanted, investment in quality.
A week later I was able to catch up with the executive that wasn't able to attend the rescheduled date and the feedback was basically that my delivery needs some improvement, "blunt axe" was the exact takeaway. I wasn't upset with anyone, but myself. I know that talking with the executives is not my forte and mostly because I don't have the opportunity to do it from where I sit in my business unit. The opportunity to lead the Quality Center of Excellence opened up the executives to me as they were the ones requesting the program, but I still need to polish my negotiating skills and also my ability to answer the age old question "what is in it for them". That last piece I learned just this past week at a SIM-RTP dinner event. Also that being concise and to the point, "less is more", is very important.
Looking back I have some work to do myself, pare it down, make it clear and concise, and tell the audience what is in it for them. Also coming ready to negotiate and get parts of the whole concept green lighted as opposed to everything staying stuck on the stop line. It will take some time but I will get the right message to the right people and others from throughout the organization will support the strategy and start to implement it because it is the right thing to do to move their business unit and ultimately the enterprise forward. Until then it is back to developing bi-weekly meeting content to continue training the testers in how to approach challenges differently, stand out and start influencing behaviors in their teams that lead them forward faster and with higher customer satisfaction.
During this time I have developed a Continuous Testing program that helps to spread testing throughout the lifecycle and it also shares the responsibility for testing from the testers to the whole team. Making sure that the right people are in meetings and discussions about team scope is one of the most important things to drive teams to change. The more that everyone on the team talks, the less lines of code that are written based on unvalidated assumptions from the requirements and the more tests that are executed whether scripted (unit, integration or functional) or exploratory.
Also I have run through some ROI calculations, why would anyone want to change what they are currently doing if we are doing "well enough" now? Well the answer is simple there is a return on investments being made in changing processes, training people and removing organizational impediments. For instance the reduction of time for a hardening sprint can translate into hundreds of thousands of dollars of savings, not that the money is not spent, but it can be redeployed to build features, rather than test and harden the previously completed sprints.
Again as testing slips out of sprints in a multiple sprint release cycle it is easy to let testing "slip right" out of the sprint, but the correct mechanism to improve quality and reduce waste in product development is to "shift left". Shifting left is when each phase of the product development cycle includes testing, from the requirements to the support of the application in production, tests should be executed throughout, whether table top requirements refinement exercises with the 3 amigos (product, dev, test representatives) or unit tests, or integration tests, or functional automation, or even exploratory testing. All of these things add value by reducing rework later.
This is where I was heading in my strategy and when I attended the two day TISQA conference locally in Chapel Hill, NC at the end of February I was excited to be right on par with some of the industries best thought leaders. I returned from the conference and reviewed my nearly complete "Get to Great Quality" presentation that I was building as the explanation of my testing strategy for product development and I made only a handful of minor updates! My strategy was spot on with what multiple companies had already done and were sharing so that others could get to the level that they were already at.
I would meet with executives the following week after the conference, a meeting that was on the calendar for over a month and had already been moved once. I was as ready as ever and had so many facts and industry comparisons and also peer review from some of my most trusted leads from my business unit. Unfortunately the one thing that I had failed to work on was my delivery and also my negotiation skills. While my presentation on the future strategy went well and I maintained the attention of those in attendance I was left without the result that I wanted, investment in quality.
A week later I was able to catch up with the executive that wasn't able to attend the rescheduled date and the feedback was basically that my delivery needs some improvement, "blunt axe" was the exact takeaway. I wasn't upset with anyone, but myself. I know that talking with the executives is not my forte and mostly because I don't have the opportunity to do it from where I sit in my business unit. The opportunity to lead the Quality Center of Excellence opened up the executives to me as they were the ones requesting the program, but I still need to polish my negotiating skills and also my ability to answer the age old question "what is in it for them". That last piece I learned just this past week at a SIM-RTP dinner event. Also that being concise and to the point, "less is more", is very important.
Looking back I have some work to do myself, pare it down, make it clear and concise, and tell the audience what is in it for them. Also coming ready to negotiate and get parts of the whole concept green lighted as opposed to everything staying stuck on the stop line. It will take some time but I will get the right message to the right people and others from throughout the organization will support the strategy and start to implement it because it is the right thing to do to move their business unit and ultimately the enterprise forward. Until then it is back to developing bi-weekly meeting content to continue training the testers in how to approach challenges differently, stand out and start influencing behaviors in their teams that lead them forward faster and with higher customer satisfaction.
Sunday, March 18, 2018
2018 is a new year
Happy New Year. As 2017 closed out and 2018 began I had some really lofty goals on my New Years Resolution List. At least one was related to pushing forward the Quality Center of Excellence initiative. I had been told previously that it was mine to own and that I should lead it as I saw fit, only conditions, there was no distinct budget and participation is voluntary from others. I was determined to put as much effort as possible outside of my current responsibilities to make sure that I was not a blocker to the potential improvements ahead from this program
Voluntary for me was never a blocker, I had spent over 6 years in emergency services as a volunteer firefighter and paramedic when I lived in Maryland. I had even taken 24 college credits during that time to obtain my national paramedic certification. Not to mention the many hundreds of emergency calls and the thousands of hours of time that I spent on a fire engine or ambulance or on training or at the firehouse waiting for the next call. Oh yea, all of this was for no pay while working full time as a software testing professional!
Why would I do that many would ask? Putting my life at risk, spending time away from my family, what was the benefit? I think for me it served many purposes, I was able to give back to the community that I lived in, many of the people that I saw while on emergency calls were from the nearby community, citizens that were having a bad day and in need of help. I also had a knack for science and math, two things that help when you are doing drug dosage calculations in your head as a paramedic or when you are the operator of a fire engine and need to serve multiple hose lines with enough pressure and volume of water to quickly put out a fire. I am extremely methodical and process oriented, all of the paramedic courses taught medical procedures through flowcharts and algorithms. Lastly, I wanted a challenge, to be able to walk into any situation with numerous unknowns and intervene to hopefully bring stability and a better outcome for all involved.
If you have never been in an ambulance or fire engine heading to a call it is an amazing rush of emotions, excitement, worry, maybe even a little fear. While en route you get information through the radio about the call, whether it is a patient or a motor vehicle accident or a fire. That information paints a picture of what you are going to walk into once you arrive on scene. Once you arrive there is more data to digest, you have to reevaluate your initial assumptions and use sight, sound, touch and smell to get get to the most important information to make decisions and stabilize the situation as quickly as safely possible. Put out the fire, rescue victims, stabilize patients and transport them to a hospital for more definitive care. There are so many acronyms and mnemonics to help remember important actions and assessments in the face of high stress emergency situations. Such as how to assess a patient for traumatic injuries, DCAP-BTLS, or on the fire ground RECEO-VS to help prioritize actions to limit risk to life then to property.
Those six years in emergency services helped me to see that everything being done was to limit risk and to help to normalize the outcomes, increased patient survivability and reduced property damage. These are the exact things that software testing professionals are trying to do in our jobs to make sure that customers using our software have a positive experience with it and keep coming back for more while telling their family and friends about it. I want to make 2018 a great year for testing and quality at my company and plan to volunteer as much of my time as possible to both make myself more knowledgeable and to push forward important initiatives related to the Quality Center of Excellence.
Voluntary for me was never a blocker, I had spent over 6 years in emergency services as a volunteer firefighter and paramedic when I lived in Maryland. I had even taken 24 college credits during that time to obtain my national paramedic certification. Not to mention the many hundreds of emergency calls and the thousands of hours of time that I spent on a fire engine or ambulance or on training or at the firehouse waiting for the next call. Oh yea, all of this was for no pay while working full time as a software testing professional!
Why would I do that many would ask? Putting my life at risk, spending time away from my family, what was the benefit? I think for me it served many purposes, I was able to give back to the community that I lived in, many of the people that I saw while on emergency calls were from the nearby community, citizens that were having a bad day and in need of help. I also had a knack for science and math, two things that help when you are doing drug dosage calculations in your head as a paramedic or when you are the operator of a fire engine and need to serve multiple hose lines with enough pressure and volume of water to quickly put out a fire. I am extremely methodical and process oriented, all of the paramedic courses taught medical procedures through flowcharts and algorithms. Lastly, I wanted a challenge, to be able to walk into any situation with numerous unknowns and intervene to hopefully bring stability and a better outcome for all involved.
If you have never been in an ambulance or fire engine heading to a call it is an amazing rush of emotions, excitement, worry, maybe even a little fear. While en route you get information through the radio about the call, whether it is a patient or a motor vehicle accident or a fire. That information paints a picture of what you are going to walk into once you arrive on scene. Once you arrive there is more data to digest, you have to reevaluate your initial assumptions and use sight, sound, touch and smell to get get to the most important information to make decisions and stabilize the situation as quickly as safely possible. Put out the fire, rescue victims, stabilize patients and transport them to a hospital for more definitive care. There are so many acronyms and mnemonics to help remember important actions and assessments in the face of high stress emergency situations. Such as how to assess a patient for traumatic injuries, DCAP-BTLS, or on the fire ground RECEO-VS to help prioritize actions to limit risk to life then to property.
Those six years in emergency services helped me to see that everything being done was to limit risk and to help to normalize the outcomes, increased patient survivability and reduced property damage. These are the exact things that software testing professionals are trying to do in our jobs to make sure that customers using our software have a positive experience with it and keep coming back for more while telling their family and friends about it. I want to make 2018 a great year for testing and quality at my company and plan to volunteer as much of my time as possible to both make myself more knowledgeable and to push forward important initiatives related to the Quality Center of Excellence.
The holidays
The Christmas holiday season in the US starts at least by Thanksgiving and for employees it is a time when people can become pre-occupied with many things that are not work related and their productivity suffers. So many times we have found our releases suffering from low numbers of employees available to do critical tasks especially near the end of a release cycle. This is one of the biggest issues with large releases that are a combination of multiple sprints and a "hardening sprint".
Luckily this past quarter our product release was in the beginning of December and there was no holiday drag on that release, but the next release started off in the holiday season and there were definitely days and even full weeks with only 40% of the teams working on sprint commitments. That is a serious drain on team productivity, especially when an entire discipline may be absent from a team, no PO, or no QA. Luckily the remainder of the quarterly release the vacations and time away and distractions were not as great.
This same holiday season also impacts initiatives that require people to show up voluntarily, like the Quality Center of Excellence that I was heading. While teams were struggling to keep the lights on some days and weeks during this time, I knew it would be hard to get attention and get folks to voluntarily show up. I planned for this by having only one meeting between Thanksgiving and Christmas. This way I hoped that asking for 1 hour of time for a single meeting instead of two meetings would help with attendance. I was ready to invest the time for two, but felt others might not and I didn't want to discourage myself by having a low attendance meeting.
I also wanted to make sure that we continued moving quickly and that I got a chance to present practical content for the audience. The first couple of presentations were forward looking, they spoke of what we could do and exposed some extremely high level concepts to improve quality. In the last meeting of November one of the attendees suggested to "use the majority of the next meeting time to train the attendees on something practical", something that they could take back to their teams and help to change process and culture to promote quality.
I knew just what to present. Something that I had started using with teams in my business unit, Risk Management. This wasn't even fully my own concept or idea, it was something that I had learned while attending TriAgile in Raleigh-Durham area back in April 2017. That conference session was led by Jenny Bramble and really hit home as a way to get all teams focused on testing the most valuable features for the customer and the most risky items from an implementation perspective to ensure that in the end the customer result was better than it may have been in the past.
The goal of risk management was to reduce the amount of tests run, to reduce the hardening sprint duration, all while focusing methodically to eliminate risk and deliver the most valuable customer features with the fewest impactful defects. At that point my teams had already finished up an entire quarterly release and implemented a risk scoring process and communication with the business stakeholders to ensure alignment and the right sized testing effort based on customer value and complexity. I thought it was pretty successful and was happy to share this with others.
The session I delivered went really well, most teams present said that they had an "informal" method of doing what I was talking about, but nothing written or reviewed regularly. There was obvious room for improvement and I had a few requests for the slides from the presentation. I always put the slides and the recording of the session on a Confluence site by the meeting date so that anyone in the company can locate the information and potentially benefit from it.
After this mid-December session it was time to hit the snooze button, as many teams through the company were heads down trying to finish up things before year end or they were on PTO or just in that state where distractions about the holiday gifts and the family events and everything else was taking time from "voluntary" participation in a QCoE. This closes out 2017 and the first 2.5 months of QCoE startup.
Friday, March 16, 2018
Rewind the clock five months
As promised I am going back to the beginning of my current effort to raise the visibility and importance of quality in the organization.
What is quality? There are so many definitions, the most concise one that I could find is: "degree of excellence" from Merriam-Webster dictionary. This definition leaves lots to be defined, if we look up excellence we get "the quality of being excellent". This seems almost like a circular definition if you combine these together "degree of (the quality of being excellent)". How can I sell this to executives, or even those that I manage directly?
Talking with my executive sponsor for this initiative I found out that the top three goals of this program were to 1) gather a group of existing quality leaders from all business units to attend regular meetings and share their best practices; 2) get products closer to continuous delivery (from quarterly or longer releases to something much faster); 3) do this in small incremental changes.
This seemed like something we could finish in a couple of months, surely there are others in the organization that want to join and contribute and move the organization forward. I left the first meeting with a sense of excitement, I was picked to lead this and I figured that everyone I would interact with in the near future would be ready to learn and happy to receive feedback on processes and potential improvements.
I had numerous 1x1 meetings with my executive sponsor and other trusted advisors that I have throughout the organization. I was testing my ideas and the setup of the initial focus areas that the QCoE should start with.
Mid-November was the kick off meeting for the group, I used a list of quality leads and managers that was provided to me by the executive sponsor and invited all of them. Our first meeting was attended by 16 people in addition to myself, a collection of predominantly quality engineers from most of the lines of business. We talked about the executive level program and how this Quality Center of Excellence fits into other improvement projects that are going on in the enterprise. We talked through all of this and defined 7 focus areas. Each of those areas needed to have an "owner" or chairperson.
Of course I forgot to record the WebEx so that it could be shared with others that were invited but did not attend. Realizing this, I sent out an email update to everyone invited and included the presentation slides and a summary of the meeting. I also requested volunteers for the focus areas that I had defined. Over the next couple of weeks I had received sporadic interest in some of the focus areas and took it as an opportunity to learn more about the other person and their teams and products they test. I also sent out several SurveyMonkey surveys one per focus area hoping I could get information from each person and product and that would help to formulate the basis for the next meetings and identify the "biggest bang for the buck" areas to start with improvement activities.
What is quality? There are so many definitions, the most concise one that I could find is: "degree of excellence" from Merriam-Webster dictionary. This definition leaves lots to be defined, if we look up excellence we get "the quality of being excellent". This seems almost like a circular definition if you combine these together "degree of (the quality of being excellent)". How can I sell this to executives, or even those that I manage directly?
Talking with my executive sponsor for this initiative I found out that the top three goals of this program were to 1) gather a group of existing quality leaders from all business units to attend regular meetings and share their best practices; 2) get products closer to continuous delivery (from quarterly or longer releases to something much faster); 3) do this in small incremental changes.
This seemed like something we could finish in a couple of months, surely there are others in the organization that want to join and contribute and move the organization forward. I left the first meeting with a sense of excitement, I was picked to lead this and I figured that everyone I would interact with in the near future would be ready to learn and happy to receive feedback on processes and potential improvements.
I had numerous 1x1 meetings with my executive sponsor and other trusted advisors that I have throughout the organization. I was testing my ideas and the setup of the initial focus areas that the QCoE should start with.
Mid-November was the kick off meeting for the group, I used a list of quality leads and managers that was provided to me by the executive sponsor and invited all of them. Our first meeting was attended by 16 people in addition to myself, a collection of predominantly quality engineers from most of the lines of business. We talked about the executive level program and how this Quality Center of Excellence fits into other improvement projects that are going on in the enterprise. We talked through all of this and defined 7 focus areas. Each of those areas needed to have an "owner" or chairperson.
Of course I forgot to record the WebEx so that it could be shared with others that were invited but did not attend. Realizing this, I sent out an email update to everyone invited and included the presentation slides and a summary of the meeting. I also requested volunteers for the focus areas that I had defined. Over the next couple of weeks I had received sporadic interest in some of the focus areas and took it as an opportunity to learn more about the other person and their teams and products they test. I also sent out several SurveyMonkey surveys one per focus area hoping I could get information from each person and product and that would help to formulate the basis for the next meetings and identify the "biggest bang for the buck" areas to start with improvement activities.
Friday, March 9, 2018
Welcome to my blog
It has been many years since I have written a blog entry (July 14, 2011), six and a half years ago roughly. My last blog post was about putting out my first house fire. Back in the day I had a blog about Emergency Services and things that I had seen or experienced in the normal course of being a volunteer Paramedic and Fire Fighter in Maryland. I was about halfway through my stint as a test manager at Agora Publishing in Baltimore, MD, I had a wife and two kids with the third on the way.
Flash forward to today and I am in a different state, North Carolina to be exact, I no longer volunteer in Emergency Services, I have twice as many kids now and I am still employed managing software testers albeit for another company. I have learned a lot more about technology, testing, and people in the past six plus years.
I plan to use this blog to give me somewhere to write about my passion for testing, what I have learned in my career and to hopefully inspire others to pursue careers in testing. Along the way I hope to also pick other's brains and get answers to challenges and other things that will make me better at leadership or technical ability or at influencing others to support and promote healthy testing practices and culture.
I have so much to write about. The past five months at my job have been a whirlwind. Back in October I was asked to lead a "Quality Center of Excellence" initiative. My heart raced, my palms got sweaty and I was over excited about the opportunity. As I learned more about it the position was in addition to all my current responsibilities, and it came with no extra pay. This didn't discourage me though and I think that the senior leadership knew that and it was one of the reasons that I was selected.
Having worked there for almost four years in October they knew what I was capable of and the passion that I had for "testing things". The product that I worked on was considered very mature in process and ability to deliver on time, on budget and with an acceptable amount of quality. So naturally whatever I was doing should be able to be forklifted to all other business units in the company and we would see instant benefits right? Well at the beginning that was definitely their expectation, but I knew better. I had heard the horror stories from other business units and even had some first hand accounts from folks that I knew outside my group.
This is where my blog is going to focus, on the past five months and I hope to catch everyone up to current day, March 9, 2018 within the next few blog posts.
Flash forward to today and I am in a different state, North Carolina to be exact, I no longer volunteer in Emergency Services, I have twice as many kids now and I am still employed managing software testers albeit for another company. I have learned a lot more about technology, testing, and people in the past six plus years.
I plan to use this blog to give me somewhere to write about my passion for testing, what I have learned in my career and to hopefully inspire others to pursue careers in testing. Along the way I hope to also pick other's brains and get answers to challenges and other things that will make me better at leadership or technical ability or at influencing others to support and promote healthy testing practices and culture.
I have so much to write about. The past five months at my job have been a whirlwind. Back in October I was asked to lead a "Quality Center of Excellence" initiative. My heart raced, my palms got sweaty and I was over excited about the opportunity. As I learned more about it the position was in addition to all my current responsibilities, and it came with no extra pay. This didn't discourage me though and I think that the senior leadership knew that and it was one of the reasons that I was selected.
Having worked there for almost four years in October they knew what I was capable of and the passion that I had for "testing things". The product that I worked on was considered very mature in process and ability to deliver on time, on budget and with an acceptable amount of quality. So naturally whatever I was doing should be able to be forklifted to all other business units in the company and we would see instant benefits right? Well at the beginning that was definitely their expectation, but I knew better. I had heard the horror stories from other business units and even had some first hand accounts from folks that I knew outside my group.
This is where my blog is going to focus, on the past five months and I hope to catch everyone up to current day, March 9, 2018 within the next few blog posts.
Subscribe to:
Posts (Atom)